Migrating Single Sign On to CAS and Shibboleth

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

2. Background: • KU’s original Identity Management system (Account Information Management System – AIMS) was a “home-grown” 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 v1, Identity Provider, via a custom login handler. • These systems comprised the first Single-Sign-On and Federation solutions at KU.

3. 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.

4. 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 NetIQ Identity Manager. • The Argus/Shibboleth implementations were to be replaced with Sun OpenSSO. OpenSSO 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 OpenSSO.

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

6. 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, OpenAM began to exhibit the same stability issues and integration work again halted. • The core problem was that the servers running OpenAM would reach 100% CPU utilization, and then due to the synchronization between the OpenAM 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.

7. 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 OpenAM did not support a load-balanced LDAP environment. That is exactly how KU is configured.

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

9. CAS: Central Authentication Service KU has been running uPortal, 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. CAS provides numerous client library implementations allowing for broader adoption. CAS runs inside the Tomcat container, which allows for better support expertise at KU.

10. 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 v1 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. Shibboleth provides simpler integration with federations like InCommon.

11. 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.

12. 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 • Configure the CAS filters in the “cas-authentication-facade” web.xml suitable for your CAS installation. • Configure the IDP External Login Handler in your IDP’s handler.xml • Add the IDP External Auth Servlet entries in your IDP’s web.xml • Build and copy the resulting .war file to your tomcat webapps and the resulting .jar file to the lib directory in your IDP webapp.

13. The route KU took: • We were in a time crunch: • KU had already devoted a significant amount of time trying to make OpenAM a feasible solution. • Researchers and Scholars were clamoring for federation like InCommon. • 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 uPortal. • Experts in OpenSource products for higher education. • Their statement of work explicitly called out knowledge transfer back to KU staff.

14. 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.