[ https://issues.apache.org/jira/browse/CXF-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13285668#comment-13285668 ]
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: 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