cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Wulff (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CXF-3520) CXF support for cross domain SSO based on SAML token
Date Mon, 16 May 2011 07:59:47 GMT
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

Mime
View raw message