cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Wulff (JIRA)" <>
Subject [jira] [Commented] (CXF-3520) CXF support for cross domain SSO based on SAML token
Date Wed, 30 May 2012 13:57:24 GMT


Oliver Wulff commented on CXF-3520:

It's an issue request to the RP STS.
> CXF support for cross domain SSO based on SAML token
> ----------------------------------------------------
>                 Key: CXF-3520
>                 URL:
>             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
> <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 thread in mailing list:

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