Nathan Summers (Migrated from SEC-965) said:
The standard method for sending a proxy ticket is to include it as the request parameter “ticket”. For example, in HTTP GET, it could be http://example.com/some/uri?ticket=ST-3-alDsk2jaLkfjzC3v-cas. Spring Security does not currently support this convention, which makes using generic CAS proxy-aware components difficult.
Nathan Summers said:
This patch implements the needed functionality, although perhaps not in the cleanest way possible, which would require more refactoring than I felt license to do in a patch submitted to a bug tracker. Basically the required behavior is to recognize any request with a “ticket” parameter as being an alternate way to authenticate using CAS, and to continue the chain instead of send a redirect if that method is used.
It would probably be cleaner if the filter strips the ticket parameter from the request before continuing on the chain.
Scott Battaglia said:
Started to look at this. Two questions:
It looks like Spring Security would support the following already:
Is that sufficient?
If not, it looks like more work is needed to properly support this.
Bruno Felaco said:
I wish to use CAS as my authentication provider across a suite of cooperating server applications. I need to make server-to-server web-service calls, some of which will be WS-* style and others will be RESTful. I would like to use the same authentication mechanism (CAS proxy tickets) for both. Using the solution proposed by Scott, may work for RESTful web-services, using something like Spring's RestTemplate and ensuring that the ClientHttpRequest follows redirects and saves cookies, but I'm not sure if the various SOAP clients will cooperate as easily. Plus, the client-side redirect just adds more overhead I'd rather avoid.
I would prefer if the ticket could be tacked on to any URL either as a query parameter or perhaps in the path after the semi-colon (like jsessionid). This would also enable me redirect back to the original URL after login through CAS as well and avoid yet another redirect after landing on j_spring_security_cas.
From my cursory analysis of the code, it appears that the filters provided by CAS work as I described (but I haven't actually tried this). However, if I'm to use them with Spring Security, it appears I will need to write a custom security filter to build the UsernamePasswordAuthenticationToken from the Assertion placed in the request context. Is that a viable solution?
Bruno, you could use the CAS filters in combination with the Spring Security's support for container auth (i.e. reading request.getRemoteUser())
Luke, supporting the ticket param on any url breaks with tradition for how this is normally handled in Spring Security. Is that fine? Or would we prefer to always go to the same url endpoint with a url to redirect to?