What should the behavior of renew=true be when validating proxy tickets against /proxyValidate?
It seems to me that the CAS protocol specification is ambiguous on this point I suggest that renew=true should affect only Service Ticket validation and having no effect on Proxy Ticket validation, since I'm not sure what it would mean for an end user to have to present credentials to acquire a proxy ticket (end users don't acquire proxy tickets) and the protocol affords no way to distinguish service tickets from proxy tickets without validating the ticket, which is already too late to have decided whether to set renew=true to constrain the sort of service ticket that's acceptable. (And the protocol affords no way to differentiate renew=true-worthy from renew=true-unworthy service tickets but for setting the parameter on the validation request and thereby requesting that the server enforces this.) Interpreting renew=true as affecting only Service Tickets seems to make the right outcomes shake out, since if a client doesn't want to accept proxy tickets, they can simply use the /serviceValidate endpoint. Andrew -------- Original Message -------- Subject: Re: [cas-user] Proxy tickets (Cas Server 3.x - Cas Client 3.x & 2.x) Date: Wed, 07 Sep 2011 07:46:53 -0400 From: Andrew Petro <ape...@unicon.net> To: cas-u...@lists.jasig.org 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 tocas-u...@lists.jasig.org as:ape...@unicon.net > To unsubscribe, change settings or access archives, > seehttp://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
