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 <http://www.jasig.org/cas/protocol> 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 > <https://source.jasig.org/cas3/tags/cas-server-3.4.10/cas-server-core/src/main/java/org/jasig/cas/validation/AbstractCasProtocolValidationSpecification.java>. > > 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 [email protected] >> <mailto:[email protected]> as:[email protected] >> <mailto:[email protected]> >> To unsubscribe, change settings or access archives, >> seehttp://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
