Cwikius-Spring/spring-security
1
0
Fork 0
mirror of https://github.com/spring-projects/spring-security.git synced 2025-07-25 11:43:29 +00:00
Code Issues Packages Projects Releases Wiki Activity

Delete unused docbook file

Browse Source
This commit is contained in:
Luke Taylor 2009-06-12 10:46:16 +00:00
parent 8d4c09c191
commit ff5b90ef9d
1 changed files with 0 additions and 80 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

80
docs/manual/src/docbook/siteminder-auth-provider.xml
View File

@ -1,80 +0,0 @@
<chapter xmlns="http://docbook.org/ns/docbook" version="5.0" xml:id="siteminder"><info><title>Siteminder Authentication Mechanism</title></info>
<section xml:id="siteminder-overview"><info><title>Overview</title></info>
<para>Siteminder is a commercial single sign on solution by Computer
Associates.</para>
<para>Spring Security provides a filter,
<literal>SiteminderUsernamePasswordAuthenticationProcessingFilter</literal> and
provider, <literal>SiteminderAuthenticationProvider</literal> that can
be used to process requests that have been pre-authenticated by
Siteminder. This filter assumes that you're using Siteminder for
<emphasis>authentication</emphasis>, and that you're using Spring
Security for <emphasis>authorization</emphasis>. The use of Siteminder
for <emphasis>authorization</emphasis> is not yet directly supported
by Spring Security.</para>
<para>When using Siteminder, an agent is setup on your web server to
intercept a principal's first call to your application. The agent
redirects the web request to a single sign-on login page, and once
authenticated, your application receives the request. Inside the HTTP
request is a header - such as <literal>SM_USER</literal> - which
identifies the authenticated principal (please refer to your
organization's "single sign-on" group for header details in your
particular configuration).</para>
</section>
<section xml:id="siteminder-config"><info><title>Configuration</title></info>
<para>The first step in setting up Spring Security's Siteminder
support is to define the authentication mechanism that will inspect
the HTTP header discussed earlier. It will be responsible for
generating a <literal>UsernamePasswordAuthenticationToken</literal>
that is later sent to the
<literal>SiteminderAuthenticationProvider</literal>. Let's look at an
example:</para>
<para><programlisting>&lt;bean id="authenticationProcessingFilter"
class="org.springframework.security.ui.webapp.SiteminderUsernamePasswordAuthenticationProcessingFilter"&gt;
&lt;property name="authenticationManager"&gt;&lt;ref bean="authenticationManager"/&gt;&lt;/property&gt;
&lt;property name="authenticationFailureUrl"&gt;&lt;value&gt;/login.jsp?login_error=1&lt;/value&gt;&lt;/property&gt;
&lt;property name="defaultTargetUrl"&gt;&lt;value&gt;/security.do?method=getMainMenu&lt;/value&gt;&lt;/property&gt;
&lt;property name="filterProcessesUrl"&gt;&lt;value&gt;/j_spring_security_check&lt;/value&gt;&lt;/property&gt;
&lt;property name="siteminderUsernameHeaderKey"&gt;&lt;value&gt;SM_USER&lt;/value&gt;&lt;/property&gt;
&lt;property name="formUsernameParameterKey"&gt;&lt;value&gt;j_username&lt;/value&gt;&lt;/property&gt;
&lt;/bean&gt;</programlisting></para>
<para>In our example above, the bean is being provided an
<interfacename>AuthenticationManager</interfacename>, as is normally needed by
authentication mechanisms. Several URLs are also specified, with the
values being self-explanatory. It's important to also specify the HTTP
header that Spring Security should inspect. If you additionally want
to support form-based authentication (i.e. in your development
environment where Siteminder is not installed), specify the form's
username parameter as well - just don't do this in production!</para>
<para>Note that you'll need a
<literal>SiteminderAuthenticationProvider</literal>
configured against your <literal>ProviderManager</literal> in order to
use the Siteminder authentication mechanism. Normally an
<classname>AuthenticationProvider</classname> expects the password
property to match what it retrieves from the
<literal>UserDetailsSource</literal>, but in this case, authentication
has already been handled by Siteminder, so password property is not
even relevant. This may sound like a security weakness, but remember
that users have to authenticate with Siteminder before your
application ever receives the requests, so the purpose of your custom
<interfacename>UserDetailsService</interfacename> should simply be to build the
complete <interfacename>Authentication</interfacename> object (ie with suitable
<literal>GrantedAuthority[]</literal>s).</para>
<para>Advanced tip and word to the wise: If you additionally want to
support form-based authentication in your development environment
(where Siteminder is typically not installed), specify the form's
username parameter as well. Just don't do this in production!</para>
</section>
</chapter>