Luke Taylor
17 years ago
1 changed files with 0 additions and 80 deletions
@ -1,80 +0,0 @@
@@ -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><bean id="authenticationProcessingFilter" |
||||
class="org.springframework.security.ui.webapp.SiteminderUsernamePasswordAuthenticationProcessingFilter"> |
||||
<property name="authenticationManager"><ref bean="authenticationManager"/></property> |
||||
<property name="authenticationFailureUrl"><value>/login.jsp?login_error=1</value></property> |
||||
<property name="defaultTargetUrl"><value>/security.do?method=getMainMenu</value></property> |
||||
<property name="filterProcessesUrl"><value>/j_spring_security_check</value></property> |
||||
<property name="siteminderUsernameHeaderKey"><value>SM_USER</value></property> |
||||
<property name="formUsernameParameterKey"><value>j_username</value></property> |
||||
</bean></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> |
||||
Loading…
Reference in new issue