[
https://issues.apache.org/jira/browse/CXF-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Wulff updated CXF-3520:
------------------------------
Description:
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
was:
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
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
