[
https://issues.apache.org/jira/browse/CXF-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13285553#comment-13285553
]
Colm O hEigeartaigh commented on CXF-3520:
------------------------------------------
"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. "
Does the STS client call the issue or validate binding on the Relying Party
STS?
Colm.
> 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 thread in mailing list:
> http://cxf.547215.n5.nabble.com/SAML-support-across-security-domains-SSO-td4372429.html
--
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
