> 1: A user selects an application URL > 2: The "IdP filter" at the application URL redirects the user to the > identity provider > 3: As the IdP is protected by a CAS client filter, the filter redirects > the user to CAS > 4: CAS provides the authentication (login form, Kerberos, etc.) > 5: The CAS redirects to the IdP, the CAS client filter now let the > request pass to the IdP. The IdP now issues the requested artifact and > redirects to the application > 6: the IdP filter at the application validates the artifcact and lets the > request pass to the application
Correct, except in steps 2 and 6 the name of the component is the "Service Provider" (SP) in SAML terms. > So you're saying that CAS is being used as an authentication service > only that protects the shibboleth instance. Shibboleth is then used as > an IdP to implement federated SSO protocols, e.g. SAML? See https://spaces.internet2.edu/display/SHIB2/IdPUserAuthn for info about setting up IdP authentication for the Shib 2.x IdP. The Remote User mechanism is the one that lets the authentication be handled by the container, which can use some other SSO scheme such as CAS. This kind of chaining approach is very popular, and may become more so as organizations find themselves needing to support different authentication schemes with various partners. Chaining has some limitations, but it can work without disturbing an existing SSO service which is very appealing. Here at the UW we've been running our Shib IdP chained to our Pubcookie web SSO service for years. Since we have hundreds of local Pubcookie-enabled apps it will be years before we can fully transition to SAML/Shib. - RL "Bob" _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
