Scott, Thanks for the clarification. Very helpful. Ok, I think I understand. You say that Cas can only send a Saml response. So, that basically means that it can act as an IdProvider only, not ServiceProvider (understandably). I somehow thought/assumed that when a user attempts to access a Cas protected resource, Cas would of make a saml request to some entity, parse the saml response from that entity and allow access to the protected resource based on the response. That means Cas would have to trust another entity about the identity of the user, which you say does not happen. Would you kindly correct me if my understanding is wrong? Thanks again for your time and effort.
----- Original Message ---- From: Scott Battaglia <[EMAIL PROTECTED]> To: Yale CAS mailing list <[email protected]> Sent: Friday, June 20, 2008 5:34:14 AM Subject: Re: Understanding saml support As of right now CAS only supports sending a response via SAML (and it should handle the Browser/artifact profile). This was done to facilitate the sending back of attributes in a standard format. It does not go out and retrieve SAML requests from others, nor does it trust others to tell it who the user is. CAS4 is looking at federation use cases (whether its SAML, OpenId, etc.). If you need federation, I would recommend running a combination of CAS/Shibboleth. Both have their use cases and merits and can play nicely together. On Thu, Jun 19, 2008 at 9:15 PM, tedzo <[EMAIL PROTECTED]> wrote: Hello, I am trying to understand how exactly CAS supports saml in the context of SSO using saml and I am confused. The way I see it- 1. User logs into some application (App1) by providing username/password. 2. User is redirected to an application protected by cas while working on App1. At this point, for true SSO, Cas should make a saml request and parse the saml response and figure out the username and allow access (or deny I suppose) OR Cas is posted the saml response during the redirect and it parses the response and figures out the username and allows/denies access. This is kind of similar to the Browser/POST binding I think (in saml 1.1) which requires a well known end-point called "samlConsumer". So what exactly happens? >From what I see, - user is redirected to cas loginUrl due to AuthenticationFilter. - User presents username/password, ticket is issued etc. - Saml11TicketValidationFilter appears to make a saml request to the server. - Saml10SuccessResponseView responds with saml describing user attributes. - Saml11TicketValidationFilter parses the response, gets the user information and redirects to destination. If I have configured the AuthenticationFilter, I am always going to be redirected to the login page. How do I tell Cas to not go to the login page but to obtain a saml response and parse it to find the user information? I think I am thoroughly confused now. Appreciate your thoughts. Thanks. _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
