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

WS-T / WS-SP sp:RequestSecurityTokenTemplate not using wst:SecondaryParameters

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.2.10, 2.3
    • Fix Version/s: 2.2.10, 2.3
    • Component/s: WS-* Components
    • Labels:
      None

      Description

      Per the WS-SP 1.2 spec, section 5.4.2, "This required element contains elements which MUST be copied into the wst:SecondaryParameters of the RST request sent to the specified issuer. Note: the initiator is not required to understand the contents of this element."

      The STS client copies these values directly into the body of the wst:RequestSecurityToken element in the request to the STS.

      So this policy:

      <sp:IssuedTokensp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Always">
        <sp:RequestSecurityTokenTemplate>
          <wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1</wst:TokenType>
          <wst:AppliesTo>
            <wsp:URI>service-1</wsp:URI>
          </wst:AppliesTo>
          <wst:Participants>
            <wst:Participant>
              <wsp:URI>service-1</wsp:URI>
            </wst:Participant>
          </wst:Participants>
          <wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey</wst:KeyType>
        </sp:RequestSecurityTokenTemplate>
      </sp:IssuedToken>
      

      Becomes this request:

      <wst:RequestSecurityToken>
        ...
        <wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1</wst:TokenType>
        <wst:AppliesTo>
          <wsp:URI>service-1</wsp:URI>
        </wst:AppliesTo>
        <wst:Participants>
          <wst:Participant>
            <wsp:URI>service-1</wsp:URI>
          </wst:Participant>
        </wst:Participants>
        <wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey</wst:KeyType>
        ...
      </wst:RequestSecurityToken>
      

      Instead of:

      <wst:RequestSecurityToken>
        ...
        <wst:SecondaryParameters>
        <wst:TokenType>http://docs.oasis-open.org/wss/oasis-wss-saml-token-profile-1.1#SAMLV1.1</wst:TokenType>
          <wst:AppliesTo>
            <wsp:URI>service-1</wsp:URI>
          </wst:AppliesTo>
          <wst:Participants>
            <wst:Participant>
              <wsp:URI>service-1</wsp:URI>
            </wst:Participant>
          </wst:Participants>
          <wst:KeyType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/PublicKey</wst:KeyType>
        </wst:SecondaryParameters>
        ...
      </wst:RequestSecurityToken>
      

      WS-Trust 1.0 and WS-SP 1.0 do not support the wst:SecondaryParameters element so backwards compatibility should be retained per the interopfest samples.

        Activity

        Hide
        davaleri David Valeri added a comment -

        Interopfest wstrust13 module does not work due to relocation of Microsoft STS and change to TLS certificate. The STS WSDL moved to 131.107.153.205:8080. The STS HTTPS port is 8443. While this port is properly reflected in the WSDLs, the certificate on that port is self-issued and not part of the OSASIS interop certificate hierarchy in the downloaded certs zip.

        The following changes were implemented to test this issues fix:

        1) Change download script to use port 8080
        2) Manually adding the self-issued cert to the certs/WssIP.pfx extracted from the downloaded zip
        3) Reconfiguring the HTTP conduits in client.xml to use certs/WssIP.pfx instead of the bob.pfx file

        Even with these changes, a TLS related exception is still created for one of the interop scenarios. The fix for this issue is observed to be working during execution of the functioning tests in wstrust13 and the other interop samples.

        Show
        davaleri David Valeri added a comment - Interopfest wstrust13 module does not work due to relocation of Microsoft STS and change to TLS certificate. The STS WSDL moved to 131.107.153.205:8080. The STS HTTPS port is 8443. While this port is properly reflected in the WSDLs, the certificate on that port is self-issued and not part of the OSASIS interop certificate hierarchy in the downloaded certs zip. The following changes were implemented to test this issues fix: 1) Change download script to use port 8080 2) Manually adding the self-issued cert to the certs/WssIP.pfx extracted from the downloaded zip 3) Reconfiguring the HTTP conduits in client.xml to use certs/WssIP.pfx instead of the bob.pfx file Even with these changes, a TLS related exception is still created for one of the interop scenarios. The fix for this issue is observed to be working during execution of the functioning tests in wstrust13 and the other interop samples.

          People

          • Assignee:
            davaleri David Valeri
            Reporter:
            davaleri David Valeri
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development