UI Passport

UI Passport is a Microsoft Passport-like (I just dated this project) tool that provides central authentication services to web applications at The University of Iowa. Any web application can plug into UI Passport and use UI Passport to authenticate a user against their hawkid and hawkid password.

The technology is based on an early version of Yale's Central Authentication Service. The protocol is the same, we have just heavily modified the authentication engine to line up with our needs. We have also heavily modified the service support to allow service clients to have their own customized login page. Through this customization, we also provide service specific information back to callers, and setup the SSO trust relationships that are in place for some services.

Features and Functionality

• A generic web service that handles authentication and can be used by any web based technology in any development language.
• Supports a "brand-able" login page, so that applications can tie into the service yet still maintain their own online identity.
• Single sign-on (SSO) support. The service can be configured to establish trust relationships between services allowing users to be logged in automatically to a service once they have had an initial login.
• User tools to lookup their hawkid, integration with password changing and resetting tools.
• Administrative password reset tools, which pulls information from a variety of sources (student records, HR, etc...) so that phone operators can quiz users who call in wanting password resets.
• Extensive logging, so we can track down any problems which might get reported.

Challenges and Lessons Learned

Integration with Microsoft Active Directory and our unique forest setup was challenging. We have multiple domains in our AD setup, and a Person attribute defines which domain is a person's "primary" domain. The login process is smart enough to head out to the Microsoft global catalog, look up this attribute and authenticate to the proper domain automatically. We don't require the user to enter domain information when logging in - just their hawkid and hawkid password.

Reliability and performance are obviously important. All significant (in size) web applications authenticate through this service. If it is not available for any length of time, that effectively disables all web applications on campus (ISIS, HR, Library, etc...). It is important that it remain available 24x7, 356. Making even minor changes to a critical system that handles 100k logins a day has to be done with some care.