CAS Federation Across Multiple CAS Domains for Browsers and REST Clients David Ohsie, EMC Corporation ([email protected]) John Field, Pivotal ([email protected]) Vijaya Bharadwaj, Pivotal ([email protected])
EMC is a Apereo Commercial Affiliate EMC ships CAS embedded in software (and later) some hardware platforms in order to integrate software into a coherent whole The three authors (David, John, Vijaya) work on CAS adoption across EMC products I (David) participate on the CAS user list and the CAS appsec working group
Cases Hierarchical/User Visible Federation – One or more independent CAS instances – User selects which one they want (some similarity in concept to openid, SAML federation) Federating CAS instances across Datacenters (Peer-Peer Federation) – You have two sets of applications in different datacenters, but want to SSO between them – Could also be used for HA – See “High Availability in Hurricane Alley - Multi- site Multi-node CAS Deep in the Heart of Texas” Srinivas Varadaraj, Bill Thompson (use google)
(Hierarchical) Federation Element Manager w/CAS Element Manager w/CAS Portal App w/CAS Client 1 2. Link and Launch Element Manager 1. AccessPortal Client 2 3. Directly Access CAS Enterprise AD/LAP
Element #1: CASified CAS Client Portal Cluster Portal Portal CAS Element Manager Cluster EM CAS mod_auth _cas Element Manager Assume SSO session is already established with Portal CAS 1. Element Manager 302 to EM CAS 2. Request ST 302 to Portal CAS 3. Request ST From Portal CAS 4.Request ST with Ticket; 302 to EM 5.Request To EM With ST From EM CAS mac
Element #2: CAS Whitelist Client can request which CAS server he would like to use – https://em.emc.com/?casHome=LOCAL – https://em.emc.com/?casHome=PORTAL mod_auth_cas client has whitelist – CASWhitelist LOCAL https://emCas/cas/login https://emCAS/cas/samlValidate – CASWhitelist PORTAL https://portal/cas/login https://portal/cas/samlValidate
whitelist continued In “default” mode, the cas client will extract and copy the casHome parameter: – GET https://em.emc.com/?casHome=PORTAL – 302 Location: https://emcas.emc.com/login?service=https%3A %2F%2Fem.emc.com%2F&casHome=PORTAL In “federation” mode, casHome tells the CAS client where to forward to and where to validate the ticket. The underlying CAS is configured to accept remoteUser, but produce a login screen if the remoteUser is not populated.
via LOCAL cas server Client Portal Cluster Portal Portal CAS Element Manager Cluster EM CAS mod_auth _cas 1. Element Manager 302 to EM CAS casHome= LOCAL 2. Request ST casHome=LOCAL 3.Request To EM With ST From EM CAS Element Manager mac
CAS Server Protected Service X-EMC-CAS-V2: TRUE POST https://app.com/ 401 WWW-Authenticate: X-EMC-CAS-V2 realm=”EMC CAS” Location: https://cas.com/cas/login?service=https://app.com&casAction=login GET https://cas.com/cas/login?service=https://app.com&casAction=login 302 Location: https://app.com/?ticket=ST-12345-10.1.1.8&casAction=login GET https://app.com/?ticket=ST-12345-10.1.1.8&casAction=login 204 Set-Cookie: MOD_AUTH_CAS_S=sldkf0fj498 CAS REST V2 Interaction 401 WWW-Authenticate: Basic realm="CAS" GET https://cas.com/cas/login?service=https://app.com&casAction=login Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Now that the user is Authenticated the POST can be repeated
are we so far CAS client can be configured with list of trusted CAS servers Client can determine which CAS server to access with casHome query parameter How do we deal with the “peer-to-peer” case where the client doesn’t care
Make no assumptions about the deployment of load balancers Non-Constraint: no updates to CAS clients Thus, we need to take an “opposite” approach.
Element #3: CAS_DEFHOME Domain Cookies When a user is successfully logs into a CAS server, there server sets the CAS_DEFHOME cookie as a “domain” cookie (e.g. emc.com) – Domain cookies leak information, but the information here seems relatively benign When mod_auth_cas sees CAS_DEFHOME, it forwards to that CAS server (if on the whitelist) with gateway=true
Issues HA across datacenters – Set-Cookie: CAS_RETRIES=1 – Maybe you should be using an intelligent load balancer Stickiness of the CAS_HOME query parameter
Service Whitelist If a CAS client is accessible via multiple host names, then a CAS service whitelist can be used. The HOST header is matched against the whitelist; if there is a match it is used, otherwise the default is used
Use Cassified CAS to enable CAS login/validation to be directed elsewhere Use casHome query parameter to pick cas location off of a whitelist Use CAS_DEFHOME domain cookie to enable selection of CAS server when any one is good enough