Uploaded image for project: 'CXF'
  1. CXF
  2. CXF-3928

Add token validation for OnBehalfOf element in TokenIssueOperation

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.5
    • Fix Version/s: 2.5.1
    • Component/s: Services
    • Labels:
      None
    • Estimated Complexity:
      Unknown

      Description

      Tokens passed in OnBehalfOf element are not validated. It's the responsibility of the TokenProvider implementation to validate that.

      A proposal has been discussed here:
      http://cxf.547215.n5.nabble.com/STS-OnBehalfOf-token-validation-SAMLTokenProvider-td5003544.html

      OnBehalfOf token validation is moved to the TokenIssueOperation and the ReceivedToken is enhanced with the following attributes:

      • was it a token of ws-security header (like ReceivedToken), onbehalfof, actas
      • successfully validated (it could be a token which depends on other constraints to be fully accepted)
      • original DOM element
      • transformed DOM element (used if the token is passed by ref, also supported by SAML spec)
      • principal (mostly, you only need the principal to issue a new token)
      1. git.diff.patch
        55 kB
        Oliver Wulff
      2. git.diff.patch
        24 kB
        Oliver Wulff

        Issue Links

          Activity

          Hide
          owulff Oliver Wulff added a comment -

          Implemented the changes and added a unit test where the on-behalf-of token has been issued by SAML realm A and the issued token is a SAML token of realm B

          Show
          owulff Oliver Wulff added a comment - Implemented the changes and added a unit test where the on-behalf-of token has been issued by SAML realm A and the issued token is a SAML token of realm B
          Hide
          owulff Oliver Wulff added a comment -

          Makes sense. I'll also move the refactored method validateReceivedToken up to AbstractOperation and reuse it in TokenValidateOperation.

          Show
          owulff Oliver Wulff added a comment - Makes sense. I'll also move the refactored method validateReceivedToken up to AbstractOperation and reuse it in TokenValidateOperation.
          Hide
          coheigea Colm O hEigeartaigh added a comment -

          Hi Oli,

          No major objections. I would maybe put the TokenValidator list into AbstractOperation as per the TokenProvider list. Also consider putting the OnBehalfOf validation code you added into a separate method or class.

          Colm.

          Show
          coheigea Colm O hEigeartaigh added a comment - Hi Oli, No major objections. I would maybe put the TokenValidator list into AbstractOperation as per the TokenProvider list. Also consider putting the OnBehalfOf validation code you added into a separate method or class. Colm.
          Hide
          owulff Oliver Wulff added a comment -

          I've applied an initial patch but due to several changes I'd like to get your opinion on it.

          Semantic changes:
          1) so far, the principal is written into the TokenValidatorResponse if validation was succeesful
          I changed this thus the principal is available if parsing was successful. If validation fails the ReceivedToken has the state set to INVALID.

          Therefore I had to change:

          • DefaultSubjectProvider
          • SAMLTokenValidator
          • UsernameTokenValidator

          Notes:

          • attribute tokenContext of ReceivedToken not yet used.
          • I'd like to add an additional testcase of issue onbehalfof where IdentityMapper is required (but would like your feedback first)
          Show
          owulff Oliver Wulff added a comment - I've applied an initial patch but due to several changes I'd like to get your opinion on it. Semantic changes: 1) so far, the principal is written into the TokenValidatorResponse if validation was succeesful I changed this thus the principal is available if parsing was successful. If validation fails the ReceivedToken has the state set to INVALID. Therefore I had to change: DefaultSubjectProvider SAMLTokenValidator UsernameTokenValidator Notes: attribute tokenContext of ReceivedToken not yet used. I'd like to add an additional testcase of issue onbehalfof where IdentityMapper is required (but would like your feedback first)

            People

            • Assignee:
              coheigea Colm O hEigeartaigh
              Reporter:
              owulff Oliver Wulff
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development