CXF
  1. CXF
  2. CXF-3883

Support for identity mapping as part of issue token process

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.5
    • Fix Version/s: 2.7.6
    • Component/s: STS
    • Labels:
      None
    • Estimated Complexity:
      Unknown

      Description

      The JIRA https://issues.apache.org/jira/browse/CXF-3520 describes the case where a CXF consumer has configured a different STS than the issuer configured in the IssuedToken assertion of the service provider:

      In this case, the service consumer and provider don't understand the identity/subject/principal of the counterpart. First, the consumer gets a token from its STS (IDP-STS) which could be a SAML token. Then he requests another token from the STS and sends the one issued before as part of the WS-Security header.

      The STS must figure out that the sent and requested tokens are from different realms (security domains) and must therefore call the configured identity mapper which takes as parameters source realm, target realm and source principal.

        Activity

        Hide
        Oliver Wulff added a comment -

        If the STS must be able to map the identity/claims he must know from which security domain (realm) to which security domain. The latter is defined by a RealmParser implementation. Options could be based the TCP Port as each realm runs in a different JVM or based on the URI like (.../STS/<myrealm>/...). The source realm must be encoded in the retrieved token which is possible with a SAML token (or X509). The SAMLRealmCodec interface provides customization to tell the STS how to parse the realm in the SAML token. This could be done by using an individual cert/pk for each security domain where the realm is encoded in the DN.

        Currently, the TokenProvider has only access to the principal of the token passed in the WS-Sec header but he requires access to the realm as well.

        The TokenIssueOperation is called when the SAML assertion is valid and the issuer of this token is trusted by this STS realm instance. Then, the TokenIssueOperation must parse the realm of the SAML token (SAMLRealmCodec) and get the its own realm (RealmParser). If it's equal don't do anything as right now. If different, figure out what kind of relationship is defined between the two realms (principal oder claims mapping), do the mapping.

        TokenProviderParameters provides a new attribute "mappedPrincipal" attribute (new) where the mapped id is stored. I'd like to wrap the security token used for authentication in the WS-Sec header in a ReceivedToken thus any TokenProvider has access to it (optional).

        The subject provider will first check whether there is a mappedPrincipal set before falling back to the principal attribute.

        Show
        Oliver Wulff added a comment - If the STS must be able to map the identity/claims he must know from which security domain (realm) to which security domain. The latter is defined by a RealmParser implementation. Options could be based the TCP Port as each realm runs in a different JVM or based on the URI like (.../STS/<myrealm>/...). The source realm must be encoded in the retrieved token which is possible with a SAML token (or X509). The SAMLRealmCodec interface provides customization to tell the STS how to parse the realm in the SAML token. This could be done by using an individual cert/pk for each security domain where the realm is encoded in the DN. Currently, the TokenProvider has only access to the principal of the token passed in the WS-Sec header but he requires access to the realm as well. The TokenIssueOperation is called when the SAML assertion is valid and the issuer of this token is trusted by this STS realm instance. Then, the TokenIssueOperation must parse the realm of the SAML token (SAMLRealmCodec) and get the its own realm (RealmParser). If it's equal don't do anything as right now. If different, figure out what kind of relationship is defined between the two realms (principal oder claims mapping), do the mapping. TokenProviderParameters provides a new attribute "mappedPrincipal" attribute (new) where the mapped id is stored. I'd like to wrap the security token used for authentication in the WS-Sec header in a ReceivedToken thus any TokenProvider has access to it (optional). The subject provider will first check whether there is a mappedPrincipal set before falling back to the principal attribute.
        Hide
        Colm O hEigeartaigh added a comment -

        Sounds fine to me.

        Colm.

        Show
        Colm O hEigeartaigh added a comment - Sounds fine to me. Colm.
        Hide
        Oliver Wulff added a comment -

        Committed fix for 2.7.6. Colm, can you look into 3.0?

        Show
        Oliver Wulff added a comment - Committed fix for 2.7.6. Colm, can you look into 3.0?

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development