You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Colm O hEigeartaigh (Commented) (JIRA)" <ji...@apache.org> on 2012/03/02 15:31:57 UTC

[jira] [Commented] (CXF-3882) Support for Claims transformation in validate or issue RST

    [ https://issues.apache.org/jira/browse/CXF-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13220950#comment-13220950 ] 

Colm O hEigeartaigh commented on CXF-3882:
------------------------------------------


Looks fine to me - albeit you forgot to include the new files in the patch. Are the List of Relationships in the STSPropertiesMBean actually used, or just the resolver?

Colm.
                
> Support for Claims transformation in validate or issue RST
> ----------------------------------------------------------
>
>                 Key: CXF-3882
>                 URL: https://issues.apache.org/jira/browse/CXF-3882
>             Project: CXF
>          Issue Type: New Feature
>          Components: Services
>    Affects Versions: 2.5
>            Reporter: Oliver Wulff
>            Assignee: Oliver Wulff
>         Attachments: git.diff.txt
>
>
> Use case:
> A partner company have set up an STS which is connected to their identity system. The issued SAML token contain claims in the attribute statement which do have a different encoding for the same meaning. Applications should not directly depend on the claims because they will be different for each partner. Therefore, the application trusts a so called Relying Party STS whereas the partner uses their Identity Provider STS. If identities of the partners are provisioned into your identiy system you're fine with the current IdentityMapper interface but this means claims must be provisioned too. This might work for different identity system within the same company but doesn't scale with partners. In this case, the RP STS transforms the claims of the IP STS to claims which are understood by the application.
> If claims information are correlated to a security token like a SAML token it's encoded within an Attribute Statement. If it is a SecureConversation token, it's not part of the token itself but locally cached. The claims might be encoded within a custom token also.
> The token can be part of the WS-Security header (issue request) or within the ValidateTarget (validate request).
> The TokenValidator must validate the token and return the realm which is the source realm.
> The claims of the source realm must be provided by the token validator or retrieved from the cache.
> The target realm is provided as part of the RealmParser implementation.
> The claims transformation interface looks like something:
> List<Claim> mapClaims (String sourceRealm, List<Claim> sourceClaims, String targetRealm)

--
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