On Thu, Sep 29, 2011 at 10:02 AM, Marvin Addison <[email protected]> wrote: >> isn't that what CASShib does...takes a SAML assertion from a >> Shib IdP and >> translates that into CAS ST for the downstream service? > > Everything I have read indicates that CAS is the IdP in this case and > CASShib acts as a proxy for Shibbolized _services_ (Shib SPs) to > perform authentication and attribute release services using CAS as the > IdP. I read the link you cited and I simply don't see anything that > claims it has the capability to proxy assertions from other IdPs.
Klas asked, "How would you configure CAS to work with a SAML-authentication ticket issued by an external IdP? (i.e. supporting a federated login scenario)." One possible interpretation of this is the following flow: 1) user requests access to a casified resource (that is ready to accept attributes and possibly scoped ids) 2) user is redirected to CASShib for authN (/casshib/shib/myservice/login) 4) user is authenticated to CASShib via external Shib IdP 5) CASShib redirects user back to the resource with a ST and ultimately provides the scoped Id and user attributes via CAS/SAML1.1 validate Make sense? Bill > > M > > -- > You are currently subscribed to [email protected] as: [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
