[jira] [Assigned] (CXF-3522) Enhance CXF security context with claims information

["Colm O hEigeartaigh (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CXF-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Colm O hEigeartaigh reassigned CXF-3522:
----------------------------------------

    Assignee: Colm O hEigeartaigh

> Enhance CXF security context with claims information
> ----------------------------------------------------
>
>                 Key: CXF-3522
>                 URL: https://issues.apache.org/jira/browse/CXF-3522
>             Project: CXF
>          Issue Type: New Feature
>          Components: WS-* Components
>            Reporter: Oliver Wulff
>            Assignee: Colm O hEigeartaigh
>            Priority: Major
>
> Discussion around this feature started in the following thread:
> http://cxf.547215.n5.nabble.com/CXF-and-spring-security-td4368266.html
> The CXF SecurityContext provides the following two methods only:
> getUserPrincipal()
> isUserInRole()
> If the received security token is a SAML token further data (claims) can be in the token which might be relevant for authorization to implement the PEP/PDP in the application.
> WS-Trust has the following definition of a claim:
> A claim is a statement made about a client, service or other resource 
> The following OASIS specification defines the URI for some claims like lastname, email, country, etc. (chapter 7.5):
> http://docs.oasis-open.org/imi/identity/v1.0/os/identity-1.0-spec-os.pdf
> We could introduce a ClaimSecurityContext interface which extends the current SecurityContext and introduces a new method like:
> List<Claim> getClaims()
> A Claim consists of the following properties:
> ClaimType: URI (see spec mentioned above)
> Value: String / Object
> Additionally we can implement a ClaimsTranformer interface which depends on the security token type and creates an object which implements ClaimSecurityContext (similar design approach as for the validator implementation in WSS4J).
> We could provide out-of-the-box implementation for SAML 1.1 and 2.0 which parse the AttributeStatement and create the list of Claims object:
> <AttributeStatement><Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname"><AttributeValue>John</AttributeValue></Attribute><Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"><AttributeValue>Doe</AttributeValue></Attribute><Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth"><AttributeValue>5/5/1955</AttributeValue></Attribute><Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/homephone"><AttributeValue>555-555-5555</AttributeValue></Attribute><Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"><AttributeValue>john@...</AttributeValue></Attribute></AttributeStatement>
> In addition to that, the SamlClaimsTransformer can provide a property to define the URI how the role information is identified in the AttributeStatement. There is no standard claims URI for roles. Each STS uses a different URI. For instance, Microsoft ADFS uses the following URI:
> http://schemas.microsoft.com/ws/2008/06/identity/claims/role
> This would allow an application to use RBAC when they use ADFS and CXF out-of-the-box by using the isUserInRole of the WebServiceContext.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)