Table of Contents

Was IdM implemented around existing systems/infrastructure or was it "clean slate"?

We have implemented two iterations of or identity management system, both developed in-house. The first implementation was completed in 1994. The second implementation, known as UHIMS, 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 enterprise authentication we utilize CAS and for federated authentication we utilize Shibboleth with CAS providing the user interface. Our IdM maintains LDAP 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:

http://www.incommon.org/docs/iamonline/IAM_Online_2012_10_10.pdf

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 a Shibboleth IdP service for many years and are members of the InCommon Federation. For a list of our Shib attribute release policies visit:

<Shibboleth IdP Single Sign-On#PartyApps-CurrentlySupportedServiceProviders>

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 identity management system 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 emails with an embedded renewal token.

How do you avoid duplicate identities?

We aren't entirely successful, 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 the number of foreign students (no SSN) the greater the chances of duplication.