-
Research
and Publications
Current Issue
March/April 2013
EDUCAUSE ReviewPublications
-
Conferences
and Events
Annual Conference
October 15–18, 2013
Save the date!Events for all Levels and Interests
Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.
-
Career
Development
EDUCAUSE Institute
Leadership/Management Programs
Explore MoreCareer Center
Leadership and Management Programs
EDUCAUSE Institute
Advanced Programs
Project Management
Jump Start Your Career Growth
Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.
-
Focus Areas
and InitiativesLatest Topics
EDUCAUSE organizes its efforts around three IT Focus Areas
Join These Programs If Your Focus Is
-
Connect
and ContributeFind Others
Get on the Higher Ed IT Map
Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
-
About
EDUCAUSE
Identity data services
I suppose many of us who've built a "person registry" or an "identity database" over the years are, to varying degrees, in the business of distributing various identity-related data to individuals and applications on our campuses.
In our case, this "service" has grown incrementally over time -- we receive requests for data from those who want a single, authoritative, central source (as opposed to systems of record that focus on a particular constituency, like an HR system). So we rig up data feeds, add data to LDAP, create reports, maybe even create web services...
Anyway, we're doing some strategic planning, and I'm wondering what we should aim for in the category of identity-related data services.
* A reasonable business to be in ?
* How should we make data available going forward ?
* What should be the core elements of an "identity data service" ?
* What kinds of "raw" data should we make available ? e.g.
-- basic identifying information that we use in uniquely identifying an individual
-- basic bio/demo data
-- basic affiliation information
-- a person's "profile" information
-- geo-location information (if we have it?)
-- group membership info
-- role assignment info
My initial thoughts are:
* this -is- a reasonable business to be in, to some degree
* but gotta be scalable
* so de-emphasize push models (like outbound data feeds); emphasize pull models, e.g. central data in a directory; web services for people to use
All thoughts welcome.
- Gary Chapman
Sr IT Architect, NYU
Recommend
Comments
No question that person registries are of unique value. We must make that data available but the ‘when’ and the ‘why’ may not be our decision.
One thing we try to keep in mind is that our registry is a downstream consumer of data owned by our HR and student systems etc. I have been asked for lists that are ridiculously quick and easy for me to produce except that it is not my data to give. Employee data in the registry is still owned by HR, Student data in the registry is still owned by the Registrar. The decisions about if data should be provided should remain with the sources of authority for the data even after it has been aggregated into a registry.
We provide a ‘people directory’ that is, as the name implies, a phone number, email, office number lookup tool. But most everything else is as needed. The registry is a resource that is valuable but can also be dangerous. If you don’t carefully consider every release of data you can get into HIPAA, FERPA, or general privacy trouble quickly.
Overall my opinion is that the registry is a valuable treasure that should be kept locked up unless truly needed. I think requests should go to the sources of authority first and only come to the registry if the data need can’t be gotten from a single system of record. And requests for data from the registry should be authorized by the original data owners.
To answer your direct questions:
Can’t avoid the business like it or not.
There are too many use cases for data delivery but one thing we are trying to do is to assign each request a special user in the directory so that everything relying on the registry can be tracked and granted only the access needed.
I don’t think generic “identity data service” beyond a simple phone directory is a good idea.
What data to make available should be a per request decision and should be minimum required.
When data is to be released I do favor pull over push and I am a fan of web services.
Consider a hypothetical "ERP" system that covered registrar, staff personnel, academic personnel, library, etc., etc. It would, almost certainly, have a common "identity" module that held information about the people who use all of the other, more business-aligned modules. I think the only reason we don't think that way for our existing IAM systems is that all of our other systems of record came first, so the IAM registries were built by joining extracts from those systems of record.
This join process is suboptimal, as it is typically done after people have been entered into the identity stores of the systems of record, requiring new business processes to reconcile issues when the join fails. Asking others to go back to the registrars, personnel managers, etc., forces them to create their own join processes at higher cost and risk. Also, I think an authoritative joined identity registry can add great value beyond its obvious use for access management, as enables "cradle to grave" relationships with individuals as they become students, alumni, donors, employees, etc.
So, I think this is a reasonable business for someone to be in, and I think it is usually the IAM group.
That said, there are many issues associated with expanding the scope of the IAM registry, not the least of which is custodianship of the data. The model I've described requires partial delegation of custodianship to the the IAM group, and that requires agreements for how and under what conditions the IAM group may release what data. While there are many data elements that need to be discussed, I think there are a small number of classifications:
David Walker
On Wed, 2011-12-07 at 09:59 -0600, Jones, Mark B wrote:
I think you are trying to compare apples and oranges. The registry is either upstream (like in your hypothetical ERP example) requiring all identities to exist in the registry before any data entry can occur in the systems of record, or the registry is downstream (as I think is the case at most institutions) requiring a join process. The downstream paradigm allows traditional SORs to operate independently of the other systems of record and collect identity information in ways that satisfy their specific business.
I wouldn’t jump to the conclusion that the downstream paradigm is suboptimal. Identity reconciliation must occur and can fail using either design. I also don’t see how one paradigm supports cradle-to-grave relationships any better or worse than the other.
From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of David Walker
Sent: Wednesday, December 07, 2011 1:05 PM
To: IDM@LISTSERV.EDUCAUSE.EDU
Subject: Re: [IDM] Identity data services
Consider a hypothetical "ERP" system that covered registrar, staff personnel, academic personnel, library, etc., etc. It would, almost certainly, have a common "identity" module that held information about the people who use all of the other, more business-aligned modules. I think the only reason we don't think that way for our existing IAM systems is that all of our other systems of record came first, so the IAM registries were built by joining extracts from those systems of record.
This join process is suboptimal, as it is typically done after people have been entered into the identity stores of the systems of record, requiring new business processes to reconcile issues when the join fails. Asking others to go back to the registrars, personnel managers, etc., forces them to create their own join processes at higher cost and risk. Also, I think an authoritative joined identity registry can add great value beyond its obvious use for access management, as enables "cradle to grave" relationships with individuals as they become students, alumni, donors, employees, etc.
So, I think this is a reasonable business for someone to be in, and I think it is usually the IAM group.
That said, there are many issues associated with expanding the scope of the IAM registry, not the least of which is custodianship of the data. The model I've described requires partial delegation of custodianship to the the IAM group, and that requires agreements for how and under what conditions the IAM group may release what data. While there are many data elements that need to be discussed, I think there are a small number of classifications:
+1 -----Original Message-----From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Hendricks,Rodger ESent: Wednesday, December 07, 2011 7:54 AMTo: IDM@LISTSERV.EDUCAUSE.EDUSubject: Re: [IDM] Identity data services The data custodian for student enrollment data is the Registrar, whatever technical infrastructure you use. It seems to me that you're walking into a swamp if your responsibility extends past setting standards and providing adequate tools to the Registrar for maintaining their information in the registry. It seems to me that requirements, use cases, business logic and priorities should stay with the data custodians. All other roads lead to madness. If you're proposing to implement (or shadow) the Registrar's business logic, why stop there? What about the other IdM data custodians? There may turn out to be a number of those. At UF, off the top of my head, I can think of HRAcademic Personnel (different from HR) RegistrarAdmissions (different from Registrar)Traffic and ParkingID Card servicesLibrariesFour different flavors of Continuing EducationOther outreach (e.g. agricultural extension, certificate programs)Various professional schoolsAcademic departments Each of these feeds data into and consumes data from the registry. Each has its own mission, constituency, priorities and ever-changing business logic. > -----Original Message-----> From: Identity Management Constituent Group Discussion list> [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brendan Bellina> Sent: Tuesday, December 06, 2011 4:11 PM> To: Hendricks,Rodger E> Subject: Re: Identity data services> >David Walker
On Wed, 2011-12-07 at 09:59 -0600, Jones, Mark B wrote:
Mark,
I call the downstream paradigm "suboptimal," as it requires a separate reconciliation process from the original reconciliation process used locally by the SOR. An upstream paradigm can handle reconciliation as part of the original process. This, of course, doesn't mean that it often isn't best to use the downstream model. The downstream model can be the only viable model, due to the high cost (or infeasibility) of changing an existing SOR.
That said, my main point is that maintaining an authoritative identity registry, either upstream or downstream, can be difficult and expensive to do well. Doing it multiple times not only increases cost, but also tends to result in mediocre, less-than-fully-secure implementations. As you've said, either the upstream or downstream model can create a registry appropriate for "cradle to grave" use, but that assumes that the registry created is perceived as authoritative and available as a service to the enterprise.
David
On Wed, 2011-12-07 at 14:31 -0600, Jones, Mark B wrote:
I agree with all of this. It should be noted that the upstream paradigm comes with its own set of advantages and disadvantages.
I wonder if we are communicating on what each other means by “perceived as authoritative and available as a service to the enterprise”?
Maybe the debate is around what the ‘scope of authority’ should be for the registry?
From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of David Walker
Sent: Wednesday, December 07, 2011 4:24 PM
To: IDM@LISTSERV.EDUCAUSE.EDU
Subject: Re: [IDM] Identity data services
Mark,
I call the downstream paradigm "suboptimal," as it requires a separate reconciliation process from the original reconciliation process used locally by the SOR. An upstream paradigm can handle reconciliation as part of the original process. This, of course, doesn't mean that it often isn't best to use the downstream model. The downstream model can be the only viable model, due to the high cost (or infeasibility) of changing an existing SOR.
That said, my main point is that maintaining an authoritative identity registry, either upstream or downstream, can be difficult and expensive to do well. Doing it multiple times not only increases cost, but also tends to result in mediocre, less-than-fully-secure implementations. As you've said, either the upstream or downstream model can create a registry appropriate for "cradle to grave" use, but that assumes that the registry created is perceived as authoritative and available as a service to the enterprise.
David
On Wed, 2011-12-07 at 14:31 -0600, Jones, Mark B wrote:
I think you are trying to compare apples and oranges. The registry is either upstream (like in your hypothetical ERP example) requiring all identities to exist in the registry before any data entry can occur in the systems of record, or the registry is downstream (as I think is the case at most institutions) requiring a join process. The downstream paradigm allows traditional SORs to operate independently of the other systems of record and collect identity information in ways that satisfy their specific business.
I wouldn’t jump to the conclusion that the downstream paradigm is suboptimal. Identity reconciliation must occur and can fail using either design. I also don’t see how one paradigm supports cradle-to-grave relationships any better or worse than the other.
Mark,
On Wed, 2011-12-07 at 16:48 -0600, Jones, Mark B wrote: Yes, I think so, although the scope might be different for different attributes in the registry, if I understand what you mean. A couple of examples:
David
If you are saying that the registry would be authoritative for mail forwarding I would agree.
If you are saying that the registry is not authoritative for enrollment status I agree again. That is not to say that getting enrollment status from the registry wouldn’t be ‘authoritative enough’ in some case.
But one thing I do question is if enrollment status is an appropriate data point to store in an identity registry. It does not seem very useful outside the context of the student system.
From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of David Walker
Sent: Thursday, December 08, 2011 12:52 PM
To: IDM@LISTSERV.EDUCAUSE.EDU
Subject: Re: [IDM] Identity data services
Mark,
On Wed, 2011-12-07 at 16:48 -0600, Jones, Mark B wrote:
I agree with all of this. It should be noted that the upstream paradigm comes with its own set of advantages and disadvantages.
I wonder if we are communicating on what each other means by “perceived as authoritative and available as a service to the enterprise”?
Maybe the debate is around what the ‘scope of authority’ should be for the registry?
Yes, I think so, although the scope might be different for different attributes in the registry, if I understand what you mean. A couple of examples:
David
These were just examples of the kinds of statements that could be made. While I think they're not unreasonable, I'm not advocating those specific statements.
The real point is that there are degrees of authoritative-ness, and statements like this let people know if the information is "authoritative enough." Populating the registry with attributes that are authoritative enough for enough uses is, in my opinion, a good thing.
David
On Thu, 2011-12-08 at 13:46 -0600, Jones, Mark B wrote: