On Tue, Oct 13, 2009 at 10:05 PM, <[email protected]> wrote: > Thanks Scott, I feel like I'm on the right track now. Upon a validation > success, the application receives the username through plain text from CAS. > How does the Ticket Granting Cookie come into action from here?
It doesn't. An SSO session is generated when the user authenticates for the first time (which means sending the cookie to the browser). > > > > > Quoting Scott Battaglia <[email protected]>: > > On Tue, Oct 13, 2009 at 8:45 PM, <[email protected]> wrote: >> >> This is helpful for clearing up a bit of my confusion, but I'm >>> wondering how exactly the webapp could validate a CAS-enabled webapp >>> session. I understand that the browser receives a "Ticket Granting >>> Cookie", TGC, of which is mentioned little about in the architecture >>> docs and is also an optional component of a CAS system. To present >>> the appearance of SSO, the TGC is required. The Service ticket, the >>> thing that expires as soon as it is used, validates the session on the >>> CAS-enabled webapp. >>> >> >> >> >>>>>> >> Upon success with the validation of the service >>> ticket, a TGC is sent to the browser. >>> >> >> <<<<<< >> >> I'm not sure where you saw this but its not true. When a user comes to a >> CASified application that he has not logged into yet, he is redirected to >> CAS. One of two things happens. 1. If no SSO session exists he is >> prompted >> for his credentials, and on successful authentication, a SSO session is >> established or (2) the server recognizes an existing SSO session. In >> either >> case, a Service TIcket is issued for that service that made the original >> redirect. CAS tells the browser to redirect to the application with the >> Service Ticket. The application sees the Service Ticket and makes a >> validation call to CAS. If the validation is successful, the application >> will receive the username and is then able to establish its local >> application session. >> >> Cheers, >> Scott >> >> >> >> >> The existence of the TGC seems >>> to be a clue into the world of validating a CAS-enabled webapp >>> session. Is this how an CAS SSO solution is supposed to work? >>> >>> >>> >>> Quoting Marvin Addison <[email protected]>: >>> >>> >>> Perhaps unnecessary redirects, redirects that >>> >>> happen when a user is logged in already, could be avoided by storing >>> data >>> >>> via the session with the webapp? >>> > >>> > I think we need to clarify what session you mean. The SSO session or >>> > the session of the CAS-enabled Web application? Assuming you mean the >>> > webapp session, then most CAS clients do store authenticated state to >>> > prevent unnecessary redirects to CAS every time. Note that this >>> > client feature is entirely optional; CAS has full support for >>> > stateless authentication scenarios. >>> > >>> >> I think a better question would have been: Where in the CAS >>> architecture >>> >> does session validation take place? >>> > >>> > Again, assuming you mean validating the authenticated state of a >>> > CAS-enabled webapp, then it's not formally part of either the protocol >>> > or the CAS architecture per se. Most CAS clients store the >>> > authenticated state to prevent redirects other than on session >>> > creation. >>> > >>> > 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 >>> >>> >>> >> -- >> 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 > -- 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
