Table of Contents
Was IdM implemented around existing systems/infrastructure or was it "clean slate"?
We have implemented two iterations of IdM, both developed in-house. The first implementation was completed in 1994. The second implementation was a complete rewrite and implemented in 2003; we continue to enhance and improve it. UH is a member the TIER project. We anticipate components of this project augmenting or replacing elements of our IdM as the TIER components mature.
Our IdM integrates with Banner, PeopleSoft, Kuali and other Systems of Record. For authentication we utilize CAS3 and are in the process of implementing CAS via Shibboleth version3. Our IdM maintains LDAP and AD directories.
The overview of our IAM Services should give you an idea of our overall IAM infrastructure (overview).
How long have you been doing "it" and what are some of the lessons you learned?
We've been working in this space since 1994 and the stakes have become significantly higher ever since. While our initial scope was IdM, nowadays it must be IAM. Identity management is the core function, but modern business requirements include access management too. The business drivers include compliance, audit-ability, access to cloud and federated services, single sign-on, enterprise deprovisioning, etc.
If you are starting from scratch, you may be very interested in the work of the EDUCAUSE IAM Program Project Team. They are creating a template for implementing IAM. The purpose of the template is to provide campuses with a roadmap and to also help ensure that the campus understands what policy frameworks should be in place. The roadmap will help you to clearly define what you want in the end product and it will help with identifying the key drivers for the project, your campus landscape, stakeholders, etc. There is a lot that has to be lined up to make the project successful and to ensure that it doesn’t painfully drag out over too much time.
Slides from recent webinar:
An additional lesson to consider: as your IAM infrastructure grows in sophistication you will need to ensure that you are keeping your IT managers and developer community well informed and well supported so that they can leverage the new solutions. If you are a small, highly centralized IT shop this won’t be hard, but for a large institution that disperses at last 50% of its IT staff to the departments, we’ve had to work extra hard to cultivate a well-informed IT community. We utilize a wiki space, a LISTSERV list, and regular meetings that include food. Basically, the IAM group must also become IT evangelists (forum).
Have you implemented federated directory? From the start?
We have been running Shibboleth for many years and are members of the InCommon Federation. Shib is also used for authentication to Google Applications for Education.
What are your account retention policies?
Accounts are never recycled and for most users, as long as they do no evil, their accounts can last for the rest of their lives. Our IAM has business rules that ensure that all accounts are subject to a life cycle. If a person is not currently in one of our SoRs, then she must annually renew her account since we have no other way to determine if she is still using it. We send reminder email with an embedded renewal token.
How do you avoid duplicate identities?
We don't, but we are continually working toward reducing the rate of creation. Training and good IdM tools to help identify potential duplicates help. We have determined that the vast majority of duplicate entrees are introduced by our student information system; the higher your number of foreign students (no SSN) the greater the chances of duplication. We are currently investigating the use of heuristics that identify new entries that have a high probability of duplication so that we may flag them for our Help Desk to follow up before we create a new record in our Person Registry.