CAS and Shib cohabitation

Owned by Tom Barton
Last updated: Oct 08, 2008Version comment

What guidance can be given to campuses that have deployed CAS but also want to get into federated access scenarios using shibboleth? Are there new capabilities that need to be developed in such cases?

Use cases

There are two main use cases:

1. Have CAS, add shib IdP (& maybe some SPs), no new login presented to users

2. Support federated access to CASified applications (dealing both with authentication & attributes)

Use case 1: have CAS, add shib IdP

  • Protect shib SSO endpoint with CAS
    • This is done now at many places by protecting their IdP's SSO endpoint with CAS.
    • That uses the generic login handler, which does not support fancier authNRequests that SAML2 SPs might request.
    • A CAS-specific handler (for shib 2) would need to be developed to support of nuanced authNRequests from SPs
      • especially important are forceAuthN, isPassive, and specified authN methods
    • Existing Apache module fine for simple, common, needs
    • Use CAS Java APIs for fancier authNRequest needs
    • Google uses isPassive. Most SPs are not known to do anything fancy, yet.
      *IdP & CAS login servers need not be collocated

Use case 2: federated access to CASified applications

One approach: gateway shib into CAS login & keep CAS app-side stuff unchanged. This really only adds value when the campus wants to allow federated access to a CASified application.

  • Policy issues may arise when SAML attributes are pushed into non-SAML agents
    • just tell everyone so they know
  • Essential UX: browser approach CAS-app, redirect to CAS-login, protected by shib-SP, browser redirected to IdP, login, POST SAML artifact back to CAS-login, away you go
  • What to do about users not all coming from same org?
    • Do the ScottC trick to not bother local uses with a WAYF process, ie, when a user first logs in at the IdP, drop a SAML IdP cookie in their browser so that further SPs won't bother to WAYF them.

The group gathered at the session do not know of a campus that is at the point of needing a solution to use case #2, but we all agree to keep on the lookout for one. Readers are encouraged to record their own thoughts about how to deal with this use case on the wiki page mentioned below.

Next steps

ScottS will create a suitable wiki pages in the ja-sig/CAS space to house docs related to CAS-Shib cohabitation.

Eric Pierce will adapt the SWITCH docs on protecting a shib IdP with a web SSO and place them on that ja-sig/CAS wiki page.

John A. Lewis will nag Unicon staff to add to those docs.

Some shib/federation discussion points that arose

  • SAML attributes
    • SAML is a standard for expressing attributes, it doesn't care which attributes
    • Practical experience is to use string values
    • Uneven attribute policies across federations
  • Federation-alia
    • They are not 3rd parties to IdP-SP contracts
    • Simplifies metadata management (trust fabric)
    • Often membership is leveraged to strong-arm vendors into SP-ifying
  • Need a separate session on federation-related Q&A