Main Nav

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

Comments

Here are my humble opinions, please pardon my answering questions with questions. > * A reasonable business to be in ? Is there a way that we can get out of the business such as outsourcing and leveraging? If so would there be sufficient depth in LOA for our needs and would it be simpler to use for those we provide identities for now? If no to the last 2 then it probably will fall back in our lap. It is not about saving money, because if we do it poorly or make poor choices the results are never good. > * How should we make data available going forward ? Hopefully using standards based protocols and in a privacy protecting manner that is scalable. Real time, on demand is a high mark to aim for but not always the best or the most reasonable and generally the most expensive to build and support. Careful planning is needed and built in checks are required to ensure that a change in the supply chain does not break the downstream systems in a demand service. > * What should be the core elements of an "identity data service" ? Obscure or opaque when it should be and transparent when it has to be. An example would be to use group membership for access controls in lieu of passing attributes about a user to obscure information about the person. But if a unique identifier is required that one can be made available (these can also be opaque, unique and never recycled. Simple and possibly scalable (depending on your needs), compatible with all of the possible consumers (think provisioning and access controls) As flexible as people's identities are flexible and as rigid as the requirements of the apps that rely on them There should be sufficient information that is accurate for each entity in the system so as to reduce the amount of possible collisions and make reconciliation possible on a large enough scale to accommodate long term data growth. > * 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 The idea of being liberal with attributes we consume and stingy with those we distribute still has a good feel to it in this case. I find that each consumer may want something different. Ensuring that the consumer only get what they need and then in turn agree to protect the data under the same conditions that it was given up. You can measure what should be public by validating if it is already public, but you may want to ensure that you are not just adding another or better source. > 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 > I hope I have added some value. I think you are on the right track Barry

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.

 

Brendan wrote: "One issue I am expecting to face is that the data we have today in the registry is suitable for identity resolution and authorizations, but it is not suitable for reporting. For example, we have enrollment information for who is enrolled in a class and anytime an individual changes their enrollment that information is updated in the registry. However, if a class is cancelled in the student system today, there is no function that removes that class from the enrollment information. Also, if a student is on leave they are not automatically de-enrolled from classes. This hasn't been a significant issue as of yet, but if someone wants a report that lists the students in a class they probably do not expect to see students on leave listed in the report. I expect we will have to have alterations in our student system to handle use cases like this differently." Do you really want to get into this business? Once you get your system tuned to know when a student is on leave the Registrar will add, change, or remove a use case for student leave. Once you start trying to interpret the data in the student system you are committed to monitor and keep up with their changing business logic.
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 HR Academic Personnel (different from HR) Registrar Admissions (different from Registrar) Traffic and Parking ID Card services Libraries Four different flavors of Continuing Education Other outreach (e.g. agricultural extension, certificate programs) Various professional schools Academic 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 > >
+1 -----Original Message----- From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Hendricks,Rodger E Sent: Wednesday, December 07, 2011 7:54 AM To: IDM@LISTSERV.EDUCAUSE.EDU Subject: 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 HR Academic Personnel (different from HR) Registrar Admissions (different from Registrar) Traffic and Parking ID Card services Libraries Four different flavors of Continuing Education Other outreach (e.g. agricultural extension, certificate programs) Various professional schools Academic 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 > >
We are faced with the challenge of providing reporting services. We are migrating both our Payroll system and our Student system and there are many advantages to having reporting being done against a reporting system rather than directly against systems of record. Since the registry is the system that combines identity data from multiple systems of record and maintains the master identity record, it makes sense that it should be the primary source for such a reporting system. This is an opportunity to improve the data quality in the registry and directory, significantly reduce the number of datafeeds containing PII, and provide a layer of indirection between report consumers and the systems of record which should reduce the complexity of migration. Though more complex this is essentially the same as what we have all already been doing to populate attributes like eduPersonPrimaryAffiliation that are useful for end user applications but have no direct correspondence with an attribute in a single system of record. Anyone populating standard attributes in a directory service is already interpreting SOR business rules. I don't see this as a fundamentally different exercise. The scale will be challenging though and extending the governance model will probably prove difficult as well. If anyone already has an ODS or Data Warehouse built based on their registry I would be very interested in knowing what governance structure they have implemented and what kinds of policies they follow. Regards, Brendan Bellina Mgr, IdM USC
Message from dhwalker@ucdavis.edu

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:

  • Data can be made available with little or no control (e.g., white pages directory data).  Many IAM groups are already doing this.
  • Data that can be made available by the IAM group for legitimate university business.  This would likely entail requirements for being "legitimate," as well as operational and security requirements.  For example, legitimacy might require the approval of a dean or department chair.
  • Data that can be made available by the IAM group only after approval by the primary custodian.  (I am including data that cannot be made available by the IAM group here, since the primary custodian can always say no.)

David Walker

On Wed, 2011-12-07 at 09:59 -0600, Jones, Mark B wrote:
+1 -----Original Message----- From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Hendricks,Rodger E Sent: Wednesday, December 07, 2011 7:54 AM To: IDM@LISTSERV.EDUCAUSE.EDU Subject: 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 HR Academic Personnel (different from HR) Registrar Admissions (different from Registrar) Traffic and Parking ID Card services Libraries Four different flavors of Continuing Education Other outreach (e.g. agricultural extension, certificate programs) Various professional schools Academic 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 > >
This really depends on what kinds of reporting you are talking about. From a policy perspective, I'm not convinced that it is a good idea to have a layer of indirection between report consumers and the systems of record. In my mind it is desirable and appropriate that the owners of systems of record be directly responsible and accountable for the release of their data. We do not interpret SOR business rules. The SOR controls what data we receive into the registry. Basically we ask HR for a set of data points for all current employees and the SOR for HR provides that data set. How that data is extracted from the SOR is the responsibility of the custodians of the HR system of record. Here is an example to talk about... Our Registrar provides IdM an extract of 'current students'. They also provide reports to the State on 'current students'. But the definition of 'current student' is different for both. For IdM the definition is shaped by the needs for access to IT resources. For the State it is about how many 'students' qualify for the State funding equation. The definition of 'current student' for the State report could change every term and has little if anything to do with IdM, and I don't think IdM should be involved in such reporting or even store the data points needed to generate the report. -----Original Message----- From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brendan Bellina Sent: Wednesday, December 07, 2011 12:23 PM To: IDM@LISTSERV.EDUCAUSE.EDU Subject: Re: [IDM] Identity data services We are faced with the challenge of providing reporting services. We are migrating both our Payroll system and our Student system and there are many advantages to having reporting being done against a reporting system rather than directly against systems of record. Since the registry is the system that combines identity data from multiple systems of record and maintains the master identity record, it makes sense that it should be the primary source for such a reporting system. This is an opportunity to improve the data quality in the registry and directory, significantly reduce the number of datafeeds containing PII, and provide a layer of indirection between report consumers and the systems of record which should reduce the complexity of migration. Though more complex this is essentially the same as what we have all already been doing to populate attributes like eduPersonPrimaryAffiliation that are useful for end user applications but have no direct correspondence with an attribute in a single system of record. Anyone populating standard attributes in a directory service is already interpreting SOR business rules. I don't see this as a fundamentally different exercise. The scale will be challenging though and extending the governance model will probably prove difficult as well. If anyone already has an ODS or Data Warehouse built based on their registry I would be very interested in knowing what governance structure they have implemented and what kinds of policies they follow. Regards, Brendan Bellina Mgr, IdM USC

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:

  • Data can be made available with little or no control (e.g., white pages directory data).  Many IAM groups are already doing this.
  • Data that can be made available by the IAM group for legitimate university business.  This would likely entail requirements for being "legitimate," as well as operational and security requirements.  For example, legitimacy might require the approval of a dean or department chair.
  • Data that can be made available by the IAM group only after approval by the primary custodian.  (I am including data that cannot be made available by the IAM group here, since the primary custodian can always say no.)


David Walker

On Wed, 2011-12-07 at 09:59 -0600, Jones, Mark B wrote:

 +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> >
Valuable service comes from meeting business needs with data, capabilities and an interface. If you pretend there isn't a business need for reporting, then you aren't providing valuable service (so that's out). If you pretend that the business needs can be fulfilled in silos (i.e. each customer must go to each SOR), then you'll be OK for a while until your customers ask questions or have needs which span those silos. For a while, a few of them may *EACH* build their *own* data interface layer between each of the SORs, so they can fulfill their business needs. But at some point (hopefully before they build their own layer) they'll realize that this data integration capability is something that should be run centrally instead of each of them expending resources on it. So at some point, you will need to establish an enterprise identity data model, an enterprise identity data integration layer, and probably an enterprise identity service integration layer. I balk at calling all these valuable architectural components "a layer of indirection" which are a bad idea--in fact, I'm convinced they are a really good idea. I'd also like to challenge your assumption that by having an enterprise identity data integration layer you've removed the direct responsibility and accountability of the owners of SORs. There are certainly many ways that access control and auditing can be accomplished regardless of the actual delivery of the services, so an assumption that by integrating these data sources you've removed those capabilities seems unwarranted. Finally, your example seems to hinge on the assumption that the word "current" must only be represented by a single data point. Seems to me that you build two different data points in your data model. The enterprise business needs call for two different data points, so why can't you have those two data points in a single integration layer instead of having a single data point with different definitions in two separate integration services? > -----Original Message----- > From: Identity Management Constituent Group Discussion list > [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jones, Mark B > Sent: Wednesday, December 07, 2011 12:11 PM > To: IDM@LISTSERV.EDUCAUSE.EDU > Subject: Re: [IDM] Identity data services > > This really depends on what kinds of reporting you are talking about. > > From a policy perspective, I'm not convinced that it is a good idea to have a > layer of indirection between report consumers and the systems of record. In > my mind it is desirable and appropriate that the owners of systems of record > be directly responsible and accountable for the release of their data. > > We do not interpret SOR business rules. The SOR controls what data we > receive into the registry. Basically we ask HR for a set of data points for all > current employees and the SOR for HR provides that data set. How that data > is extracted from the SOR is the responsibility of the custodians of the HR > system of record. > > Here is an example to talk about... Our Registrar provides IdM an extract of > 'current students'. They also provide reports to the State on 'current > students'. But the definition of 'current student' is different for both. For > IdM the definition is shaped by the needs for access to IT resources. For the > State it is about how many 'students' qualify for the State funding equation. > The definition of 'current student' for the State report could change every > term and has little if anything to do with IdM, and I don't think IdM should be > involved in such reporting or even store the data points needed to generate > the report. > > > > -----Original Message----- > From: Identity Management Constituent Group Discussion list > [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brendan Bellina > Sent: Wednesday, December 07, 2011 12:23 PM > To: IDM@LISTSERV.EDUCAUSE.EDU > Subject: Re: [IDM] Identity data services > > We are faced with the challenge of providing reporting services. We are > migrating both our Payroll system and our Student system and there are > many advantages to having reporting being done against a reporting system > rather than directly against systems of record. Since the registry is the system > that combines identity data from multiple systems of record and maintains > the master identity record, it makes sense that it should be the primary > source for such a reporting system. This is an opportunity to improve the > data quality in the registry and directory, significantly reduce the number of > datafeeds containing PII, and provide a layer of indirection between report > consumers and the systems of record which should reduce the complexity of > migration. Though more complex this is essentially the same as what we > have all already been doing to populate attributes like > eduPersonPrimaryAffiliation that are useful for end user applications but > have no direct correspondence with an attribute in a single system of record. > Anyone populating standard attributes in a directory service is already > interpreting SOR business rules. I don't see this as a fundamentally different > exercise. The scale will be challenging though and extending the governance > model will probably prove difficult as well. If anyone already has an ODS or > Data Warehouse built based on their registry I would be very interested in > knowing what governance structure they have implemented and what kinds > of policies they follow. > > Regards, > > Brendan Bellina > Mgr, IdM > USC > >
Message from dhwalker@ucdavis.edu

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.

 

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:

  • Data can be made available with little or no control (e.g., white pages directory data).  Many IAM groups are already doing this.
  • Data that can be made available by the IAM group for legitimate university business.  This would likely entail requirements for being "legitimate," as well as operational and security requirements.  For example, legitimacy might require the approval of a dean or department chair.
  • Data that can be made available by the IAM group only after approval by the primary custodian.  (I am including data that cannot be made available by the IAM group here, since the primary custodian can always say no.)


David Walker

On Wed, 2011-12-07 at 09:59 -0600, Jones, Mark B wrote:

  +1   -----Original Message----- From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Hendricks,Rodger E Sent: Wednesday, December 07, 2011 7:54 AM To: IDM@LISTSERV.EDUCAUSE.EDU Subject: 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   HR Academic Personnel (different from HR) Registrar Admissions (different from Registrar) Traffic and Parking ID Card services Libraries Four different flavors of Continuing Education Other outreach (e.g. agricultural extension, certificate programs) Various professional schools Academic 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 > >
I think speaking in general terms is confusing the issue to some extent. We are going to have to talk about specific business needs to debate this in more detail. What I am firmly against is duplicating SOR business logic in the IdM layer. I was not commenting on any reporting use cases that involved more than one SOR. What type of reporting are you thinking about here? By experience I know that the concept of 'current' where it applies to students is very fluid and can depend on many data points, and it is not in my opinion the role of IdM to make sense of what 'current student' means by interpreting student system data. -----Original Message----- From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brian Arkills Sent: Wednesday, December 07, 2011 4:18 PM To: IDM@LISTSERV.EDUCAUSE.EDU Subject: Re: [IDM] Identity data services Valuable service comes from meeting business needs with data, capabilities and an interface. If you pretend there isn't a business need for reporting, then you aren't providing valuable service (so that's out). If you pretend that the business needs can be fulfilled in silos (i.e. each customer must go to each SOR), then you'll be OK for a while until your customers ask questions or have needs which span those silos. For a while, a few of them may *EACH* build their *own* data interface layer between each of the SORs, so they can fulfill their business needs. But at some point (hopefully before they build their own layer) they'll realize that this data integration capability is something that should be run centrally instead of each of them expending resources on it. So at some point, you will need to establish an enterprise identity data model, an enterprise identity data integration layer, and probably an enterprise identity service integration layer. I balk at calling all these valuable architectural components "a layer of indirection" which are a bad idea--in fact, I'm convinced they are a really good idea. I'd also like to challenge your assumption that by having an enterprise identity data integration layer you've removed the direct responsibility and accountability of the owners of SORs. There are certainly many ways that access control and auditing can be accomplished regardless of the actual delivery of the services, so an assumption that by integrating these data sources you've removed those capabilities seems unwarranted. Finally, your example seems to hinge on the assumption that the word "current" must only be represented by a single data point. Seems to me that you build two different data points in your data model. The enterprise business needs call for two different data points, so why can't you have those two data points in a single integration layer instead of having a single data point with different definitions in two separate integration services? > -----Original Message----- > From: Identity Management Constituent Group Discussion list > [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Jones, Mark B > Sent: Wednesday, December 07, 2011 12:11 PM > To: IDM@LISTSERV.EDUCAUSE.EDU > Subject: Re: [IDM] Identity data services > > This really depends on what kinds of reporting you are talking about. > > From a policy perspective, I'm not convinced that it is a good idea to have a > layer of indirection between report consumers and the systems of record. In > my mind it is desirable and appropriate that the owners of systems of record > be directly responsible and accountable for the release of their data. > > We do not interpret SOR business rules. The SOR controls what data we > receive into the registry. Basically we ask HR for a set of data points for all > current employees and the SOR for HR provides that data set. How that data > is extracted from the SOR is the responsibility of the custodians of the HR > system of record. > > Here is an example to talk about... Our Registrar provides IdM an extract of > 'current students'. They also provide reports to the State on 'current > students'. But the definition of 'current student' is different for both. For > IdM the definition is shaped by the needs for access to IT resources. For the > State it is about how many 'students' qualify for the State funding equation. > The definition of 'current student' for the State report could change every > term and has little if anything to do with IdM, and I don't think IdM should be > involved in such reporting or even store the data points needed to generate > the report. > > > > -----Original Message----- > From: Identity Management Constituent Group Discussion list > [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brendan Bellina > Sent: Wednesday, December 07, 2011 12:23 PM > To: IDM@LISTSERV.EDUCAUSE.EDU > Subject: Re: [IDM] Identity data services > > We are faced with the challenge of providing reporting services. We are > migrating both our Payroll system and our Student system and there are > many advantages to having reporting being done against a reporting system > rather than directly against systems of record. Since the registry is the system > that combines identity data from multiple systems of record and maintains > the master identity record, it makes sense that it should be the primary > source for such a reporting system. This is an opportunity to improve the > data quality in the registry and directory, significantly reduce the number of > datafeeds containing PII, and provide a layer of indirection between report > consumers and the systems of record which should reduce the complexity of > migration. Though more complex this is essentially the same as what we > have all already been doing to populate attributes like > eduPersonPrimaryAffiliation that are useful for end user applications but > have no direct correspondence with an attribute in a single system of record. > Anyone populating standard attributes in a directory service is already > interpreting SOR business rules. I don't see this as a fundamentally different > exercise. The scale will be challenging though and extending the governance > model will probably prove difficult as well. If anyone already has an ODS or > Data Warehouse built based on their registry I would be very interested in > knowing what governance structure they have implemented and what kinds > of policies they follow. > > Regards, > > Brendan Bellina > Mgr, IdM > USC > >

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.

 

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:

  • Data can be made available with little or no control (e.g., white pages directory data).  Many IAM groups are already doing this.
  • Data that can be made available by the IAM group for legitimate university business.  This would likely entail requirements for being "legitimate," as well as operational and security requirements.  For example, legitimacy might require the approval of a dean or department chair.
  • Data that can be made available by the IAM group only after approval by the primary custodian.  (I am including data that cannot be made available by the IAM group here, since the primary custodian can always say no.)



David Walker

On Wed, 2011-12-07 at 09:59 -0600, Jones, Mark B wrote:

  +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> >
I'm not suggesting that business logic be duplicated. I'm suggesting that instead of having to rely upon an SOR data expert to get a useful report, the reporting system should contain information so that rport writers only need to know what they want and not be intimately familiar with the data in the SOR. For example, the SOR may have stored major information in this way: Major_1, Major_2, Major_3, Major_4, Major_5 instead of using a cross-reference table. Since that is a physical data modeling restriction and is not relevant to the information needs it should be modeled differently in the reporting system so that the person writing a report doesn't need to know that if he/she wants students with a certain major that the report has to check 5 fields. When you ask the student systems experts for a data feed they probably write the data feed knowing about these things, but if you are providing a reporting system the information has to be accessible without that kind of knowledge. I can imagine many reports that would include people from multiple SOR's. Any report about courses may need to include information about both students and instructors. There may be affiliates who are attending or teaching courses as well. Reports on employees would quite possibly need to include student workers. I agree with you that the student system should define "current student". But it is not always the case that they can or will do so. Resolving that attribute in the registry, as long as it is based on a documented approved definition, is I believe preferable to requiring everyone to rely upon SOR data feeds. Regards, Brendan
So we may not be too far apart... Uncooperative stakeholders can mess up everything. Just keep in mind that your data is not authoritative if not 'blessed' by the owner of the data. We have similar problems but are expecting our Sources of Authority to establish the needed definitions. Is there a difference between what you are calling "the reporting system" and "the registry"? I agree that any data that is consumed from a SOR should be completely de referenced. For instance if you are getting 'gender' you should see values like 'male' and 'female' as opposed to '0' and '1' where you have to know or lookup that '0' means 'male'. I'm not sure if this is what you meant but I don't think that you should have to be "intimately familiar with the data in the SOR" in order to maintain the "reporting system". I see this as duplicating SOR business logic. -----Original Message----- From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Brendan Bellina Sent: Wednesday, December 07, 2011 5:27 PM To: IDM@LISTSERV.EDUCAUSE.EDU Subject: Re: [IDM] Identity data services I'm not suggesting that business logic be duplicated. I'm suggesting that instead of having to rely upon an SOR data expert to get a useful report, the reporting system should contain information so that rport writers only need to know what they want and not be intimately familiar with the data in the SOR. For example, the SOR may have stored major information in this way: Major_1, Major_2, Major_3, Major_4, Major_5 instead of using a cross-reference table. Since that is a physical data modeling restriction and is not relevant to the information needs it should be modeled differently in the reporting system so that the person writing a report doesn't need to know that if he/she wants students with a certain major that the report has to check 5 fields. When you ask the student systems experts for a data feed they probably write the data feed knowing about these things, but if you are providing a reporting system the information has to be accessible without that kind of knowledge. I can imagine many reports that would include people from multiple SOR's. Any report about courses may need to include information about both students and instructors. There may be affiliates who are attending or teaching courses as well. Reports on employees would quite possibly need to include student workers. I agree with you that the student system should define "current student". But it is not always the case that they can or will do so. Resolving that attribute in the registry, as long as it is based on a documented approved definition, is I believe preferable to requiring everyone to rely upon SOR data feeds. Regards, Brendan
Message from dhwalker@ucdavis.edu

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:

  • Enrollment status is synchronized from the student information system on a nightly basis.  Updates must be made through the Registrar's office.  The information will be made available for university business processes upon approval by the Registrar.
  • Electronic mail forwarding addresses are maintained in the identity registry.  Updates may be made through a web interface provided by the IAM group.  The information is available publicly unless the user has opted out; it is available for university business processes upon approval by the IAM group if if the user has opted out of public availability.

David


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.

 

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:

  • Data can be made available with little or no control (e.g., white pages directory data).  Many IAM groups are already doing this.
  • Data that can be made available by the IAM group for legitimate university business.  This would likely entail requirements for being "legitimate," as well as operational and security requirements.  For example, legitimacy might require the approval of a dean or department chair.
  • Data that can be made available by the IAM group only after approval by the primary custodian.  (I am including data that cannot be made available by the IAM group here, since the primary custodian can always say no.)



David Walker

On Wed, 2011-12-07 at 09:59 -0600, Jones, Mark B wrote:

    +1   -----Original Message----- From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Hendricks,Rodger E Sent: Wednesday, December 07, 2011 7:54 AM To: IDM@LISTSERV.EDUCAUSE.EDU Subject: 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   HR Academic Personnel (different from HR) Registrar Admissions (different from Registrar) Traffic and Parking ID Card services Libraries Four different flavors of Continuing Education Other outreach (e.g. agricultural extension, certificate programs) Various professional schools Academic 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 > >

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:

  • Enrollment status is synchronized from the student information system on a nightly basis.  Updates must be made through the Registrar's office.  The information will be made available for university business processes upon approval by the Registrar.
  • Electronic mail forwarding addresses are maintained in the identity registry.  Updates may be made through a web interface provided by the IAM group.  The information is available publicly unless the user has opted out; it is available for university business processes upon approval by the IAM group if if the user has opted out of public availability.


David


 

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.

 

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:

  • Data can be made available with little or no control (e.g., white pages directory data).  Many IAM groups are already doing this.
  • Data that can be made available by the IAM group for legitimate university business.  This would likely entail requirements for being "legitimate," as well as operational and security requirements.  For example, legitimacy might require the approval of a dean or department chair.
  • Data that can be made available by the IAM group only after approval by the primary custodian.  (I am including data that cannot be made available by the IAM group here, since the primary custodian can always say no.)




David Walker

On Wed, 2011-12-07 at 09:59 -0600, Jones, Mark B wrote:

   +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> >
Message from dhwalker@ucdavis.edu

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:
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:

  • Enrollment status is synchronized from the student information system on a nightly basis.  Updates must be made through the Registrar's office.  The information will be made available for university business processes upon approval by the Registrar.
  • Electronic mail forwarding addresses are maintained in the identity registry.  Updates may be made through a web interface provided by the IAM group.  The information is available publicly unless the user has opted out; it is available for university business processes upon approval by the IAM group if if the user has opted out of public availability.


David




 

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.

 

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:

  • Data can be made available with little or no control (e.g., white pages directory data).  Many IAM groups are already doing this.
  • Data that can be made available by the IAM group for legitimate university business.  This would likely entail requirements for being "legitimate," as well as operational and security requirements.  For example, legitimacy might require the approval of a dean or department chair.
  • Data that can be made available by the IAM group only after approval by the primary custodian.  (I am including data that cannot be made available by the IAM group here, since the primary custodian can always say no.)




David Walker

On Wed, 2011-12-07 at 09:59 -0600, Jones, Mark B wrote:

      +1   -----Original Message----- From: Identity Management Constituent Group Discussion list [mailto:IDM@LISTSERV.EDUCAUSE.EDU] On Behalf Of Hendricks,Rodger E Sent: Wednesday, December 07, 2011 7:54 AM To: IDM@LISTSERV.EDUCAUSE.EDU Subject: 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   HR Academic Personnel (different from HR) Registrar Admissions (different from Registrar) Traffic and Parking ID Card services Libraries Four different flavors of Continuing Education Other outreach (e.g. agricultural extension, certificate programs) Various professional schools Academic 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 > >
Close
Close


Annual Conference
September 29–October 2
Register Now!

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.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
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.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.