cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Wulff (JIRA)" <>
Subject [jira] [Commented] (CXF-3883) Support for identity mapping as part of issue token process
Date Wed, 30 May 2012 19:54:23 GMT


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:
>             Project: CXF
>          Issue Type: New Feature
>          Components: Services
>    Affects Versions: 2.5
>            Reporter: Oliver Wulff
> The JIRA 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:!default.jspa
For more information on JIRA, see:


View raw message