cxf-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r897643 [4/8] - in /websites/production/cxf/content: ./ cache/ docs/
Date Wed, 12 Feb 2014 16:48:13 GMT
Modified: websites/production/cxf/content/docs/jaxrs-kerberos.html
==============================================================================
--- websites/production/cxf/content/docs/jaxrs-kerberos.html (original)
+++ websites/production/cxf/content/docs/jaxrs-kerberos.html Wed Feb 12 16:48:12 2014
@@ -118,14 +118,12 @@ Apache CXF -- JAXRS Kerberos
          <td height="100%">
            <!-- Content -->
            <div class="wiki-content">
-<div id="ConfluenceContent"><p><span style="font-size:2em;font-weight:bold"> JAX-RS Kerberos Support </span></p><p></p>
+<div id="ConfluenceContent"><span style="font-size:2em;font-weight:bold"> JAX-RS Kerberos Support </span><p>&#160;</p><p><style type="text/css">/*<![CDATA[*/
+div.rbtoc1392223669926 {padding: 0px;}
+div.rbtoc1392223669926 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1392223669926 li {margin-left: 0px;padding-left: 0px;}
 
-<style type="text/css">/*<![CDATA[*/
-div.rbtoc1387471146927 {padding: 0px;}
-div.rbtoc1387471146927 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1387471146927 li {margin-left: 0px;padding-left: 0px;}
-
-/*]]>*/</style><div class="toc-macro rbtoc1387471146927">
+/*]]>*/</style></p><div class="toc-macro rbtoc1392223669926">
 <ul class="toc-indentation"><li><a shape="rect" href="#JAXRSKerberos-Introduction">Introduction</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#JAXRSKerberos-Setup">Setup</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#JAXRSKerberos-Unix">Unix</a></li><li><a shape="rect" href="#JAXRSKerberos-Windows">Windows</a></li></ul>
@@ -137,109 +135,11 @@ div.rbtoc1387471146927 li {margin-left: 
 </li><li><a shape="rect" href="#JAXRSKerberos-Serverconfiguration">Server configuration</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#JAXRSKerberos-ServiceprincipalnameandJAASConfiguration">Service principal name and JAAS Configuration</a></li><li><a shape="rect" href="#JAXRSKerberos-CallbackHandler">CallbackHandler</a></li></ul>
 </li><li><a shape="rect" href="#JAXRSKerberos-CredentialDelegation">Credential Delegation</a></li></ul>
-</div>
-
-<h1 id="JAXRSKerberos-Introduction">Introduction</h1>
-
-<p>Please see <a shape="rect" class="external-link" href="http://www.kerberos.org/software/tutorial.html" rel="nofollow">MIT Kerberos Tutorial</a> for a good introduction to Kerberos.<br clear="none">
-The <a shape="rect" class="external-link" href="http://msdn.microsoft.com/en-us/library/aa378747%28v=vs.85%29" rel="nofollow">Windows guide</a> as well as <a shape="rect" class="external-link" href="http://en.wikipedia.org/wiki/Kerberos_%28protocol%29" rel="nofollow">this Wikipedia page</a> are also worth checking.</p>
-
-<h2 id="JAXRSKerberos-Setup">Setup</h2>
-
-<h3 id="JAXRSKerberos-Unix">Unix</h3>
-
-<p>1. Install the packages</p>
-
-<p>&gt; sudo apt-get install krb5-kdc krb5-admin-server</p>
-
-<p>During the installation enter "localhost" as the host name for Kerberos servers (unless you have more specific host names to enter) and set a default realm, example, "MYCOMPANY.COM". Follow the 1.2 step from this <a shape="rect" class="external-link" href="http://coheigea.blogspot.com/2011/10/using-kerberos-with-web-services-part-i.html" rel="nofollow">blog entry</a> to get this default realm set up properly.</p>
-
-<p>2. Create principals</p>
-
-<p>From the step 1.3 at <a shape="rect" class="external-link" href="http://coheigea.blogspot.com/2011/10/using-kerberos-with-web-services-part-i.html" rel="nofollow">this blog entry</a>:</p>
-
-<p>2.1 Create master key:<br clear="none">
-&gt; sudo kdb5_util create -s</p>
-
-<p>2.2 Create user and service principals</p>
-
-<p>&gt; sudo kadmin.local </p>
-
-<p>followed by</p>
-
-<p>&gt; addprinc alice<br clear="none">
-&gt; addprinc HTTP/localhost</p>
-
-<p>where 'HTTP/localhost' is the typical service principal name used in the Negotiate scheme, replace 'localhost' if needed.<br clear="none">
-Add more user and service principals too as required.</p>
-
-<p>3 Start KDC</p>
-
-<p>&gt; sudo krb5kdc</p>
-
-<p>4. Create an optional ticket cache</p>
-
-<p>&gt; klist</p>
-
-<p>returns an empty response</p>
-
-<p>&gt; kinit alice</p>
-
-<p>&gt; klist</p>
-
-<p>confirms a TGT for 'alice' is in the cache.</p>
-
-<p>2.4 Create keytabs</p>
-
-<p>When keytabs are available, the principal password does not have to be specified in the login configuration.<br clear="none">
-Please follow the step 1.4 from <a shape="rect" class="external-link" href="http://coheigea.blogspot.com/2011/10/using-kerberos-with-web-services-part-i.html" rel="nofollow">this blog entry</a>.</p>
-
-<p>Note, creating a keytab actually resets an original principal password, example, after creating a keytab for 'alice' one would not be able to use the original password (TODO: apparently this can be restored - find out how). Thus, if you'd like to experiment with keytabs then you may want to have few user and service principals created, with only selected principals using keytabs. </p>
-
-<h3 id="JAXRSKerberos-Windows">Windows</h3>
-
-<p>Please check the relevant Windows configuration guide such as <a shape="rect" class="external-link" href="http://technet.microsoft.com/en-us/library/cc753173%28v=ws.10%29" rel="nofollow">this one</a>.</p>
-
-<h2 id="JAXRSKerberos-HTTPNegotiatescheme">HTTP Negotiate scheme </h2>
-
-<p>'Negotiate' authentication scheme is used to pass Kerberos service tickets over HTTP.<br clear="none">
-Example:</p>
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[
-Authorization: Negotiate &quot;the encrypted service ticket&quot;
+</div><h1 id="JAXRSKerberos-Introduction">Introduction</h1><p>Please see <a shape="rect" class="external-link" href="http://www.kerberos.org/software/tutorial.html" rel="nofollow">MIT Kerberos Tutorial</a> for a good introduction to Kerberos.<br clear="none"> The <a shape="rect" class="external-link" href="http://msdn.microsoft.com/en-us/library/aa378747%28v=vs.85%29" rel="nofollow">Windows guide</a> as well as <a shape="rect" class="external-link" href="http://en.wikipedia.org/wiki/Kerberos_%28protocol%29" rel="nofollow">this Wikipedia page</a> are also worth checking.</p><h2 id="JAXRSKerberos-Setup">Setup</h2><h3 id="JAXRSKerberos-Unix">Unix</h3><p>1. Install the packages</p><p>&gt; sudo apt-get install krb5-kdc krb5-admin-server</p><p>During the installation enter "localhost" as the host name for Kerberos servers (unless you have more specific host names to enter) and set a default realm, example, "MYCOMPANY.COM". Follow the 1.2 step from this <a shape="rect" class="external-link
 " href="http://coheigea.blogspot.com/2011/10/using-kerberos-with-web-services-part-i.html" rel="nofollow">blog entry</a> to get this default realm set up properly.</p><p>2. Create principals</p><p>From the step 1.3 at <a shape="rect" class="external-link" href="http://coheigea.blogspot.com/2011/10/using-kerberos-with-web-services-part-i.html" rel="nofollow">this blog entry</a>:</p><p>2.1 Create master key:<br clear="none"> &gt; sudo kdb5_util create -s</p><p>2.2 Create user and service principals</p><p>&gt; sudo kadmin.local</p><p>followed by</p><p>&gt; addprinc alice<br clear="none"> &gt; addprinc HTTP/localhost</p><p>where 'HTTP/localhost' is the typical service principal name used in the Negotiate scheme, replace 'localhost' if needed.<br clear="none"> Add more user and service principals too as required.</p><p>3 Start KDC</p><p>&gt; sudo krb5kdc</p><p>4. Create an optional ticket cache</p><p>&gt; klist</p><p>returns an empty response</p><p>&gt; kinit alice</p><p>&gt; klist</p><p
 >confirms a TGT for 'alice' is in the cache.</p><p>2.4 Create keytabs</p><p>When keytabs are available, the principal password does not have to be specified in the login configuration.<br clear="none"> Please follow the step 1.4 from <a shape="rect" class="external-link" href="http://coheigea.blogspot.com/2011/10/using-kerberos-with-web-services-part-i.html" rel="nofollow">this blog entry</a>.</p><p>Note, creating a keytab actually resets an original principal password, example, after creating a keytab for 'alice' one would not be able to use the original password (TODO: apparently this can be restored - find out how). Thus, if you'd like to experiment with keytabs then you may want to have few user and service principals created, with only selected principals using keytabs.</p><h3 id="JAXRSKerberos-Windows">Windows</h3><p>Please check the relevant Windows configuration guide such as <a shape="rect" class="external-link" href="http://technet.microsoft.com/en-us/library/cc753173%28v=
 ws.10%29" rel="nofollow">this one</a>.</p><h2 id="JAXRSKerberos-HTTPNegotiatescheme">HTTP Negotiate scheme</h2><p>'Negotiate' authentication scheme is used to pass Kerberos service tickets over HTTP.<br clear="none"> Example:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[Authorization: Negotiate &quot;the encrypted service ticket&quot;
 ]]></script>
-</div></div> 
-
-<h2 id="JAXRSKerberos-GSSAPI">GSS API</h2>
-
-<p>Please see <a shape="rect" class="external-link" href="http://docs.oracle.com/javase/7/docs/technotes/guides/security/jgss/tutorials/index.html" rel="nofollow">this</a> GSS API tutorial as well as check this <a shape="rect" class="external-link" href="http://www.javaactivedirectory.com/" rel="nofollow">blog</a> for a number of GSS API examples. Understanding GSS API may help when the way CXF Kerberos handlers work needs to be customized or when the available GSS credentials created outside of CXF need to be made available to CXF (for the credential delegation). </p>
-
-<h2 id="JAXRSKerberos-JAASKerberosModuleConfiguration">JAAS Kerberos Module Configuration</h2>
-
-<p><a shape="rect" class="external-link" href="http://docs.oracle.com/javase/6/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html" rel="nofollow">com.sun.security.auth.module.Krb5LoginModule</a> is typically used to login to Kerberos servers.</p>
-
-<h1 id="JAXRSKerberos-Clientconfiguration">Client configuration</h1>
-
-<h2 id="JAXRSKerberos-HTTPConduit">HTTPConduit</h2>
-
-<p>Please see <a shape="rect" href="http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html#ClientHTTPTransport%28includingSSLsupport%29-SpnegoAuthentication%28Kerberos%29">this page</a> for the information about Spnego/Kerberos HTTPConduit client support. </p>
-
-<h2 id="JAXRSKerberos-Interceptor">Interceptor</h2>
-
-<p>org.apache.cxf.jaxrs.security.KerberosAuthOutInterceptor can be used as an alternative to configuring HTTPConduit.</p>
-
-<p>KerberosAuthOutInterceptor and the HTTPConduit Spnego handler share the same base code. Having HTTPConduit configuration can be enough in many cases<br clear="none">
-especially when SSL is also being setup at the conduit level. Using the interceptor can be handy when testing as well as when setting few extra properties which is not easy to set up at the generic HTTP Conduit Authorization Policy level. </p>
-
-<p>The interceptor properties are explained in the following sub-sections</p>
-
-<h3 id="JAXRSKerberos-AuthorizationPolicy">Authorization Policy</h3>
-
-<p>As explained on <a shape="rect" href="http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html#ClientHTTPTransport%28includingSSLsupport%29-SpnegoAuthentication%28Kerberos%29">this page</a>, Authorization Policy typically needs to have its type set to "Negotiate" and its "authorization" property set to the name of the JAAS context. AuthorizationPolicy is set as a "policy" property on the interceptor, example:</p>
-
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[
-WebClient wc = WebClient.create(&quot;http://localhost:&quot; + PORT + &quot;/bookstore/books/123&quot;);
+</div></div><h2 id="JAXRSKerberos-GSSAPI">GSS API</h2><p>Please see <a shape="rect" class="external-link" href="http://docs.oracle.com/javase/7/docs/technotes/guides/security/jgss/tutorials/index.html" rel="nofollow">this</a> GSS API tutorial as well as check this <a shape="rect" class="external-link" href="http://www.javaactivedirectory.com/" rel="nofollow">blog</a> for a number of GSS API examples. Understanding GSS API may help when the way CXF Kerberos handlers work needs to be customized or when the available GSS credentials created outside of CXF need to be made available to CXF (for the credential delegation).</p><h2 id="JAXRSKerberos-JAASKerberosModuleConfiguration">JAAS Kerberos Module Configuration</h2><p><a shape="rect" class="external-link" href="http://docs.oracle.com/javase/6/docs/jre/api/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html" rel="nofollow">com.sun.security.auth.module.Krb5LoginModule</a> is typically used to login to Kerberos servers.</
 p><h1 id="JAXRSKerberos-Clientconfiguration">Client configuration</h1><h2 id="JAXRSKerberos-HTTPConduit">HTTPConduit</h2><p>Please see <a shape="rect" href="http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html#ClientHTTPTransport%28includingSSLsupport%29-SpnegoAuthentication%28Kerberos%29">this page</a> for the information about Spnego/Kerberos HTTPConduit client support.</p><h2 id="JAXRSKerberos-Interceptor">Interceptor</h2><p>org.apache.cxf.jaxrs.security.KerberosAuthOutInterceptor can be used as an alternative to configuring HTTPConduit.</p><p>KerberosAuthOutInterceptor and the HTTPConduit Spnego handler share the same base code. Having HTTPConduit configuration can be enough in many cases<br clear="none"> especially when SSL is also being setup at the conduit level. Using the interceptor can be handy when testing as well as when setting few extra properties which is not easy to set up at the generic HTTP Conduit Authorization Policy level.</p><p>The interc
 eptor properties are explained in the following sub-sections</p><h3 id="JAXRSKerberos-AuthorizationPolicy">Authorization Policy</h3><p>As explained on <a shape="rect" href="http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html#ClientHTTPTransport%28includingSSLsupport%29-SpnegoAuthentication%28Kerberos%29">this page</a>, Authorization Policy typically needs to have its type set to "Negotiate" and its "authorization" property set to the name of the JAAS context. AuthorizationPolicy is set as a "policy" property on the interceptor, example:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[WebClient wc = WebClient.create(&quot;http://localhost:&quot; + PORT + &quot;/bookstore/books/123&quot;);
         
 KerberosAuthOutInterceptor kbInterceptor = new KerberosAuthOutInterceptor();
         
@@ -252,40 +152,8 @@ WebClient.getConfig(wc).getOutIntercepto
         
 Book b = wc.get(Book.class);
 ]]></script>
-</div></div>
-
-<p>In this example, the <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/security/kerberos.cfg">KerberosClientKeyTab</a> policy is used which links to the available keytab; otherwise AuthorizationPolicy 'UserName' and 'Password' properties would most likely have to be set too (with the possible exceptions on Windows) </p>
-
-<h3 id="JAXRSKerberos-Configuringtheserviceprincipalname">Configuring the service principal name</h3>
-
-<p>Service principal identifies a target service.</p>
-
-<p>By default, the service principal name is calculated by concatenating "HTTP", "/" and the name of the target host, example, when invoking on "http://localhost:8080/services", the service principal name is set to "HTTP/localhost".</p>
-
-<p>The "servicePrincipalName" and "realm" properties can be used to customize it, example, setting "servicePrincipalName" to "HTTP/www.mycompany.com" and realm to "services.org" will result in the "HTTP/www.mycompany.com@services.org" service principal name being used. </p>
-
-<h3 id="JAXRSKerberos-UsingJAASConfiguration">Using JAAS Configuration</h3>
-
-<p>Both HTTPConduit and interceptor handlers need a "java.security.auth.login.config" system property set up. This property needs to point to the file containing the configuration of the specific Kerberos login module.</p>
-
-<p>Instead of setting this system property and maintaining a configuration file, one might want to use an implementation of javax.security.auth.login.Configuration and set it on the interceptor as a "loginConfig" property.    </p>
-
-<h3 id="JAXRSKerberos-Howtoavoidsettingusernameandpasswordproperties">How to avoid setting username and password properties</h3>
-
-<p>Typically, one may have to set AuthorizationPolicy UserName and Password properties for the Kerberos login module to authenticate the user.</p>
-
-<p>The next option is to create a keytab as noted in the Setup section, which will let one to avoid specifying a password property.<br clear="none">
-Finally, if the user actually owns the Java process which runs the code then no username and password properties have to be provided, assuming the Kerberos login configuration has 'useTicketCache' and possibly 'renewTGT' properties set to "true" </p>
-
-
-<h1 id="JAXRSKerberos-Serverconfiguration">Server configuration</h1>
-
-<p>org.apache.cxf.jaxrs.security.KerberosAuthenticationFilter can be used to protected JAX-RS endpoints and enforce that a Negotiate authentication scheme is used by clients, example:</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[
-
-&lt;bean id=&quot;kerberosFilter&quot; class=&quot;org.apache.cxf.jaxrs.security.KerberosAuthenticationFilter&quot;&gt;
+</div></div><p>In this example, the <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/security/kerberos.cfg">KerberosClientKeyTab</a> policy is used which links to the available keytab; otherwise AuthorizationPolicy 'UserName' and 'Password' properties would most likely have to be set too (with the possible exceptions on Windows)</p><h3 id="JAXRSKerberos-Configuringtheserviceprincipalname">Configuring the service principal name</h3><p>Service principal identifies a target service.</p><p>By default, the service principal name is calculated by concatenating "HTTP", "/" and the name of the target host, example, when invoking on "http://localhost:8080/services", the service principal name is set to "HTTP/localhost".</p><p>The "servicePrincipalName" and "realm" properties can be used to customize it, example, setting "servicePrincipalName" to "HTTP/www.mycompany.com" and realm to "services.org" 
 will result in the "HTTP/www.mycompany.com@services.org" service principal name being used.</p><h3 id="JAXRSKerberos-UsingJAASConfiguration">Using JAAS Configuration</h3><p>Both HTTPConduit and interceptor handlers need a "java.security.auth.login.config" system property set up. This property needs to point to the file containing the configuration of the specific Kerberos login module.</p><p>Instead of setting this system property and maintaining a configuration file, one might want to use an implementation of javax.security.auth.login.Configuration and set it on the interceptor as a "loginConfig" property.</p><h3 id="JAXRSKerberos-Howtoavoidsettingusernameandpasswordproperties">How to avoid setting username and password properties</h3><p>Typically, one may have to set AuthorizationPolicy UserName and Password properties for the Kerberos login module to authenticate the user.</p><p>The next option is to create a keytab as noted in the Setup section, which will let one to avoid speci
 fying a password property.<br clear="none"> Finally, if the user actually owns the Java process which runs the code then no username and password properties have to be provided, assuming the Kerberos login configuration has 'useTicketCache' and possibly 'renewTGT' properties set to "true"</p><h1 id="JAXRSKerberos-Serverconfiguration">Server configuration</h1><p>org.apache.cxf.jaxrs.security.KerberosAuthenticationFilter can be used to protected JAX-RS endpoints and enforce that a Negotiate authentication scheme is used by clients, example:</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[&lt;bean id=&quot;kerberosFilter&quot; class=&quot;org.apache.cxf.jaxrs.security.KerberosAuthenticationFilter&quot;&gt;
    &lt;property name=&quot;loginContextName&quot; value=&quot;KerberosServiceKeyTab&quot;/&gt;
 &lt;/bean&gt;
 
@@ -298,21 +166,8 @@ Finally, if the user actually owns the J
   &lt;/jaxrs:providers&gt;
 &lt;/jaxrs:server&gt;
 ]]></script>
-</div></div>
-
-<p>KerberosAuthenticationFilter will set a CXF <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/api/src/main/java/org/apache/cxf/security/SecurityContext.java">SecurityContext</a> on the current message if the authentication has been successful. This SecurityContext will return an instance of KerberosAuthenticationFilter$KerberosPrincipal, this Principal will return a 'simple' and 'kerberos' source principal names, example, given "HTTP/localhost@myrealm.com", Principal#getName will return "HTTP/localhost", and KerberosPrincipal#getKerberosName will return "HTTP/localhost@myrealm.com".</p>
-
-<h2 id="JAXRSKerberos-ServiceprincipalnameandJAASConfiguration">Service principal name and JAAS Configuration</h2>
-
-<p>Service principal name and JAAS Configuration can be optionally set up the same way they can be with KerberosAuthOutInterceptor, using 'servicePrincipalName' + 'realm' and "loginConfig" properties. </p>
-
-<h2 id="JAXRSKerberos-CallbackHandler">CallbackHandler</h2>
-
-<p>javax.security.auth.callback.CallbackHandler needs to be registered if no Kerberos key tabs are used, here is an example of setting it up from Java:</p>
-
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[
-public class TestResource {
+</div></div><p>KerberosAuthenticationFilter will set a CXF <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/api/src/main/java/org/apache/cxf/security/SecurityContext.java">SecurityContext</a> on the current message if the authentication has been successful. This SecurityContext will return an instance of KerberosAuthenticationFilter$KerberosPrincipal, this Principal will return a 'simple' and 'kerberos' source principal names, example, given "HTTP/localhost@myrealm.com", Principal#getName will return "HTTP/localhost", and KerberosPrincipal#getKerberosName will return "HTTP/localhost@myrealm.com".</p><h2 id="JAXRSKerberos-ServiceprincipalnameandJAASConfiguration">Service principal name and JAAS Configuration</h2><p>Service principal name and JAAS Configuration can be optionally set up the same way they can be with KerberosAuthOutInterceptor, using 'servicePrincipalName' + 'realm' and "loginConfig" properties.</p><h2 id="JAXRSKerberos-CallbackHandl
 er">CallbackHandler</h2><p>javax.security.auth.callback.CallbackHandler needs to be registered if no Kerberos key tabs are used, here is an example of setting it up from Java:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[public class TestResource {
  public static void main(String[] args) {
    JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean();
    sf.setResourceClasses(BookStore.class);
@@ -332,33 +187,22 @@ public class TestResource {
  }
 }
 ]]></script>
-</div></div> 
-
-<p>In this example, the <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/security/kerberos.cfg">KerberosServer</a> policy is used.</p>
-
-<h1 id="JAXRSKerberos-CredentialDelegation">Credential Delegation</h1>
-
-<p>Please see this <a shape="rect" href="http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html#ClientHTTPTransport%28includingSSLsupport%29-CredentialDelegation">section</a> on the way client-side credential delegation can be both enabled and implemented at the HTTP conduit level.</p>
-
-<p>Note that if you have a JAX-RS KerberosAuthenticationFilter protecting the endpoints, then the filter will have an  org.ietf.jgss.GSSContext instance available in the current CXF SecurityContext, via its KerberosAuthenticationFilter$KerberosSecurityContext implementation, which can be used to get to  org.ietf.jgss.GSSCredential if the credential delegation is supported for a given source principal. The current credential if any can be set as a client property next, for example:</p>
-
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[
-
-import org.ietf.jgss.GSSCredential;
+</div></div><p>In this example, the <a shape="rect" class="external-link" href="http://svn.apache.org/repos/asf/cxf/trunk/systests/jaxrs/src/test/java/org/apache/cxf/systest/jaxrs/security/kerberos.cfg">KerberosServer</a> policy is used.</p><h1 id="JAXRSKerberos-CredentialDelegation">Credential Delegation</h1><p>Please see this <a shape="rect" href="http://cxf.apache.org/docs/client-http-transport-including-ssl-support.html#ClientHTTPTransport%28includingSSLsupport%29-CredentialDelegation">section</a> on the way client-side credential delegation can be both enabled and implemented at the HTTP conduit level.</p><p>Note that if you have a JAX-RS KerberosAuthenticationFilter protecting the endpoints, then the filter will have an org.ietf.jgss.GSSContext instance available in the current CXF SecurityContext, via its KerberosAuthenticationFilter$KerberosSecurityContext implementation, which can be used to get to org.ietf.jgss.GSSCredential if the credential delegation is supported for a 
 given source principal. The current credential if any can be set as a client property next, for example:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[import org.ietf.jgss.GSSCredential;
 
 import org.apache.cxf.jaxrs.security.KerberosAuthenticationFilter;
 import org.apache.cxf.jaxrs.security.KerberosAuthenticationFilter.KerberosSecurityContext;
+import org.apache.cxf.phase.PhaseInterceptorChain;
+import org.apache.cxf.security.SecurityContext;
 
 @Path(&quot;service&quot;)
 public class MyResource {
 
-   @Context 
-   private javax.ws.rs.core.SecurityContext securityContext;
-
    @GET
    public Book getBookFromKerberosProtectedStore() {
        WebClient wc = webClient.create(&quot;http://internal.com/store&quot;);
+       SecurityContext securityContext = PhaseInterceptorChain.getCurrentMessage().get(SecurityContext.class);
+
        if (securityContext instanceof KerberosSecurityContext) {
            KerberosSecurityContext ksc = (KerberosSecurityContext)securityContext;
            GSSCredential cred = ksc.getGSSContext().getDelegCred();
@@ -371,13 +215,7 @@ public class MyResource {
 
 }
 ]]></script>
-</div></div>
-
-<p>The HTTPConduit or KerberosAuthOutInterceptor handler will use the available GSSCredential.</p>
-
-
-<p>Also note that KerberosAuthOutInterceptor can have its "credDelegation" property set to "true" if it is used instead of HTTPConduit on the client side, when enabling the delegation initially.</p>
-</div>
+</div></div><p>The HTTPConduit or KerberosAuthOutInterceptor handler will use the available GSSCredential.</p><p>Also note that KerberosAuthOutInterceptor can have its "credDelegation" property set to "true" if it is used instead of HTTPConduit on the client side, when enabling the delegation initially.</p></div>
            </div>
            <!-- Content -->
          </td>

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 Feb 12 16:48:12 2014
@@ -118,93 +118,30 @@ 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>
+<div id="ConfluenceContent"><span style="font-size:2em;font-weight:bold"> JAX-RS: SAML Web SSO</span><p>&#160;</p><p><style type="text/css">/*<![CDATA[*/
+div.rbtoc1392223669039 {padding: 0px;}
+div.rbtoc1392223669039 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1392223669039 li {margin-left: 0px;padding-left: 0px;}
 
-
-<style type="text/css">/*<![CDATA[*/
-div.rbtoc1387471153197 {padding: 0px;}
-div.rbtoc1387471153197 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1387471153197 li {margin-left: 0px;padding-left: 0px;}
-
-/*]]>*/</style><div class="toc-macro rbtoc1387471153197">
+/*]]>*/</style></p><div class="toc-macro rbtoc1392223669039">
 <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></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></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>
-</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 following 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">
-   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[
-&lt;dependency&gt;
+</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[&lt;dependency&gt;
   &lt;groupId&gt;org.apache.cxf&lt;/groupId&gt;
   &lt;artifactId&gt;cxf-rt-rs-security-sso-saml&lt;/artifactId&gt;
   &lt;version&gt;2.6.1&lt;/version&gt;
 &lt;/dependency&gt;
 ]]></script>
-</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 redirecting 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">
-<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[
-&lt;bean id=&quot;serviceBean&quot; class=&quot;org.apache.cxf.samlp.sso.BookStore&quot;/&gt;
+</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">
+<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[&lt;bean id=&quot;serviceBean&quot; class=&quot;org.apache.cxf.samlp.sso.BookStore&quot;/&gt;
 
 &lt;jaxrs:server address=&quot;/app1&quot;&gt; 
        &lt;jaxrs:serviceBeans&gt;
@@ -228,29 +165,8 @@ return to Request Assertion Consumer Ser
 &lt;/bean&gt;
 
 ]]></script>
-</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/viewvc/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">
-<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[
-&lt;bean id=&quot;serviceBean&quot; class=&quot;org.apache.cxf.samlp.sso.BookStore&quot;/&gt;
+</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">
+<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[&lt;bean id=&quot;serviceBean&quot; class=&quot;org.apache.cxf.samlp.sso.BookStore&quot;/&gt;
 &lt;jaxrs:server address=&quot;/app2&quot;&gt; 
     &lt;jaxrs:serviceBeans&gt;
        &lt;ref bean=&quot;serviceBean&quot;/&gt;
@@ -281,19 +197,8 @@ RACS will set up a security context and 
 
 
 ]]></script>
-</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 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">
-<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[
-&lt;%@ page import=&quot;javax.servlet.http.HttpServletRequest,org.apache.cxf.rs.security.saml.sso.SamlRequestInfo&quot; %&gt;
+</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">
+<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[&lt;%@ page import=&quot;javax.servlet.http.HttpServletRequest,org.apache.cxf.rs.security.saml.sso.SamlRequestInfo&quot; %&gt;
 
 &lt;%
     SamlRequestInfo data = (SamlRequestInfo)request.getAttribute(&quot;samlrequestinfo&quot;);
@@ -315,22 +220,8 @@ RACS will set up a security context and 
 &lt;/body&gt;
 &lt;/html&gt;
 ]]></script>
-</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">
-<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[
-&lt;bean id=&quot;ssoSignedRedirectPOST&quot; class=&quot;org.apache.cxf.rs.security.saml.sso.SamlPostBindingFilter&quot;&gt;
+</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">
+<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[&lt;bean id=&quot;ssoSignedRedirectPOST&quot; class=&quot;org.apache.cxf.rs.security.saml.sso.SamlPostBindingFilter&quot;&gt;
         &lt;property name=&quot;idpServiceAddress&quot; value=&quot;https://localhost:9443/idp&quot;/&gt;
         &lt;property name=&quot;assertionConsumerServiceAddress&quot; value=&quot;/racs/sso&quot;/&gt;
         &lt;property name=&quot;stateProvider&quot; ref=&quot;stateManager&quot;/&gt;
@@ -347,50 +238,11 @@ RACS will set up a security context and 
 &lt;/bean&gt;
 
 ]]></script>
-</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">
-<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[
-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="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">
+<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[Set-Cookie: value; Domain=mydomain; Path=/accounts; Expires=Wed, 13-Jan-2021 22:23:01 GMT;
 ]]></script>
-</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 Consumer 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">
-<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[
-
-&lt;bean id=&quot;consumerService&quot; class=&quot;org.apache.cxf.rs.security.saml.sso.RequestAssertionConsumerService&quot;&gt;
+</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">
+<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[&lt;bean id=&quot;consumerService&quot; class=&quot;org.apache.cxf.rs.security.saml.sso.RequestAssertionConsumerService&quot;&gt;
         &lt;property name=&quot;stateProvider&quot; ref=&quot;stateManager&quot;/&gt;
         &lt;!-- responses are expected to be deflated by default
         &lt;property name=&quot;supportDeflateEncoding&quot; value=&quot;false&quot;/&gt;
@@ -412,22 +264,8 @@ the current user, persists it and redire
    &lt;/jaxrs:serviceBeans&gt;
 &lt;/jaxrs:server&gt;
 ]]></script>
-</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">
-<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[
-&lt;bean id=&quot;consumerService&quot; class=&quot;org.apache.cxf.rs.security.saml.sso.RequestAssertionConsumerService&quot;&gt;
+</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">
+<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[&lt;bean id=&quot;consumerService&quot; class=&quot;org.apache.cxf.rs.security.saml.sso.RequestAssertionConsumerService&quot;&gt;
         &lt;property name=&quot;stateProvider&quot; ref=&quot;stateManager&quot;/&gt;
         &lt;property name=&quot;supportBase64Encoding&quot; value=&quot;false&quot;/&gt;
 
@@ -436,20 +274,8 @@ the current user, persists it and redire
         &lt;property name=&quot;callbackHandlerClass&quot; value=&quot;org.apache.cxf.samlp.sso.SSOCallbackHandler&quot;/&gt;
 &lt;/bean&gt;
 ]]></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>
-
-<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[
-&lt;ehcache xsi:noNamespaceSchemaLocation=&quot;ehcache.xsd&quot; updateCheck=&quot;false&quot; monitoring=&quot;autodetect&quot; dynamicConfig=&quot;true&quot;&gt;
+</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">
+<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[&lt;ehcache xsi:noNamespaceSchemaLocation=&quot;ehcache.xsd&quot; updateCheck=&quot;false&quot; monitoring=&quot;autodetect&quot; dynamicConfig=&quot;true&quot;&gt;
 
     &lt;diskStore path=&quot;/home/username/work/ehcache&quot;/&gt;
 
@@ -472,23 +298,8 @@ Assuming this configuration is saved in 
     &lt;constructor-arg value=&quot;/WEB-INF/ehcache.xml&quot;/&gt;
 &lt;/bean&gt;
 ]]></script>
-</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 filters 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 panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[
-    &lt;bean id=&quot;stateManager&quot; class=&quot;org.apache.cxf.rs.security.saml.sso.state.HTTPSPStateManager&quot;/&gt;
+</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">
+<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[    &lt;bean id=&quot;stateManager&quot; class=&quot;org.apache.cxf.rs.security.saml.sso.state.HTTPSPStateManager&quot;/&gt;
 
     &lt;bean id=&quot;consumerService&quot; class=&quot;org.apache.cxf.rs.security.saml.sso.RequestAssertionConsumerService&quot;&gt;
         &lt;property name=&quot;stateProvider&quot; ref=&quot;stateManager&quot;/&gt;
@@ -503,15 +314,8 @@ One approach is to setup the Ehcache pro
        &lt;/jaxrs:serviceBeans&gt;
     &lt;/jaxrs:server&gt;
 ]]></script>
-</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">
-<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[
-
-&lt;jaxrs:client id=&quot;stateManager&quot;
+</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">
+<script class="theme: Default; brush: xml; gutter: false" type="syntaxhighlighter"><![CDATA[&lt;jaxrs:client id=&quot;stateManager&quot;
          address=&quot;https://localhost:${racs.port}/racs&quot;
          serviceClass=&quot;org.apache.cxf.rs.security.saml.sso.state.HTTPSPStateManager&quot;/&gt;
          
@@ -524,12 +328,7 @@ Here is an example of how the SPStateMan
  &lt;/bean&gt;
 
 ]]></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></div>
            </div>
            <!-- Content -->
          </td>

Modified: websites/production/cxf/content/docs/using-cxf-with-maven.html
==============================================================================
--- websites/production/cxf/content/docs/using-cxf-with-maven.html (original)
+++ websites/production/cxf/content/docs/using-cxf-with-maven.html Wed Feb 12 16:48:12 2014
@@ -117,13 +117,8 @@ Apache CXF -- Using CXF with maven
          <td height="100%">
            <!-- Content -->
            <div class="wiki-content">
-<div id="ConfluenceContent"><h1 id="UsingCXFwithmaven-MavenPOMInformation">Maven POM Information</h1>
-
-<p>To use CXF within Maven, you'll need to declare the CXF dependencies in your POM. The CXF groupId is "org.apache.cxf". Here is a small example:</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[
-
-&lt;properties&gt;
+<div id="ConfluenceContent"><h1 id="UsingCXFwithmaven-MavenPOMInformation">Maven POM Information</h1><p>To use CXF within Maven, you'll need to declare the CXF dependencies in your POM. The CXF groupId is "org.apache.cxf". Here is a small example:</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[&lt;properties&gt;
   &lt;cxf.version&gt;2.2.3&lt;/cxf.version&gt;
 &lt;/properties&gt;
 
@@ -146,17 +141,8 @@ Apache CXF -- Using CXF with maven
 	&lt;/dependency&gt;
 &lt;/dependencies&gt;
 ]]></script>
-</div></div>
-
-<p>For information on using Maven with CXF and Tomcat, this <a shape="rect" class="external-link" href="http://www.jroller.com/gmazza/entry/web_service_tutorial" rel="nofollow">blog entry</a> may be helpful.</p>
-
-<h4 id="UsingCXFwithmaven-AdditionalDependencies">Additional Dependencies</h4>
-
-<p>Depending on your usage of CXF, you may need to bring in additional dependencies--the mvn install process will usually make clear what you are missing.  Here's a non-exhaustive list of additional CXF artifacts that may be needed:</p>
-
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[
-&lt;!-- Use dependency blocks for these CXF artifact Ids just as above --&gt;
+</div></div><p>For information on using Maven with CXF and Tomcat, this <a shape="rect" class="external-link" href="http://www.jroller.com/gmazza/entry/web_service_tutorial" rel="nofollow">blog entry</a> may be helpful.</p><h4 id="UsingCXFwithmaven-AdditionalDependencies">Additional Dependencies</h4><p>Depending on your usage of CXF, you may need to bring in additional dependencies--the mvn install process will usually make clear what you are missing. Here's a non-exhaustive list of additional CXF artifacts that may be needed:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[&lt;!-- Use dependency blocks for these CXF artifact Ids just as above --&gt;
 cxf-rt-core
 cxf-rt-frontend-simple
 cxf-rt-frontend-jaxws
@@ -168,16 +154,8 @@ cxf-rt-transports-jms
 cxf-rt-management
 cxf-common-utilities
 ]]></script>
-</div></div> 
-
-
-<h4 id="UsingCXFwithmaven-MavenSnapshotRepository">Maven Snapshot Repository</h4>
-
-<p>To work with the latest non-release versions of CXF (not recommended for production use), <a shape="rect" class="external-link" href="http://www.nabble.com/CXF-snapshot-location-has-changed.-td22460813.html#a22460813" rel="nofollow">updated nightly</a>, change the CXF version to the -SNAPSHOT version desired and add the Apache snapshot repository to both the repositories and pluginRepositories sections:</p>
-
-<div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
-<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[
-&lt;repositories&gt;
+</div></div><h4 id="UsingCXFwithmaven-MavenSnapshotRepository">Maven Snapshot Repository</h4><p>To work with the latest non-release versions of CXF (not recommended for production use), <a shape="rect" class="external-link" href="http://www.nabble.com/CXF-snapshot-location-has-changed.-td22460813.html#a22460813" rel="nofollow">updated nightly</a>, change the CXF version to the -SNAPSHOT version desired and add the Apache snapshot repository to both the repositories and pluginRepositories sections:</p><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
+<script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[&lt;repositories&gt;
    ...other repos...
    &lt;repository&gt;
       &lt;id&gt;apache-snapshots&lt;/id&gt;
@@ -187,7 +165,7 @@ cxf-common-utilities
          &lt;enabled&gt;true&lt;/enabled&gt;
       &lt;/snapshots&gt;
    &lt;/repository&gt;
-&lt;/respositories&gt;
+&lt;/repositories&gt;
 
 &lt;pluginRepositories&gt;
    ...other repos...
@@ -196,9 +174,7 @@ cxf-common-utilities
    &lt;/pluginRepository&gt;
 &lt;/pluginRepositories&gt;
 ]]></script>
-</div></div>
-
-<p>The addition to the plugin repositories section is needed because the cxf-codegen-plugin, used for the WSDL2Java, Java2WS, etc. tasks, is downloaded using that entry.</p></div>
+</div></div><p>The addition to the plugin repositories section is needed because the cxf-codegen-plugin, used for the WSDL2Java, Java2WS, etc. tasks, is downloaded using that entry.</p></div>
            </div>
            <!-- Content -->
          </td>



Mime
View raw message