[
https://issues.apache.org/jira/browse/CXF-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13285962#comment-13285962
]
Oliver Wulff commented on CXF-3883:
-----------------------------------
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.
> Support for identity mapping as part of issue token process
> -----------------------------------------------------------
>
> Key: CXF-3883
> URL: https://issues.apache.org/jira/browse/CXF-3883
> Project: CXF
> Issue Type: New Feature
> Components: Services
> Affects Versions: 2.5
> Reporter: Oliver Wulff
>
> 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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
