Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Aug 22, 2008 · 5 comments
Closed

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

spring-projects-issues opened this issue Aug 22, 2008 · 5 comments

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Aug 22, 2008

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-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Aug 22, 2008

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-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Dec 27, 2009

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-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jan 21, 2010

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-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jul 6, 2010

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-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jul 6, 2010

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants