Where are we now?
The processes and techniques that provide authentication and authorization for the campus community have not changed in many years. These processes are reliant on batch consumption of identity data using WatIAM’s Extract file, direct LDAP authentication against the campus active directory, and the use of CAS for web application single sign-on. While this infrastructure has served the University well for many years, some changes will be required to ensure future needs are met.
In the coming years the University will be introducing a number of new systems and services hosted within the institution and in “the cloud”. Many of these offerings support a protocol known as Security Assertion Markup Language (SAML) for integrating with an organization’s identity and access systems. At the same time, many campus initiatives are looking to introduce processes that will require changes to current identity lifecycle practices, both in its management and its dissemination to campus IT services.
The first project in a larger program to renew identity and access management services is to introduce a SAML identity provider to the campus infrastructure.
Why use SAML?
The University is increasingly employing Software as a Service (SaaS) solutions, also known as cloud applications, that recommend SAML as their authentication method. Deploying a SAML identity provider eases future integrations with these applications, may improve some existing ones, and eliminates the need for pushing user credentials to a third party.
Identity Data Transfer
An identity provider enables modern identity data dissemination. With access to the appropriate data, it should support many use-cases currently being satisfied by WatIAM’s Extract file. An identity provider may be configured to release a specific attribute set for every service provider, allowing transfer of student ID, employee ID, username, email address, and any group memberships that may pertain to the service in question. This allows controlled and auditable transfer of just enough identity data to SAML consuming services in real-time, just-in-time to better manage and protect identities affiliated with the University.
Why start with an identity provider?
A number of campus initiatives call for identity processes that enable much faster identity creation that can only be met by introducing significant changes to the way identity data is handled.
Today, many campus systems rely on WatIAM’s Extract file to link identity data to application data. While the Extract file won’t go away immediately, its continued use will cause significant delays in user provisioning processes as we start making changes to the identity lifecycle to address new and changing requirements. A SAML identity provider is the first piece being offered to provide an opportunity for existing applications to migrate away from WatIAM’s Extract file.
What do I need to do to migrate?
Integrating with a SAML identity provider (IdP) requires the target system to operate a SAML service provider (SP). This implies that every system maintainer will also be operating an SP. Each SP becomes part of the fabric of the identity and authentication infrastructure for the University.
For those running software that already supports SAML authentication, details should be documented for your software and may be quite straightforward. For those systems that do not already support SAML authentication, a SAML service provider component must be introduced into your software architecture. This will require a good understanding of the SAML protocol, the service provider software chosen, and the system being integrated. In some cases additional computing resources may be required in the target system’s environment.
In all cases, detailed dialog with the Information Systems & Technology (IST) Information Security Services (ISS) group is required. An identity attribute set must be determined. The integrator must supply SAML metadata about their service provider installation, and receive metadata about the identity provider in order to configure communication between the two systems. This metadata exchange identifies service endpoints that will enable the service provider and identity provider to communicate and may also contain certificates that enable digital signing and/or encrypted communication of the attributes when appropriate.
A pilot SAML IdP is already being used by Lynda.com and Concur. A production-ready instance is being planned based on experiences from this pilot and should be available this summer.
Contact ISS at any time to begin planning your system’s migration towards this new service.