Migrating Single Sign On to CAS and Shibboleth

Migrating Single Sign On to CAS and Shibboleth George Hosler Information Technology 5/29/2013

Background: • KU’s original Identity Management system (Account Information Management System – AIMS) was a “homegrown” implementation processing batch feeds from our Student, and HR systems. As well as feeds from KU Continuing Education and the KUMC Campus. • AIMS utilized a custom-developed Single-Sign-On solution called Argus. • Argus was integrated into a Shibboleth v 1, Identity Provider, via a custom login handler. • These systems comprised the first Single-Sign-On and Federation solutions at KU.

But over time: The AIMS/Argus/Shibboleth systems began to show their age • A number of unmaintainable business processes made AIMS more and more difficult to support. Staffing changes, and poorly documented processes led to it’s ultimate demise. • Argus provided client libraries for Perl and Java, but never grew to provide support for other languages. • The Shibboleth Identity Provider was never upgraded, and became difficult to support and continue adding federated integrations.

The solution: In 2009 KU launched an effort to implement a new Identity Management solution • AIMS was replaced with an installation of Novell Identity Manager, now Net. IQ Identity Manager. • The Argus/Shibboleth implementations were to be replaced with Sun Open. SSO provided SAML responses, so the plan was to no longer utilize a separate Shibboleth Identity Provider. • The new systems were implemented, and the project team set out migrating web applications to utilize Open. SSO.

But… We had the Identity Manager processing data from our systems of record, and provisioning accounts downstream, however Open. SSO began exhibiting stability problems. • After the Oracle acquisition of Sun, Oracle made the decision to discontinue Open. SSO. We were on the latest release, with no upgrade or patches. • The Open. SSO code base was picked up by the Forge. Rock group and released as Open. AM • So, to address our stability issues, and apply some patches, KU implemented Open. AM.

Of course the upgrade resolved everything, right? At first the new installation appeared to be completely stable, and the team proceeded with additional integrations: • However, once we started adding large scale systems, Open. AM began to exhibit the same stability issues and integration work again halted. • The core problem was that the servers running Open. AM would reach 100% CPU utilization, and then due to the synchronization between the Open. AM instances, all of the production servers would become unresponsive. • After additional exhaustive investigation, KU engaged consultants to assist us in determining root cause of this problem.

Root Cause: Load Balanced LDAP Servers • The consulting firm spent about a week reviewing our installation and configurations. • They provided suggestions on changes that should resolve our stability issues based on “best practices”. • The suggestions were implemented, and nothing changed. • The consultant assigned to our case left the company, and no one else was assigned to us. • In the meantime one of my staff came across a mailing list post describing how Open. AM did not support a load-balanced LDAP environment. That is exactly how KU is configured.

Back to the drawing board… Aside from stability, Open. AM had other challenges: 1. It ran inside Glassfish. KU did not have any other Glassfish installations, limiting in-house support capacities. 2. The Open. AM clients required special installation packages, not just a simple library or module to add on. 3. For Java web applications, you could not “hot-deploy” war files, resulting in a full service outage when deploying updates. 4. The Open. AM server could not serve SAML v 1 responses and could not be easily integrated with legacy applications. 5. We were encountering problems integrating Open. AM with In. Common federation, delaying rollout of In. Common at KU.

CAS: Central Authentication Service KU has been running u. Portal, from Jasig – now Apereo, since fall 2003. CAS is another Jasig/Apereo product, so we were already familiar with it. Additional information: http: //www. jasig. org/cas As a common SSO solution in the higher education community, many of the products in the higher education space are already designed to integrate with CAS provides numerous client library implementations allowing for broader adoption. CAS runs inside the Tomcat container, which allows for better support expertise at KU.

Shibboleth: KU was already running an older version of Shibboleth, so there was “some” basic in-house knowledge. The Identity Provider could be configured to provide SAML v 1 responses for easier integration with older applications and Service Providers. As with CAS, many of the products common to higher education are already designed to integrate with Shibboleth provides simpler integration with federations like In. Common.

CAS and Shibboleth: Both implementations are Open Source products with active communities behind them. Both products are a better fit for KU’s core architecture. Most importantly, the Shibboleth Identity Provider can be configured to utilize CAS for login, allowing for complete integration. Achieving Single-Sign-On so that users logging into a CAS protected site won’t be prompted again for authentication when they visit a Shibboleth protected site, and vice-versa.

How do CAS and Shibboleth integrate: There are several options, KU utilized the “Shibboleth IDP External Authentication via CAS plugin” option: https: //github. com/Unicon/shib-cas-authenticator 1. Configure the CAS filters in the “cas-authentication-facade” web. xml suitable for your CAS installation. 2. Configure the IDP External Login Handler in your IDP’s handler. xml 3. Add the IDP External Auth Servlet entries in your IDP’s web. xml 4. Build and copy the resulting. war file to your tomcat webapps and the resulting. jar file to the lib directory in your IDP webapp.

The route KU took: We were in a time crunch: • KU had already devoted a significant amount of time trying to make Open. AM a feasible solution. • Researchers and Scholars were clamoring for federation like In. Common. • Maintaining multiple SSO systems had become a major undertaking. KU engaged Unicon to implement CAS, Shibboleth, and transfer knowledge back to KU staff for ongoing support: • Unicon worked with KU on the early efforts for u. Portal. • Experts in Open. Source products for higher education. • Their statement of work explicitly called out knowledge transfer back to KU staff.

Future areas of focus: • Two factor authentication – Many two factor authentication solutions integrate directly with Shibboleth. However, integrating CAS has introduced a complication. KU needs to do some additional research on how to best integrate two factor solutions with our SSO implementation. • ADFS – Services utilizing Active Directory Federation are becoming more common. Other institutions have successfully integrated ADFS into their SSO solutions, we need to investigate how this was done so we’re ready. • One-Stop-Shop Portal – Rolling out new functionality to the web is resulting in “application sprawl”. Users are becoming confused about “where to go”. To help solve this, KU has launched an effort to route all general-user traffic through our portal. Having SSO options for all general use campus applications is a key factor to making this work.