Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Wed, 30 May 2012 19:33:23 +0000 (UTC)
From: "Oliver Wulff (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: <1499482701.17887.1338406403251.JavaMail.jiratomcat@issues-vm>
In-Reply-To: 
 <173633522.14814.1305532787602.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (CXF-3520) CXF support for cross domain SSO
 based on SAML token
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CXF-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13285946#comment-13285946 ] 

Oliver Wulff commented on CXF-3520:
-----------------------------------

This issue depends on CXF-3883 for the 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