SEC-965: Support standard convention for proxy tickets #1216

Closed
spring-issuemaster opened this Issue Aug 22, 2008 · 5 comments

2 participants

@spring-issuemaster

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.

@spring-issuemaster

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.

@spring-issuemaster

Scott Battaglia said:

Started to look at this. Two questions:

It looks like Spring Security would support the following already:

  1. The ability to specify spring-security-redirect such that you could do /j_spring_security_cas?ticket=&spring-security-redirect=/foo-bar.html

Is that sufficient?

If not, it looks like more work is needed to properly support this.

@spring-issuemaster

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?

@spring-issuemaster

Scott Battaglia said:

Bruno, you could use the CAS filters in combination with the Spring Security's support for container auth (i.e. reading request.getRemoteUser())

@spring-issuemaster

Scott Battaglia said:

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?

@spring-issuemaster spring-issuemaster added this to the 3.1.0.RC2 milestone Feb 5, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment