> Does It mean that the validity is into the cookie ? The cookie simply contains the value of the ticket-granting ticket identifier, which is presented to the server on each request. The server manages all state information, and expires the cookie once it fails to meet the expiration policy criteria.
> OK. If I understand well, does a service request the server to > validate the user ticket-granting cookie, for each user requests ? When a user attempts to access a CAS-enabled service, the service redirects him to the CAS server for a service ticket. At that time the ticket-granting ticket (TGT) in his cookie is presented to obtain a service ticket. If the TGT is valid, its usage information is updated and the user is sent back to the original service via 302 redirect with a service ticket appended to the querystring. If for any reason the TGT is invalid or does not exist, the user must authenticate to the CAS server in order to obtain a service ticket. CAS-enabled services only care about service tickets. > During this process, I suppose that session lifetime is updated, > doesn't it ? Correct, but the usage information would only be used to determine validity for an expiration policy that cared about usage, like sliding expiration. > Great. My service should use the ticket-granting ticket to retrieve > different informations about the user ? You don't have to make a special request for this information. You simply configure your CAS clients to request the SAML protocol for ticket validation, and a payload like the sample response mentioned in http://www.ja-sig.org/wiki/display/CASUM/SAML+1.1 will be returned. The client will extract the attributes and make them available to the application, e.g. via session data. Note not all CAS clients support SAML, but the major ones (Java, PHP, .NET) do. 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
