But you probably shouldn't configure the ST to be multiply validatable (as opposed to just one-time-use).
CAS is an authentication broker, not a session manager. So, your application (or the end user) can use an ST once to log in to an application. Great. But then that application should establish a traditional cookie-mediated web application session (for the end user) or participate in some reasonable web service authentication regime (for service-to-service calls). One option would be for the application to itself continue to accept the ST as a lightweight adhoc session identifier. Spring Security provides support for this. In the case where your application is using this ST to access a web service directly. So, yes, you can configure an ST to be longer-lived and multiply-usable, in CAS ticket expiration policy configuration. And you probably shouldn't be needing to do either of those configuration changes. Hope this helps, Andrew On Fri, Oct 19, 2012 at 4:50 PM, Dmitriy Kopylenko < [email protected]> wrote: > > > > Is there any way to config cas not to throw away ST. Instead make is valid > for a period of time?**** > > ** ** > > Yes, that is possible by configuring serviceTicketExpirationPolicy: > > > https://github.com/Jasig/cas/blob/master/cas-server-webapp/src/main/webapp/WEB-INF/spring-configuration/ticketExpirationPolicies.xml > > Cheers, > Dmitriy. > > > ** ** > > *From:* Andrew Petro [mailto:[email protected]] > *Sent:* Friday, October 19, 2012 2:15 PM > *To:* [email protected] > *Subject:* Re: [cas-user] Can yo manually set CASTGC cookie manually > (httpservletrsponse) to a different domain**** > > ** ** > > Richard,**** > > ** ** > > By design, only CAS can set and read the CAS ticket granting cookie. This > is important to the security of using CAS, since if your CAS TGC was > readable more widely (by, say, your application on a different domain), > then applications able to read the cookie could read it and use it to craft > their own requests to get service tickets in the name of the user. That > is, this would enable illicit delegation.**** > > ** ** > > So. What are you trying to do? The RESTful API is more intended for your > application to authenticate as itself to get a TGT to obtain STs > authenticating itself to other services. If you want to be authenticating > end users, then the intent of the CAS design is for your application to > send those users to CAS to log in to CAS directly, obtain a ST to log in to > your application, and then your application can obtain a PGT from that if > you need to be getting PTs to authenticate to other applications on the > user's behalf.**** > > ** ** > > Hope this helps,**** > > ** ** > > Andrew**** > > ** ** > > On Fri, Oct 19, 2012 at 2:46 PM, Richard Yang <[email protected]> wrote:*** > * > > I am calling cas Restful API to generate a TGT. I would like to store this > as the valie in the **** > > CASTGC. But the domain of my application is different from that of the cas > server. So can I foul the cas server to make it think this is a valid > cookie?**** > > **** > > Otherwise, I had to generate a ST for each service request > programmatically using Restful api. This approach has its drawback as it > involves application code to manage the ST.**** > > -- > 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
