CXF support for cross domain SSO based on SAML token
----------------------------------------------------

                 Key: CXF-3520
                 URL: https://issues.apache.org/jira/browse/CXF-3520
             Project: CXF
          Issue Type: Improvement
          Components: WS-* Components
    Affects Versions: 2.4
            Reporter: Oliver Wulff


Use case:
There is a service consumer and a service provider using SOAP/HTTPS. Both 
understand SAML tokens. An identity known in the security domain of the service 
consumer is not known to the domain of the service provider. 

This use case can be addressed by the following proposal. The IssuedToken 
assertion in the WS-SecurityPolicy document of the service provider defines the 
Issuer he trusts which is the so called Relying Party (RP) STS. The service 
consumer configures the STSClient bean where you define the URL of the STS 
which is the so called Identity Provider (IP) STS. 

If service consumer and service provider are in the same security domain 
(principal/id understood by service consumer and provider) the URLs/EPR are 
equal. If they are not I'd say we have the use case I described above. CXF 2.4 
ignores the Issuer element in the IssuedToken assertion.

<sp:IssuedToken sp:IncludeToken="xs:anyURI"? xmlns:sp="..." ...> 
    <sp:Issuer>wsa:EndpointReferenceType</sp:Issuer> 
    <sp:RequestSecurityTokenTemplate TrustVersion="xs:anyURI"? > 
    ... 

If they are different, the CXF service consumer must first go to the STS 
configured in the STSClient and gets a SAML token. Then the service consumer 
sends the previously issued token (in WS-Security header) to the Relying Party 
STS and let's issue a new token based on the data in the 
RequestSecurityTokenTemplate element of the policy. There must be a trust 
established between the IP STS and the RP STS.
(This is *not* a case for OnBehalfOf support as described in WS-Trust spec)

As far as I understand the WS-Federation spec this is the idea of the active 
requestor profile. It's then up to the Relying Party STS do implements claims 
transformation (like principal mapping, role mapping and other claims) 

Link to topic in mailing list:
http://cxf.547215.n5.nabble.com/SAML-support-across-security-domains-SSO-td4372429.html

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to