And what about the session timeout of the local application? I tried a 1 minute session timeout. After the session ends, a new ST is automatically raised again, and I arrived authenticated to the application. Is there a way to avoid this?
________________________________ From: Andrew Petro <[email protected]> To: [email protected] Sent: Wednesday, September 7, 2011 4:45 PM Subject: Re: [cas-user] Proxy tickets (Cas Server 3.x - Cas Client 3.x & 2.x) Do you mean for logging out of your application to terminate the CAS SSO session? Then your application's logout link, after locally terminating the application-local session, should redirect to https://yourcasserver.com/cas/logout to terminate the CAS SSO session. Do you mean for logging out of your application to terminate the application-local session, not terminate the SSO session, and advise the user of this fact? Then after terminating the application-local session, send the user to path *not* protected by the CAS filter so that they can see your message without immediately authenticating to the application again via CAS. A typical such message would advise that the user is still logged in to CAS and invite the user to log out of CAS, presenting a hyperlink to do so. Andrew On 9/7/2011 3:35 PM, Fernando Correa wrote: Thanks Andrew! > > >Let's suppose that I leave renew = false. > > > >All my logout logic is invalidate the session and redirect to a protected >page, to require a new authentication... > > >With renew = false, after a redirect, a new ST is issued, and I arrive >authenticated again to the application... > > >Do I have another option? > > > > >________________________________ >From: Andrew Petro <[email protected]> >To: [email protected] >Sent: Wednesday, September 7, 2011 8:46 AM >Subject: Re: [cas-user] Proxy tickets (Cas Server 3.x - Cas Client 3.x & 2.x) > > >Interesting requirements. > >It's probably the case that setting renew=true on a ticket validation request is ambiguous, and in practice fails validation of proxy tickets, which necessarily weren't issued in immediate response to end-user presentation of primary credentials (username and password). The CAS protiocol specification is ambiguous on this point. My own reading is that renew=true should have no effect for proxy tickets, which would handily allow naive configuration and client library implementation of the protocol to meet your requirements. This seems a good solution since a client library has no way to know whether a ticket is a service ticket or a proxy ticket without validating it, at which point it had to have already decided whether to set renew=true or not, so the protocol should allow both restricting service tickets to renew=true qualified STs and also accepting proxy tickets. That's just my reading into it what I wish where there, though, the specification itself seems ambiguous. > >In practice, the latest CAS server's proxyValidate will enforce renew=true's >requirements on both proxy tickets and service tickets. > >It might be worth tweaking this validation specification to only enforce renew=true where the ticket is a service ticket and not a proxy ticket. I'll forward this over to cas-dev for discussion on that point. > > >Others have locally addressed this use case of CAS providing single sign-on only when used through a portal. The solution to this I'm familiar with doesn't involve or require proxy tickets, rather it constrains in what circumstances CAS will issue the TGT cookie such that one obtains a TGT cookie only when CAS authenticating to the portal. Log in to the portal, enjoy single sign-on to applications -- even if you then directly access those applications rather than following a link from the portal. Don't log in to the portal, you can use CAS to sign in to each application, but you won't have the TGT cookie so you won't have a single sign-on session so you'll have to present credentials to log in via CAS to each successive application. > >In this approach, the portal provides the context for end-user understanding of single sign-on -- while it's CAS doing the work, a user can roughly understand that if they log in to the portal, they get single sign-on and especially need to terminate their browser session when they're done; if not, they don't get single sign-on, and cleaning up that "portal session" is less critical. And then the portal can have appropriate branding, messaging about logging out and closing the browser etc. > >In general, putting proxy tickets on URLs that end users can see is weird and not the way CAS is commonly used. Proxy tickets are for back-end authentication directly between portal and backing services. If you need the end user browser to experience single sign-on in accessing an additional application, service tickets are sufficient to the task, though you may need to tweak under what circumstances you allow users to participate in single sign-on sessions if you want them to enjoy single sign-on only sometimes. > >Best wishes, > >Andrew > > >On 09/03/2011 12:33 PM, Fernando Correa wrote: >I want to generate access links from my portal to my web applications. Some of >them are using cas client 3.x and the rest are using cas client 2.x. Cas >Server is 3.X. >> >> >>The correct way to access the applications if through proxy tickets generated >>from the portal. If someone knows the URL of the web application and put it >>in the browser, I want to require an authentication (renew = true I think). >> >> >>If I generate a proxy ticket and use it with cas client 2.x with renew = >>false, it works perfect. But If I put renew = true, it doesn't work (I get >>a javax.servlet.ServletException: CAS authentication error: >>INVALID_TICKET...) and the cas server log says something like "Ticket does >>not satisfy validation specification). >> >> >>If I generate a proxy ticket and use it with cas client 3.x with renew = >>false (in both filteres), it works perfect. If I put renew = true in >>validation filter, it works fine only in the first access. After that, I >>logout from the application (session.invalidate()), and the proxy tickets >>generated from that moment don't work (it says like I'm trying to validate a >>proxy ticket like a service ticket or I'm not respecting the renew = true). >> >> >>Any help? >> >> >>Thanks! >> >> >> >> >> >> >>-- 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
