You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cxf.apache.org by bu...@apache.org on 2014/04/02 13:48:01 UTC
svn commit: r904648 - in /websites/production/cxf/content:
cache/docs.pageCache docs/saml-web-sso.html
Author: buildbot
Date: Wed Apr 2 11:48:01 2014
New Revision: 904648
Log:
Production update by buildbot for cxf
Modified:
websites/production/cxf/content/cache/docs.pageCache
websites/production/cxf/content/docs/saml-web-sso.html
Modified: websites/production/cxf/content/cache/docs.pageCache
==============================================================================
Binary files - no diff available.
Modified: websites/production/cxf/content/docs/saml-web-sso.html
==============================================================================
--- websites/production/cxf/content/docs/saml-web-sso.html (original)
+++ websites/production/cxf/content/docs/saml-web-sso.html Wed Apr 2 11:48:01 2014
@@ -118,21 +118,21 @@ Apache CXF -- SAML Web SSO
<td height="100%">
<!-- Content -->
<div class="wiki-content">
-<div id="ConfluenceContent"><p><span style="font-size:2em;font-weight:bold"> JAX-RS: SAML Web SSO</span></p><p></p><p> </p><p><style type="text/css">/*<![CDATA[*/
-div.rbtoc1395395367217 {padding: 0px;}
-div.rbtoc1395395367217 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1395395367217 li {margin-left: 0px;padding-left: 0px;}
+<div id="ConfluenceContent"><span style="font-size:2em;font-weight:bold"> JAX-RS: SAML Web SSO</span><p> </p><p> </p><p><style type="text/css">/*<![CDATA[*/
+div.rbtoc1396439258884 {padding: 0px;}
+div.rbtoc1396439258884 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1396439258884 li {margin-left: 0px;padding-left: 0px;}
-/*]]>*/</style></p><div class="toc-macro rbtoc1395395367217">
+/*]]>*/</style></p><div class="toc-macro rbtoc1396439258884">
<ul class="toc-indentation"><li><a shape="rect" href="#SAMLWebSSO-Introduction">Introduction</a>
<ul class="toc-indentation"><li><a shape="rect" href="#SAMLWebSSO-TypicalFlow">Typical Flow</a></li></ul>
</li><li><a shape="rect" href="#SAMLWebSSO-Mavendependencies">Maven dependencies</a></li><li><a shape="rect" href="#SAMLWebSSO-IdentityProvider">Identity Provider</a></li><li><a shape="rect" href="#SAMLWebSSO-ServiceProviderSecurityFilter">Service Provider Security Filter</a>
<ul class="toc-indentation"><li><a shape="rect" href="#SAMLWebSSO-RedirectBindingFilter">Redirect Binding Filter</a></li><li><a shape="rect" href="#SAMLWebSSO-POSTBindingFilter">POST Binding Filter</a></li><li><a shape="rect" href="#SAMLWebSSO-SigningSAMLAuthenticationRequests">Signing SAML Authentication Requests</a></li><li><a shape="rect" href="#SAMLWebSSO-FiltersandStateManagement">Filters and State Management</a></li></ul>
</li><li><a shape="rect" href="#SAMLWebSSO-RequestAssertionConsumerService">Request Assertion Consumer Service</a>
-<ul class="toc-indentation"><li><a shape="rect" href="#SAMLWebSSO-DealingwithsignedSAMLResponses">Dealing with signed SAML Responses</a></li><li><a shape="rect" href="#SAMLWebSSO-SignatureKeyInfoValidation">Signature Key Info Validation</a></li></ul>
+<ul class="toc-indentation"><li><a shape="rect" href="#SAMLWebSSO-DealingwithsignedSAMLResponses">Dealing with signed SAML Responses</a></li><li><a shape="rect" href="#SAMLWebSSO-SignatureKeyInfoValidation">Signature Key Info Validation</a></li><li><a shape="rect" href="#SAMLWebSSO-UsingRACSasEndpointFilter">Using RACS as Endpoint Filter</a></li></ul>
</li><li><a shape="rect" href="#SAMLWebSSO-SSOStateProvider">SSO State Provider</a>
<ul class="toc-indentation"><li><a shape="rect" href="#SAMLWebSSO-DistributedStateManagement">Distributed State Management</a></li></ul>
-</li></ul>
+</li><li><a shape="rect" href="#SAMLWebSSO-LogoutService">Logout Service</a></li></ul>
</div><h1 id="SAMLWebSSO-Introduction">Introduction</h1><p><a shape="rect" class="external-link" href="http://en.wikipedia.org/wiki/Single_sign-on" rel="nofollow">SSO</a> is about a user having to sign in only once when interacting with a custom web application which may offer of a number of individual endpoints.</p><p>CXF 2.6.1 introduces a comprehensive service provider (SP) support for the SAML Web SSO <a shape="rect" class="external-link" href="http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf" rel="nofollow">profile</a>. This <a shape="rect" class="external-link" href="http://en.wikipedia.org/wiki/SAML_2.0" rel="nofollow">page</a> also offers a good overview of the <a shape="rect" class="external-link" href="http://en.wikipedia.org/wiki/SAML_2.0#Web_Browser_SSO_Profile" rel="nofollow">profile</a>.</p><p>HTTP Redirect(via GET) and POST bindings are supported. The module has been tested against many IDP providers and is easily configurable.</p><p>The followin
g components are required to get SSO supported:</p><ul class="alternate"><li>Identity Provider (IDP) supporting SAML SSO</li><li>Request Assertion Consumer Service (RACS)</li><li>Service Provider Security Filter</li><li>SSO State Provider</li></ul><p>The following sections will describe these components in more details</p><h2 id="SAMLWebSSO-TypicalFlow">Typical Flow</h2><p>Typically, the following flow represents the way SAML SSO is enforced:</p><p>1. User accesses a custom application for the first time<br clear="none"> 2. Service Provider Security Filter checks if the security context is available <br clear="none"> and redirects the user to IDP with a SAML SSO request<br clear="none"> 3. IDP challenges the user with the authentication dialog and redirects the user to<br clear="none"> Request Assertion Consumer Service (RACS) after the user has authenticated<br clear="none"> 4. RACS validates the response from IDP, establishes a security context and redirects the user <br clear="no
ne"> to the original application endpoint<br clear="none"> 5. Service Provider Security Filter enforces that a valid security context is available and lets the user<br clear="none"> access the custom application.</p><h1 id="SAMLWebSSO-Mavendependencies">Maven dependencies</h1><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[<dependency>
<groupId>org.apache.cxf</groupId>
@@ -274,7 +274,7 @@ div.rbtoc1395395367217 li {margin-left:
<property name="callbackHandlerClass" value="org.apache.cxf.samlp.sso.SSOCallbackHandler"/>
</bean>
]]></script>
-</div></div><p>In this example the "enforceAssertionsSigned" enforcing that signed Assertions are contained in a Response is disabled by default and RACS will only verify that the actual Responses are signed.</p><h2 id="SAMLWebSSO-SignatureKeyInfoValidation">Signature Key Info Validation</h2><p>By default ds:Signature is expected to contain ds:KeyInfo element.</p><p>Setting a "keyInfoMustBeAvailable" property to false will lead to a default store alias being used to load the certificate for validating the signature.</p><h1 id="SAMLWebSSO-SSOStateProvider">SSO State Provider</h1><p>SP Security Filters and RACS depend on the custom <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/sso/saml/src/main/java/org/apache/cxf/rs/security/saml/sso/state/SPStateManager.java">SPStateManager</a> implementation for persisting the current request and security context state.</p><p>CXF ships a basic <a shape="rect" class="external-link" href="http://
svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/sso/saml/src/main/java/org/apache/cxf/rs/security/saml/sso/state/MemorySPStateManager.java">MemorySPStateProvider</a> and an <a shape="rect" class="external-link" href="http://ehcache.org/" rel="nofollow">EhCache</a>-based <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/sso/saml/src/main/java/org/apache/cxf/rs/security/saml/sso/state/EHCacheSPStateManager.java">implementation</a> which is memory based with an option to overflow to the disk. Users can customize the EhCache provider or register their own custom SPStateProvider implementations if required.</p><p>For example, by default, the EhCache provider will overflow the data to the system temp directory and will not persist the data across restarts. The following EhCache configuration can be used to change it:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+</div></div><p>In this example the "enforceAssertionsSigned" enforcing that signed Assertions are contained in a Response is disabled by default and RACS will only verify that the actual Responses are signed.</p><h2 id="SAMLWebSSO-SignatureKeyInfoValidation">Signature Key Info Validation</h2><p>By default ds:Signature is expected to contain ds:KeyInfo element.</p><p>Setting a "keyInfoMustBeAvailable" property to false will lead to a default store alias being used to load the certificate for validating the signature.</p><h2 id="SAMLWebSSO-UsingRACSasEndpointFilter">Using RACS as Endpoint Filter</h2><p>As you can see from the documentation above, RACS is typically represented as an independent service endpoint or service bean: in such cases RACS redirects the requestor back to the the actual endpoint.</p><p>Starting from CXF 3.0.0 it is possible to set it up as the target endpoint filter, simply add org.apache.cxf.rs.security.saml.sso.RequestionAssertionConsumerFilter to the list of o
ther endpoint providers.</p><p>In this case the authentication filters do not have to set their "assertionConsumerServiceAddress" property</p><h1 id="SAMLWebSSO-SSOStateProvider">SSO State Provider</h1><p>SP Security Filters and RACS depend on the custom <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/sso/saml/src/main/java/org/apache/cxf/rs/security/saml/sso/state/SPStateManager.java">SPStateManager</a> implementation for persisting the current request and security context state.</p><p>CXF ships a basic <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/sso/saml/src/main/java/org/apache/cxf/rs/security/saml/sso/state/MemorySPStateManager.java">MemorySPStateProvider</a> and an <a shape="rect" class="external-link" href="http://ehcache.org/" rel="nofollow">EhCache</a>-based <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/sso/saml/
src/main/java/org/apache/cxf/rs/security/saml/sso/state/EHCacheSPStateManager.java">implementation</a> which is memory based with an option to overflow to the disk. Users can customize the EhCache provider or register their own custom SPStateProvider implementations if required.</p><p>For example, by default, the EhCache provider will overflow the data to the system temp directory and will not persist the data across restarts. The following EhCache configuration can be used to change it:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[<ehcache xsi:noNamespaceSchemaLocation="ehcache.xsd" updateCheck="false" monitoring="autodetect" dynamicConfig="true">
<diskStore path="/home/username/work/ehcache"/>
@@ -328,7 +328,7 @@ Assuming this configuration is saved in
</bean>
]]></script>
-</div></div><p>Note that a JAX-RS Client proxy to the HTTPSPStateManager endpoint is used as SPStateManager reference.</p><p>The alternative to having a distributed state cache be set up is to simply have a RACS endpoint collocated with every individual web application constituting the bigger application, see the earlier section describing SSO filters on how this can be easily set up. One possible downside of it is that there will be no centralized store managing the state required by different filters and RACS which in turn can make it more difficult to audit and log all the SSO-related activities spanning across all the bigger application.</p></div>
+</div></div><p>Note that a JAX-RS Client proxy to the HTTPSPStateManager endpoint is used as SPStateManager reference.</p><p>The alternative to having a distributed state cache be set up is to simply have a RACS endpoint collocated with every individual web application constituting the bigger application, see the earlier section describing SSO filters on how this can be easily set up. One possible downside of it is that there will be no centralized store managing the state required by different filters and RACS which in turn can make it more difficult to audit and log all the SSO-related activities spanning across all the bigger application.</p><p> </p><h1 id="SAMLWebSSO-LogoutService">Logout Service</h1><p> </p><p>CXF 3.0.0 introduces <a shape="rect" class="external-link" href="https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f=rt/rs/security/sso/saml/src/main/java/org/apache/cxf/rs/security/saml/sso/LogoutService.java;h=048f7c11ccc5f8dd8fd243e4b8344901420d6652;hb
=HEAD">LogoutService</a>. It will remove the SSO state for the logged-in user, and can be registered as an independent endpoint or service bean.</p><p>It returns LogoutResponse bean which is expected to be processed by the View handler.</p><p>For example, one can imagine a user getting HTML page confirming the logout has been successful and linking to the application front page.</p><p> </p><p> </p></div>
</div>
<!-- Content -->
</td>