Author: buildbot
Date: Fri Apr 10 13:56:41 2020
New Revision: 1059109
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 Fri Apr 10 13:56:41
2020
@@ -34,6 +34,7 @@
<script src='/resources/highlighter/scripts/shCore.js'></script>
<script src='/resources/highlighter/scripts/shBrushJava.js'></script>
<script src='/resources/highlighter/scripts/shBrushXml.js'></script>
+<script src='/resources/highlighter/scripts/shBrushBash.js'></script>
<script>
SyntaxHighlighter.defaults['toolbar'] = false;
SyntaxHighlighter.all();
@@ -117,15 +118,15 @@ 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>
+<div id="ConfluenceContent"><p><br clear="none"><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.rbtoc1524513417198 {padding: 0px;}
-div.rbtoc1524513417198 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1524513417198 li {margin-left: 0px;padding-left: 0px;}
+<br clear="none"></p><p><br clear="none"></p><p><style
type="text/css">/*<![CDATA[*/
+div.rbtoc1586526962909 {padding: 0px;}
+div.rbtoc1586526962909 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1586526962909 li {margin-left: 0px;padding-left: 0px;}
-/*]]>*/</style></p><div class="toc-macro rbtoc1524513417198">
+/*]]>*/</style></p><div class="toc-macro rbtoc1586526962909">
<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>
@@ -135,15 +136,15 @@ div.rbtoc1524513417198 li {margin-left:
</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><li><a shape="rect" href="#SAMLWebSSO-LogoutService">Logout
Service</a></li><li><a shape="rect" href="#SAMLWebSSO-MetadataService">Metadata
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">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><dependency>
+</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="none">t
o 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">
+<pre class="brush: java; gutter: false; theme: Default"><dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-rs-security-sso-saml</artifactId>
<version>2.6.1</version>
</dependency>
</pre>
-</div></div><h1 id="SAMLWebSSO-IdentityProvider">Identity
Provider</h1><p>Identity Provider (IDP) is the service which accepts the
redirect requests from application security filters, authenticates users and
redirects them back to Request Assertion Security Service.</p><p>CXF does not
offer its own IDP SAML Web SSO implementation but might provide it in the
future as part of the <a shape="rect"
href="http://cxf.apache.org/fediz.html";>Fediz</a> project.</p><p>However, CXF
has been tested against a number of popular IDP implementations which support
SAML SSO and thus should be interoperable with whatever IDP is being used in
the specific production environment. The interoperability tests have shown that
some IDPs may process SAML request and produce SAML response data the way which
may not be exactly specification-compliant and thus CXF Request Assertion
Consumer Service (RACS) and Service Provider Security Filter implementations
have a number of configuration properties for adjusting
the way SAML requests to IDP are prepared and SAML responses from IDP are
processed.</p><h1 id="SAMLWebSSO-ServiceProviderSecurityFilter">Service
Provider Security Filter</h1><p>SP Security Filter protects the application
endpoints by checking that a valid SSO security context is available. If it is
then the filter lets the request to continue, if not then it redirects the
current user to IDP.</p><p>When a filter redirects a user to IDP, it creates a
SAML Authentication Request, see <a shape="rect" class="external-link"
href="http://en.wikipedia.org/wiki/SAML_2.0#Web_Browser_SSO_Profile";
rel="nofollow">this page</a> for the example and appends it to the IDP Service
URI or gets it POSTed to IDP.<br clear="none"> Additionally, a RelayState token
pointing to the state of the current user request is also included which IDP
will <br clear="none"> return to Request Assertion Consumer Service (RACS)
after the user has authenticated.</p><p>CXF offers two SP Security filters, one
for redire
cting the user back to IDP via GET and another one - via POST.</p><h2
id="SAMLWebSSO-RedirectBindingFilter">Redirect Binding Filter</h2><p>Redirect
Binding Filter is implemented by
org.apache.cxf.rs.security.saml.sso.SamlRedirectBindingFilter.</p><p>Here is an
example of a typical filter protecting a custom JAX-RS endpoint:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><bean id="serviceBean"
class="org.apache.cxf.samlp.sso.BookStore"/>
+</div></div><h1 id="SAMLWebSSO-IdentityProvider">Identity
Provider</h1><p>Identity Provider (IDP) is the service which accepts the
redirect requests from application security filters, authenticates users and
redirects them back to Request Assertion Security Service.</p><p>CXF does not
offer its own IDP SAML Web SSO implementation but might provide it in the
future as part of the <a shape="rect"
href="http://cxf.apache.org/fediz.html";>Fediz</a> project.</p><p>However, CXF
has been tested against a number of popular IDP implementations which support
SAML SSO and thus should be interoperable with whatever IDP is being used in
the specific production environment. The interoperability tests have shown that
some IDPs may process SAML request and produce SAML response data the way which
may not be exactly specification-compliant and thus CXF Request Assertion
Consumer Service (RACS) and Service Provider Security Filter implementations
have a number of configuration properties for adjusting
the way SAML requests to IDP are prepared and SAML responses from IDP are
processed.</p><h1 id="SAMLWebSSO-ServiceProviderSecurityFilter">Service
Provider Security Filter</h1><p>SP Security Filter protects the application
endpoints by checking that a valid SSO security context is available. If it is
then the filter lets the request to continue, if not then it redirects the
current user to IDP.</p><p>When a filter redirects a user to IDP, it creates a
SAML Authentication Request, see <a shape="rect" class="external-link"
href="http://en.wikipedia.org/wiki/SAML_2.0#Web_Browser_SSO_Profile";
rel="nofollow">this page</a> for the example and appends it to the IDP Service
URI or gets it POSTed to IDP.<br clear="none">Additionally, a RelayState token
pointing to the state of the current user request is also included which IDP
will <br clear="none">return to Request Assertion Consumer Service (RACS) after
the user has authenticated.</p><p>CXF offers two SP Security filters, one for
redirect
ing the user back to IDP via GET and another one - via POST.</p><h2
id="SAMLWebSSO-RedirectBindingFilter">Redirect Binding Filter</h2><p>Redirect
Binding Filter is implemented by
org.apache.cxf.rs.security.saml.sso.SamlRedirectBindingFilter.</p><p>Here is an
example of a typical filter protecting a custom JAX-RS endpoint:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"><bean
id="serviceBean" class="org.apache.cxf.samlp.sso.BookStore"/>
<jaxrs:server address="/app1">
<jaxrs:serviceBeans>
@@ -167,8 +168,8 @@ div.rbtoc1524513417198 li {margin-left:
</bean>
</pre>
-</div></div><p>Note that at the very minimum the filter needs to have 3
properties set-up:<br clear="none"> 1. IDP service address<br clear="none"> 2.
RACS address - it can be absolute or relative if RACS is collocated <br
clear="none"> (shares the same web application context) with the application
endpoint.<br clear="none"> 3. Reference to SSO State Provider.</p><p>The
following optional properties affecting the created SAML request may also be
set:</p><ul><li>String issuerId - it defaults to the base URI of the
application endpoint protected by this filter, for example,
"http://localhost:8080/services/app1";.</li><li><a shape="rect"
class="external-link"
href="http://svn.apache.org/viewvc/cxf/trunk/rt/rs/security/sso/saml/src/main/java/org/apache/cxf/rs/security/saml/sso/AuthnRequestBuilder.java?view=markup";>AuthnRequestBuilder</a>
authnRequestBuilder - A builder that constructs the SAML Request. It defaults
to <a shape="rect" class="external-link" href="http://svn.apache.org/viewv
c/cxf/trunk/rt/rs/security/sso/saml/src/main/java/org/apache/cxf/rs/security/saml/sso/DefaultAuthnRequestBuilder.java?view=markup">DefaultAuthnRequestBuilder</a>.</li></ul><p>The
IDP address is where filters will redirect users to and the RACS address is
where users will be redirected by IDP to.<br clear="none"> RACS will set up a
security context and redirect the user back to the original application address
by using the RelayState token which is included by the filters when users are
initially redirected to IDP.</p><h2 id="SAMLWebSSO-POSTBindingFilter">POST
Binding Filter</h2><p>POST Binding Filter is implemented by
org.apache.cxf.rs.security.saml.sso.SamlPostBindingFilter.</p><p>Here is an
example of a typical filter protecting a custom JAX-RS endpoint.</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><bean id="serviceBean"
class="org.apache.cxf.samlp.sso.BookStore"/>
+</div></div><p>Note that at the very minimum the filter needs to have 3
properties set-up:<br clear="none">1. IDP service address<br clear="none">2.
RACS address - it can be absolute or relative if RACS is collocated <br
clear="none">(shares the same web application context) with the application
endpoint.<br clear="none">3. Reference to SSO State Provider.</p><p>The
following optional properties affecting the created SAML request may also be
set:</p><ul><li>String issuerId - it defaults to the base URI of the
application endpoint protected by this filter, for example,
"http://localhost:8080/services/app1";.</li><li><a shape="rect"
class="external-link"
href="https://github.com/apache/cxf/blob/master/rt/rs/security/sso/saml/src/main/java/org/apache/cxf/rs/security/saml/sso/AuthnRequestBuilder.java";
rel="nofollow">AuthnRequestBuilder</a> authnRequestBuilder - A builder that
constructs the SAML Request. It defaults to <a shape="rect"
class="external-link" href="https://github.com/apache
/cxf/blob/master/rt/rs/security/sso/saml/src/main/java/org/apache/cxf/rs/security/saml/sso/DefaultAuthnRequestBuilder.java"
rel="nofollow">DefaultAuthnRequestBuilder</a>.</li></ul><p>The IDP address is
where filters will redirect users to and the RACS address is where users will
be redirected by IDP to.<br clear="none">RACS will set up a security context
and redirect the user back to the original application address by using the
RelayState token which is included by the filters when users are initially
redirected to IDP.</p><h2 id="SAMLWebSSO-POSTBindingFilter">POST Binding
Filter</h2><p>POST Binding Filter is implemented by
org.apache.cxf.rs.security.saml.sso.SamlPostBindingFilter.</p><p>Here is an
example of a typical filter protecting a custom JAX-RS endpoint.</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"><bean
id="serviceBean" class="org.apache.cxf.samlp.sso.BookStore"/>
<jaxrs:server address="/app2">
<jaxrs:serviceBeans>
<ref bean="serviceBean"/>
@@ -199,8 +200,8 @@ div.rbtoc1524513417198 li {margin-left:
</pre>
-</div></div><p>Note that the POST binding filter has the same 3 required
properties as org.apache.cxf.rs.security.saml.sso.SamlRedirectBindingFilter has
but also sets a "useDeflateEncoding" property for getting a SAML request
deflated. Some IDPs might not be able to process deflated SAML requests with
POST binding redirects thus the compression may be optionally
disabled.</p><p>What is actually different in this case from the GET-based
redirect is that the filter prepares an instance of <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/SamlRequestInfo.java";>SAMLRequestInfo</a>
which is subsequently bound to an XHTML view via a JSP filter. The view will
typically have a Java Script handler which will actually redirect the user to
IDP when it is loaded into the browser. The data to view binding is facilitated
by org.apache.cxf.jaxrs.provider.RequestDispatcherProvider, please s
ee <a shape="rect"
href="http://cxf.apache.org/docs/jax-rs-redirection.html#JAX-RSRedirection-WithRequestDispatcherProvider";>this
page</a> for more information.</p><p>One may prefer using the POST binding
filter in cases where having SAML request to IDP encoded as a URI parameter
prohibited.</p><p>Here is a typical JSP handler for binding
org.apache.cxf.rs.security.saml.sso.SAMLRequestInfo to the view:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><%@ page
import="javax.servlet.http.HttpServletRequest,org.apache.cxf.rs.security.saml.sso.SamlRequestInfo"
%>
+</div></div><p>Note that the POST binding filter has the same 3 required
properties as org.apache.cxf.rs.security.saml.sso.SamlRedirectBindingFilter has
but also sets a "useDeflateEncoding" property for getting a SAML request
deflated. Some IDPs might not be able to process deflated SAML requests with
POST binding redirects thus the compression may be optionally
disabled.</p><p>What is actually different in this case from the GET-based
redirect is that the filter prepares an instance of <a shape="rect"
class="external-link"
href="https://github.com/apache/cxf/blob/master/rt/rs/security/sso/saml/src/main/java/org/apache/cxf/rs/security/saml/sso/SamlRequestInfo.java";
rel="nofollow">SAMLRequestInfo</a> which is subsequently bound to an XHTML
view via a JSP filter. The view will typically have a Java Script handler which
will actually redirect the user to IDP when it is loaded into the browser. The
data to view binding is facilitated by
org.apache.cxf.jaxrs.provider.RequestDispatcherPro
vider, please see <a shape="rect"
href="http://cxf.apache.org/docs/jax-rs-redirection.html#JAX-RSRedirection-WithRequestDispatcherProvider";>this
page</a> for more information.</p><p>One may prefer using the POST binding
filter in cases where having SAML request to IDP encoded as a URI parameter
prohibited.</p><p>Here is a typical JSP handler for binding
org.apache.cxf.rs.security.saml.sso.SAMLRequestInfo to the view:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"><%@ page
import="javax.servlet.http.HttpServletRequest,org.apache.cxf.rs.security.saml.sso.SamlRequestInfo"
%>
<%
SamlRequestInfo data =
(SamlRequestInfo)request.getAttribute("samlrequestinfo");
@@ -223,7 +224,7 @@ div.rbtoc1524513417198 li {margin-left:
</html>
</pre>
</div></div><h2 id="SAMLWebSSO-SigningSAMLAuthenticationRequests">Signing SAML
Authentication Requests</h2><p>The filters may optionally sign SAML requests,
the following configuration properties can be set-up:</p><ul><li>boolean
signRequest - Whether to sign the AuthnRequest or not. The default is
false.</li><li>String signatureUsername - The keystore alias to use to sign the
AuthnRequest.</li><li>Crypto signatureCrypto - A WSS4J Crypto object if the
SAML AuthnRequest is to be signed.</li><li>String signaturePropertiesFile -
This points to a properties file that can be used to load a Crypto instance if
the SAML AuthnRequest is to be signed.</li><li>CallbackHandler callbackHandler
- A CallbackHandler object to retrieve the private key password used to sign
the request.</li><li>String callbackHandlerClass - A class name that is loaded
for use as the CallbackHandler object.</li></ul><p>Either the "signatureCrypto"
or "signaturePropertiesFile" properties must be set if "signRequest" is
set to true. Similarly, either "callbackHandler" or "callbackHandlerClass"
must be configured.</p><p>Example:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><bean id="ssoSignedRedirectPOST"
class="org.apache.cxf.rs.security.saml.sso.SamlPostBindingFilter">
+<pre class="brush: java; gutter: false; theme: Default"><bean
id="ssoSignedRedirectPOST"
class="org.apache.cxf.rs.security.saml.sso.SamlPostBindingFilter">
<property name="idpServiceAddress"
value="https://localhost:9443/idp"/>
<property name="assertionConsumerServiceAddress"
value="/racs/sso"/>
<property name="stateProvider" ref="stateManager"/>
@@ -240,11 +241,11 @@ div.rbtoc1524513417198 li {margin-left:
</bean>
</pre>
-</div></div><h2 id="SAMLWebSSO-FiltersandStateManagement">Filters and State
Management</h2><p>The following properties affect the way filters manage the
SSO state:</p><ul><li><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>
stateProvider</li><li>long stateTimeToLive - default is 2 minutes (in
milliseconds).</li><li>String webAppDomain.</li><li>boolean addWebAppContext -
default is true.</li><li>boolean boolean addEndpointAddressToContext - default
is false.</li></ul><p>The 'stateProvider' refers to a 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 and is used for filters and RACS coordinating with the filters
persisting the current user request state,
RACS validating it and persisting the current security context state and
filters getting the information about the context. Filters and RACS use a
'RelayState' token to work with the current request state. RACS persists the
security context and the filters retrieve and validate it using the cookie
which RACS also sets to point to this security context.</p><p>Note that a
'stateTimeToLive' property can be used to control how long the current security
context can be valid for.</p><p>Both filters and RACS use opaque cookies to
refer to the original request and security context state and 'webAppDomain',
'addWebAppContext' and 'addEndpointAddressToContext' affect the way these
cookies can be shared between multiple SP custom applications.</p><p>For
example, here is a typical Set Cookie request issued by a web application to
the browser:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;">Set-Cookie: value; Domain=mydomain; Path=/accounts;
Expires=Wed, 13-Jan-2021 22:23:01 GMT;
+</div></div><h2 id="SAMLWebSSO-FiltersandStateManagement">Filters and State
Management</h2><p>The following properties affect the way filters manage the
SSO state:</p><ul><li><a shape="rect" class="external-link"
href="https://github.com/apache/cxf/blob/master/rt/rs/security/sso/saml/src/main/java/org/apache/cxf/rs/security/saml/sso/state/SPStateManager.java";
rel="nofollow">SPStateManager</a> stateProvider</li><li>long stateTimeToLive -
default is 2 minutes (in milliseconds).</li><li>String
webAppDomain.</li><li>boolean addWebAppContext - default is
true.</li><li>boolean boolean addEndpointAddressToContext - default is
false.</li></ul><p>The 'stateProvider' refers to a custom <a shape="rect"
class="external-link"
href="https://github.com/apache/cxf/blob/master/rt/rs/security/sso/saml/src/main/java/org/apache/cxf/rs/security/saml/sso/state/SPStateManager.java";
rel="nofollow">SPStateManager</a> implementation and is used for filters and
RACS coordinating with the filters persisting th
e current user request state, RACS validating it and persisting the current
security context state and filters getting the information about the context.
Filters and RACS use a 'RelayState' token to work with the current request
state. RACS persists the security context and the filters retrieve and validate
it using the cookie which RACS also sets to point to this security
context.</p><p>Note that a 'stateTimeToLive' property can be used to control
how long the current security context can be valid for.</p><p>Both filters and
RACS use opaque cookies to refer to the original request and security context
state and 'webAppDomain', 'addWebAppContext' and 'addEndpointAddressToContext'
affect the way these cookies can be shared between multiple SP custom
applications.</p><p>For example, here is a typical Set Cookie request issued by
a web application to the browser:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default">Set-Cookie: value;
Domain=mydomain; Path=/accounts; Expires=Wed, 13-Jan-2021 22:23:01 GMT;
</pre>
-</div></div><p>By default, CXF will get a Cookie 'Path' property set to
something like "/services", where 'services' is the actual name of the war
archive.<br clear="none"> The 'addEndpointAddressToContext' property can be
further restrict this path to something like "/services/app1",
"/services/app2", where "/app1" and "/app2" are jaxrs:endpoint addresses, this
can be handy for testing, with every jaxrs:endpoint within a single war having
its own security context.<br clear="none"> If the custom SP application is
'spread' across multiple containers with different application context names,
then the 'addWebAppContext' can be set to 'false' leading to Cookie 'Path'
parameters set to '/' and the 'webAppDomain' property set to some shared
value.</p><p>Note that the stateTimeToLive property affects a Cookie 'Expires'
property but also used by filters and RACS to enforce that the internal state
has not expired.</p><h1 id="SAMLWebSSO-RequestAssertionConsumerService">Request
Assertion Consu
mer Service</h1><p>Request Assertion Consumer Service receives a SAML
Authentication Response and RelayState token from IDP, uses the token to
validate the response against the data available in the original SAML
Authentication Request, creates a security context if it does not already
exists for<br clear="none"> the current user, persists it and redirect the user
back to the original endpoint.</p><p>The RACS processes the SAML Response, and
validates it in a number of ways:</p><ul><li>The <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/SAMLProtocolResponseValidator.java";>SAMLProtocolResponseValidator</a>
validates the Response against the specifications and checks the signature of
the Response (if it exists), as well as doing the same for any child Assertion
of the Response. It validates the status code of the Response as
well.</li><li>The <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/SAMLSSOResponseValidator.java";>SAMLSSOResponseValidator</a>
validates the Response according to the Web SSO profile.</li></ul><p>Here is a
typical RACS consfiguration:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><bean id="consumerService"
class="org.apache.cxf.rs.security.saml.sso.RequestAssertionConsumerService">
+</div></div><p>By default, CXF will get a Cookie 'Path' property set to
something like "/services", where 'services' is the actual name of the war
archive.<br clear="none">The 'addEndpointAddressToContext' property can be
further restrict this path to something like "/services/app1",
"/services/app2", where "/app1" and "/app2" are jaxrs:endpoint addresses, this
can be handy for testing, with every jaxrs:endpoint within a single war having
its own security context.<br clear="none">If the custom SP application is
'spread' across multiple containers with different application context names,
then the 'addWebAppContext' can be set to 'false' leading to Cookie 'Path'
parameters set to '/' and the 'webAppDomain' property set to some shared
value.</p><p>Note that the stateTimeToLive property affects a Cookie 'Expires'
property but also used by filters and RACS to enforce that the internal state
has not expired.</p><h1 id="SAMLWebSSO-RequestAssertionConsumerService">Request
Assertion Consume
r Service</h1><p>Request Assertion Consumer Service receives a SAML
Authentication Response and RelayState token from IDP, uses the token to
validate the response against the data available in the original SAML
Authentication Request, creates a security context if it does not already
exists for<br clear="none">the current user, persists it and redirect the user
back to the original endpoint.</p><p>The RACS processes the SAML Response, and
validates it in a number of ways:</p><ul><li>The <a shape="rect"
class="external-link"
href="https://github.com/apache/cxf/blob/master/rt/rs/security/sso/saml/src/main/java/org/apache/cxf/rs/security/saml/sso/SAMLProtocolResponseValidator.java";
rel="nofollow">SAMLProtocolResponseValidator</a> validates the Response
against the specifications and checks the signature of the Response (if it
exists), as well as doing the same for any child Assertion of the Response. It
validates the status code of the Response as well.</li><li>The <a shape="rect"
clas
s="external-link"
href="https://github.com/apache/cxf/blob/master/rt/rs/security/sso/saml/src/main/java/org/apache/cxf/rs/security/saml/sso/SAMLSSOResponseValidator.java";
rel="nofollow">SAMLSSOResponseValidator</a> validates the Response according
to the Web SSO profile.</li></ul><p>Here is a typical RACS
consfiguration:</p><div class="code panel pdl" style="border-width: 1px;"><div
class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"><bean
id="consumerService"
class="org.apache.cxf.rs.security.saml.sso.RequestAssertionConsumerService">
<property name="stateProvider" ref="stateManager"/>
<!-- responses are expected to be deflated by default
<property name="supportDeflateEncoding" value="false"/>
@@ -266,8 +267,8 @@ div.rbtoc1524513417198 li {margin-left:
</jaxrs:serviceBeans>
</jaxrs:server>
</pre>
-</div></div><p>RACS is implemented as a JAX-RS server endpoint. It needs a
reference to the SSO State Manager and by default it expects that SAML Response
is deflated and Base64 encoded which can be changed. It shares the same
'stateTimeToLive' property with the filters which can be used to restrict the
time the security context state is kept for.</p><p>The following properties may
also be set up:</p><ul><li>boolean enforceKnownIssuer - Whether the Issuer of
the Response (and child Assertions) is "known" to the RACS. This value is
compared against the IDP URL configured on the filter. The default value is
true.</li><li><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/TokenReplayCache.java";>TokenReplayCache</a>
replayCache - A TokenReplayCache implementation to store Assertion IDs for the
POST binding to guard against replay attacks. The <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/EHCacheTokenReplayCache.java";>default</a>
uses an implementation based on EhCache.</li></ul><h2
id="SAMLWebSSO-DealingwithsignedSAMLResponses">Dealing with signed SAML
Responses</h2><p>RACS can be setup to support verifying signed Responses, or
signed Assertions contained in a Response. Similarly, either "callbackHandler"
or "callbackHandlerClass" must be configured if you wish to support decrypting
encrypted Assertions. For example:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><bean id="consumerService"
class="org.apache.cxf.rs.security.saml.sso.RequestAssertionConsumerService">
+</div></div><p>RACS is implemented as a JAX-RS server endpoint. It needs a
reference to the SSO State Manager and by default it expects that SAML Response
is deflated and Base64 encoded which can be changed. It shares the same
'stateTimeToLive' property with the filters which can be used to restrict the
time the security context state is kept for.</p><p>The following properties may
also be set up:</p><ul><li>boolean enforceKnownIssuer - Whether the Issuer of
the Response (and child Assertions) is "known" to the RACS. This value is
compared against the IDP URL configured on the filter. The default value is
true.</li><li><a shape="rect" class="external-link"
href="https://github.com/apache/cxf/blob/master/rt/rs/security/sso/saml/src/main/java/org/apache/cxf/rs/security/saml/sso/TokenReplayCache.java";
rel="nofollow">TokenReplayCache</a> replayCache - A TokenReplayCache
implementation to store Assertion IDs for the POST binding to guard against
replay attacks. The <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/EHCacheTokenReplayCache.java";>default</a>
uses an implementation based on EhCache.</li></ul><h2
id="SAMLWebSSO-DealingwithsignedSAMLResponses">Dealing with signed SAML
Responses</h2><p>RACS can be setup to support verifying signed Responses, or
signed Assertions contained in a Response. Similarly, either "callbackHandler"
or "callbackHandlerClass" must be configured if you wish to support decrypting
encrypted Assertions. For example:</p><div class="code panel pdl"
style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"><bean
id="consumerService"
class="org.apache.cxf.rs.security.saml.sso.RequestAssertionConsumerService">
<property name="stateProvider" ref="stateManager"/>
<property name="supportBase64Encoding" value="false"/>
@@ -276,8 +277,8 @@ div.rbtoc1524513417198 li {margin-left:
<property name="callbackHandlerClass"
value="org.apache.cxf.samlp.sso.SSOCallbackHandler"/>
</bean>
</pre>
-</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">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><ehcache xsi:noNamespaceSchemaLocation="ehcache.xsd"
updateCheck="false" monitoring="autodetect" dynamicConfig="true">
+</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="https://github.com/apache/cxf/blob/master/rt/rs/security/sso/saml/src/main/java/org/apache/cxf/rs/security/saml/sso/state/SPStateManager.java";
rel="nofollow">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="https://github.com/apache/cxf/blob/master/rt/rs/security/sso/saml/src/main/java/org/apache/cxf/rs/security/saml/sso/state/MemorySPStateManager.java";
rel="nofollow">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="https://github.com/apache/cxf/blob/m
aster/rt/rs/security/sso/saml/src/main/java/org/apache/cxf/rs/security/saml/sso/state/EHCacheSPStateManager.java"
rel="nofollow">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">
+<pre class="brush: java; gutter: false; theme: Default"><ehcache
xsi:noNamespaceSchemaLocation="ehcache.xsd" updateCheck="false"
monitoring="autodetect" dynamicConfig="true">
<diskStore path="/home/username/work/ehcache"/>
@@ -292,16 +293,13 @@ div.rbtoc1524513417198 li {margin-left:
memoryStoreEvictionPolicy="LRU"
/>
</ehcache>
-
-Assuming this configuration is saved in WEB-INF/ehcache.xml, the EhCache
provider can be configured as follows:
-
-{code:xml}
-<bean id="stateManager"
class="org.apache.cxf.rs.security.saml.sso.state.EHCacheSPStateManager">
- <constructor-arg value="/WEB-INF/ehcache.xml"/>
-</bean>
</pre>
-</div></div><h2 id="SAMLWebSSO-DistributedStateManagement">Distributed State
Management</h2><p>If you have a complex application supported by a number of
wars deployed into different containers, one has to decide whether to have a
single RequestAssertionConsumerService (RACS) endpoint which IDP will redirect
to when processing the user authentication requests or have a separate RACS
endpoint per every web application which all form a bigger
application.</p><p>For example, assume you have server1, server2 and server3
which all support a bigger application. One can have a serverRacs web
application which will host a RACS endpoint. Next, server1, server2 and server3
SSO filters will all point to this standalone RACS endpoint when redirecting
the user to IDP and IDP will eventually redirect the user to RACS which in turn
will redirect the user to the original target URI supported by server or
server2 or server3.</p><p>In this case, one has to decide how the state between
SSO security fi
lters protecting the individual servers and RACS will be shared.<br
clear="none"> One approach is to setup the Ehcache provider to use <a
shape="rect" class="external-link"
href="http://ehcache.org/documentation/configuration/distributed-cache-configuration";
rel="nofollow">Terracotta or RMI with the multicast</a> or implement the
alternative approach not involving Ehcache at all.</p><p>CXF offers a simple <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/HTTPSPStateManager.java";>HTTPSPStateManager</a>
provider which can be used to simplify the task of setting up the distributed
state cache, which can be used for simple distributed web applications or to
support the more advanced applications at the proof-of-concept stage.</p><p>For
example, the following jaxrs:endpoint can be deployed alongside the RACS
endpoint running in its own web application:</p><div class="code p
anel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"> <bean id="stateManager"
class="org.apache.cxf.rs.security.saml.sso.state.HTTPSPStateManager"/>
+</div></div><p>Assuming this configuration is saved in WEB-INF/ehcache.xml,
the EhCache provider can be configured as follows:</p><div class="code panel
pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"><bean
id="stateManager"
class="org.apache.cxf.rs.security.saml.sso.state.EHCacheSPStateManager">
+ <constructor-arg value="/WEB-INF/ehcache.xml"/>
+</bean></pre>
+</div></div><h2 id="SAMLWebSSO-DistributedStateManagement">Distributed State
Management</h2><p>If you have a complex application supported by a number of
wars deployed into different containers, one has to decide whether to have a
single RequestAssertionConsumerService (RACS) endpoint which IDP will redirect
to when processing the user authentication requests or have a separate RACS
endpoint per every web application which all form a bigger
application.</p><p>For example, assume you have server1, server2 and server3
which all support a bigger application. One can have a serverRacs web
application which will host a RACS endpoint. Next, server1, server2 and server3
SSO filters will all point to this standalone RACS endpoint when redirecting
the user to IDP and IDP will eventually redirect the user to RACS which in turn
will redirect the user to the original target URI supported by server or
server2 or server3.</p><p>In this case, one has to decide how the state between
SSO security fi
lters protecting the individual servers and RACS will be shared.<br
clear="none">One approach is to setup the Ehcache provider to use <a
shape="rect" class="external-link"
href="http://ehcache.org/documentation/configuration/distributed-cache-configuration";
rel="nofollow">Terracotta or RMI with the multicast</a> or implement the
alternative approach not involving Ehcache at all.</p><p>CXF offers a simple <a
shape="rect" class="external-link"
href="https://github.com/apache/cxf/blob/master/rt/rs/security/sso/saml/src/main/java/org/apache/cxf/rs/security/saml/sso/state/HTTPSPStateManager.java";
rel="nofollow">HTTPSPStateManager</a> provider which can be used to simplify
the task of setting up the distributed state cache, which can be used for
simple distributed web applications or to support the more advanced
applications at the proof-of-concept stage.</p><p>For example, the following
jaxrs:endpoint can be deployed alongside the RACS endpoint running in its own
web application:</p><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"> <bean
id="stateManager"
class="org.apache.cxf.rs.security.saml.sso.state.HTTPSPStateManager"/>
<bean id="consumerService"
class="org.apache.cxf.rs.security.saml.sso.RequestAssertionConsumerService">
<property name="stateProvider" ref="stateManager"/>
@@ -316,8 +314,8 @@ Assuming this configuration is saved in
</jaxrs:serviceBeans>
</jaxrs:server>
</pre>
-</div></div><p>Note that the RACS bean itself directly uses HTTPSPStateManager
which is also available as an HTTP endpoint for all the SSO security filters to
work with.<br clear="none"> Here is an example of how the SPStateManagers at
the individual SSO filter end can use this HTTP endpoint:</p><div class="code
panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<pre class="brush: java; gutter: false; theme: Default"
style="font-size:12px;"><jaxrs:client id="stateManager"
+</div></div><p>Note that the RACS bean itself directly uses HTTPSPStateManager
which is also available as an HTTP endpoint for all the SSO security filters to
work with.<br clear="none">Here is an example of how the SPStateManagers at the
individual SSO filter end can use this HTTP endpoint:</p><div class="code panel
pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<pre class="brush: java; gutter: false; theme: Default"><jaxrs:client
id="stateManager"
address="https://localhost:${racs.port}/racs";
serviceClass="org.apache.cxf.rs.security.saml.sso.state.HTTPSPStateManager"/>
@@ -330,7 +328,7 @@ Assuming this configuration is saved in
</bean>
</pre>
-</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><h1 id="SAMLWebSSO-MetadataService">Metadata
Service</h1><p> </p><p>A new <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/MetadataService.java;h=63619c313b6e2adae48f1b72476d3d1de81212c6;hb=HEAD";>MetadataService</a>
is available in CXF 3.1.0 and 3.0.5, which can publish SAML SSO Metadata for a
given service. Similar to the Logout Service, it is registered as an
independent endpoint or service bean. A sample spring configuration is
available <a shape="rect" class="external-li
nk"
href="https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f=systests/rs-security/src/test/java/org/apache/cxf/systest/jaxrs/security/samlsso/metadata-server.xml;h=e130b3cb727051f6c0db3e7e3d571dc19cb536cc;hb=HEAD";>here</a>
in the CXF system tests.</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><h1 id="SAMLWebSSO-LogoutService">Logout
Service</h1><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><h1
id="SAMLWebSSO-MetadataService">Metadata Service</h1><p>A new <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/MetadataService.java;h=63619c313b6e2adae48f1b72476d3d1de81212c6;hb=HEAD";>MetadataService</a>
is available in CXF 3.1.0 and 3.0.5, which can publish SAML SSO Metadata for a
given service. Similar to the Logout Service, it is registered as an
independent endpoint or service bean. A sample spring configuration is
available <a shape="rect" class="external-link"
href="https://git-wip-us.apache.org
/repos/asf?p=cxf.git;a=blob;f=systests/rs-security/src/test/java/org/apache/cxf/systest/jaxrs/security/samlsso/metadata-server.xml;h=e130b3cb727051f6c0db3e7e3d571dc19cb536cc;hb=HEAD">here</a>
in the CXF system tests.</p></div>
</div>
<!-- Content -->
</td>
