Spring Security
  1. Spring Security
  2. SEC-965

Support standard convention for proxy tickets

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: 2.0.3
    • Fix Version/s: 3.1.0.RC2
    • Component/s: CAS
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        Nathan Summers added a comment -

        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.

        Show
        Nathan Summers added a comment - 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.
        Hide
        Scott Battaglia added a comment -

        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=<PT>&spring-security-redirect=/foo-bar.html

        Is that sufficient?

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

        Show
        Scott Battaglia added a comment - 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=<PT>&spring-security-redirect=/foo-bar.html Is that sufficient? If not, it looks like more work is needed to properly support this.
        Hide
        Bruno Felaco added a comment -

        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?

        Show
        Bruno Felaco added a comment - 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?
        Hide
        Scott Battaglia added a comment -

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

        Show
        Scott Battaglia added a comment - Bruno, you could use the CAS filters in combination with the Spring Security's support for container auth (i.e. reading request.getRemoteUser())
        Hide
        Scott Battaglia added a comment -

        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?

        Show
        Scott Battaglia added a comment - 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?

          People

          • Assignee:
            Rob Winch
            Reporter:
            Nathan Summers
          • Votes:
            8 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: