Yes, right now it only acts as an IdP. Its most likely possible for it to work as a SP. We'd need some help with that though ;-)
-Scott -Scott Battaglia PGP Public Key Id: 0x383733AA LinkedIn: http://www.linkedin.com/in/scottbattaglia On Fri, Jun 20, 2008 at 10:30 PM, tedzo <[EMAIL PROTECTED]> wrote: > 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 > >
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
