Single Sign-On Interoperability Scenarios

SSO Interoperability Scenarios

Over the past several years many institutions have already embarked upon Single-Sign-on rollouts using a number of open-source and vendor provided systems. The Single Sign-On platform is capable of interoperating with these  systems in certain recommended architectural deployments, though full-functionality may be subject to deployment/configuration constraints.

Jasig^® Central Authentication Service (CAS^®)

Schools with existing Jasig^® CAS^® infrastructure can leverage those services under two scenarios.

• The institution integrates Single Sign-On as a standard CAS^® application, and implements its own SSO solution independent of the portal, without leveraging the full capabilities of the Single Sign-On  
• The institution deploys the Clearpass extension, and can leverage both their existing CAS^® server as well as the Single Sign-On Quicklaunch  integration framework.

In either scenario above, the institution would be responsible for supporting and maintaining its own SSO infrastructure. The second scenario would also require the institution to support the Clearpass extension (see references) to allow the Quicklaunch framework access to the user’s credentials.
Without access to the user’s credentials, Quicklaunch is typically limited to integration scenarios: 1, 2 (unless the vendor API requires user credentials), 3a, 4. This may have impact on a number of the out-of the box supported SSO integrations.

Shibboleth ^®

Shibboleth ^®(a project of the Internet2 consortium) has been deployed in a number of institutions interested in federation, attribute based authorization, and standards compliance with SAML. The scenarios for integration with Shibboleth ^®are similar to those above for CAS^®, namely:

• The institution integrates Single Sign-On  as a standard Shibbolized^® application, and implements its own SSO solution independent of the portal, without leveraging the full capabilities of the Single Sign-On Quicklaunch framework. (note: Single Sign-On  does not currently natively support authorization leveraging Shib attributes)  
• The institution deploys the Single Sign-On  CAS^® server to authenticate to the Shib IDP, with Single Sign-On  leveraging CAS^® as an internal SSO mechanism, allowing the institution to leverage both their existing Shib server as well as the Single Sign-On  CAS^® and Quicklaunch integration framework. (note: Single Sign-On  would serve to authenticate all Shib requests in this scenario) In effect, this approach CAS^®ifies the Shib server.

The second scenario in particular allows for a combination of SSO for both environments, and is easily supported in the standard Single Sign-On  configuration (if CAS^® is used as primary auth). Some more details are described in the References section at the page listed under: CAS^®-Shib^® Cohabitation.

For more information about myCampus Single Sign-On, please send an e-mail to membership@campuseai.org