Guimaraes, Patricia (NIH/NLM) [C] escribió: > Also, as I understand it, authentication via the web browser works by > having the application server redirect the client to the CAS server to > authenticate the user _for __the__ specifi__ed__ service_. The CAS > server then authenticates the user and adds the _TGT __for the specified > service_ to a cookie in the client’s web browser. So, I am assuming > that the _TGT in the cookie is only valid __for__ the specified > __servi__ce_. Is that correct?
As I understand it, when you login using the login form (authentication via web browser) you get back a TGT in the cookie. But if you're being redirected from a service, and you're passing the service parameter to the login form, then you get a TGT in the cookie if you didn't have one, and you're redirected back to service with ticket (a Service Ticket - ST) being passed as a parameter. http://app/ -> redirects to http://cas/login?service=http://app/ -> upon login, TGT gets added to the cas cookie -> and user gets redirected to http://app/?ticket=ST Either your app or mod_auth_cas can validate that ST. If you access another app, say http://app2/, then you're redirected to cas but cas finds the TGT on the cookie and, if SSO is enabled, you get a ST back and a redirection to your application. http://app2/ -> redirects to http://cas/login?service=http://app/ -> TGT is found on the cas cookie -> and user gets redirected to http://app/?ticket=ST In my experience, since I 'outsource' login to a module of mine, the TGT is not being stored, so the major issue I have is users having to login to each application, which is not that annoying in my scenario. And also note this breaks the original CAS logic. -- José Miguel Parrella Romero (bureado.com.ve) PGP: 0×88D4B7DF Debian Developer Caracas, VE/Quito, EC -- 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
