Spring Security
  1. Spring Security
  2. SEC-1592

CAS proxy receptor requests must not pass through the filter chain

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Complete
    • Affects Version/s: 3.0.2
    • Fix Version/s: 3.1.0.RC1, 3.0.6
    • Component/s: CAS
    • Labels:
      None
    • Environment:
      Ubuntu Lucid
      Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
      Grails 1.3.2
      Spring security core/cas 3.0.2 (Grails spring-security-core plugin 0.4.1 & Grails spring-security-cas plugin 0.1)

      Description

      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

        Activity

        Hide
        Sébastien Launay added a comment -

        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(...)
        Show
        Sébastien Launay added a comment - 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(...)
        Hide
        Rob Winch added a comment -

        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.

        Show
        Rob Winch added a comment - 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.
        Hide
        Sébastien Launay added a comment -

        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.

        Show
        Sébastien Launay added a comment - 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.
        Hide
        Rob Winch added a comment -

        >> 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

        Show
        Rob Winch added a comment - >> 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

          People

          • Assignee:
            Rob Winch
            Reporter:
            Sébastien Launay
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: