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-1592: CAS proxy receptor requests must not pass through the filter chain #1831

Closed
spring-projects-issues opened this issue Oct 13, 2010 · 4 comments
Assignees
Milestone

Comments

@spring-projects-issues
Copy link

@spring-projects-issues spring-projects-issues commented Oct 13, 2010

Sébastien Launay (Migrated from SEC-1592) said:

I configured spring-security-cas in my webapp for generating proxy tickets.

During ticket validation we provide a pgtUrl parameter and then the CAS server tries
to connect to our webapp (using the configured proxyReceptorUrl) to determine is this
URL is a valid end-point but it result in a 404 because the request is passed trough
the servlet but is not handled (because no controller is mapped for this URL).

If we set the grails.plugins.springsecurity.rejectIfNoRule parameter [1] to true or if I mark this
proxy receptor URL with the role "IS_AUTHENTICATED_REMEMBERED" then it works:

  • the ping request [2] result in a 302 (redirection to CAS because the request needs to be authenticated)
  • the pgtId/pgtIou request result also in a 302 (therefore without the proper XML fragment) but the mapping is stored

This works because the CAS server is not strict about the expected XML fragment,
only the a proper status code is mandatory [2].

Current workaround is to create a controller for this URL with anonymous access and
always respond with a 200 and some text.

I believe this issue is not related to Grails and may impact any webapp using
spring-security-cas and wanting to generate proxy tickets.
Furthermore, the default behaviour in cas-client [3] is already to stop processing the
request once it has been handled by the Cas20ProxyReceivingTicketValidationFilter [3].

[1] http://burtbeckwith.github.com/grails-spring-security-core/docs/manual/index.html
[2] https://source.jasig.org/cas3/tags/cas-3-3-5-1-final/cas-server-core/src/main/java/org/jasig/cas/authentication/handler/support/HttpBasedServiceCredentialsAuthenticationHandler.java
[2] https://source.jasig.org/cas3/tags/cas-3-3-5-1-final/cas-server-core/src/main/java/org/jasig/cas/util/HttpClient.java
[3] https://source.jasig.org/cas-clients/java-client/tags/cas-client-3.1.12/cas-client-core/src/main/java/org/jasig/cas/client/validation/Cas20ProxyReceivingTicketValidationFilter.java
[3] https://source.jasig.org/cas-clients/java-client/tags/cas-client-3.1.12/cas-client-core/src/main/java/org/jasig/cas/client/validation/AbstractTicketValidationFilter.java

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Oct 13, 2010

Sébastien Launay said:

A patch against the master branch to:

  • reproduce the issue with a test case (and also to detect potential future regression around proxy receptor)
  • stop processing the request once it has been handled by CommonUtils#readAndRespondToProxyReceptorRequest(...)
@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jan 27, 2011

Rob Winch said:

Thank you for your bug/patch submission. I fixed this is 3.x and master, but went about it slightly differently. In short, the fix moves CommonUtils.readAndRespondToProxyReceptorRequest into CasAuthenticationFilter.attemptAuthentication. This makes sense since the CAS server is authenticating that the proxy url is valid (i.e. it exists and the SSL handshake succeeds). It also allows the FilterChain to not be processed by returning a null Authentication.

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jan 27, 2011

Sébastien Launay said:

Thanks Rob I now will be able to remove my workaround.

Like you said, the fix has been backported to 3.0.x (commit ece824f) so I guess this issue needs to also be marked as fixed for version 3.0.6.

@spring-projects-issues
Copy link
Author

@spring-projects-issues spring-projects-issues commented Jan 27, 2011

Rob Winch said:

Like you said, the fix has been backported to 3.0.x (commit ece824f) so I guess this issue needs to also be marked as fixed for version 3.0.6.

Good catch....I have updated the fix version

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