From 509ae1ccc9f659653c582b6811543f15709bd7e0 Mon Sep 17 00:00:00 2001 From: Scott McCrory Date: Mon, 7 Nov 2005 01:07:07 +0000 Subject: [PATCH] Improved Siteminder docs. --- doc/docbook/acegi.xml | 76 ++++++++++++++++++++++++++----------------- 1 file changed, 46 insertions(+), 30 deletions(-) diff --git a/doc/docbook/acegi.xml b/doc/docbook/acegi.xml index 44940815e2..0aaab4d419 100644 --- a/doc/docbook/acegi.xml +++ b/doc/docbook/acegi.xml @@ -1596,41 +1596,41 @@ public aspect DomainObjectInstanceSecurityAspect implements InitializingBean { Siteminder Authentication - Acegi Security provides a web filter that can be used to process - requests that have been pre-authenticated using Computer - Associates'/Netegrity's Siteminder product. Acegi's support assumes - that you're using Siteminder for authentication, - and your application (or backing datasource) is used for + Acegi Security provides a web filter + (net.sf.acegisecurity.ui.webapp.SiteminderAuthenticationProcessingFilter) + that can be used to process requests that have been pre-authenticated + by Computer Associates' Siteminder. This filter assumes that you're + using Siteminder for authentication, and your + application (or backing datasource) is used for authorization. The use of Siteminder for - authorization is not yet directly - supported. + authorization is not yet directly supported by + Acegi. - A Siteminder agent is typically set up on your web server to + Recall that a Siteminder agent is set up on your web server to intercept a user's first call to your application. This agent - redirects the user's initial request to a login page, and only after + redirects the initial request to a login page, and only after successful authentication does your application receive the request. Authenticated requests contain one or more HTTP headers populated by - the Siteminder agent. Below we'll assume that the primary request - header key is "SM_USER", but keep in mind that your organization's - header values may be different. Refer to your company's "single - sign-on" group for details. + the Siteminder agent. Below we'll assume that the request header key + containing the user's identity is "SM_USER", but of course your header + values may be different based on Siteminder policy server + configuration. Please refer to your company's "single sign-on" group + for header details. SiteminderAuthenticationProcessingFilter - As mentioned above the - net.sf.acegisecurity.ui.webapp.SiteminderAuthenticationProcessingFilter - attempts to identify a user based on specified HTTP headers. + The first step in setting up Acegi's Siteminder support is to + define an authenticationProcessingFilter bean and + give it an authenticationManager to use, as well + as to tell it where to send users upon success and failure and where + to find the Siteminder username and password values. Most people + won't need the password value since Siteminder has already + authenticated the user, so it's typical to use the same header for + both. - The first step is to define our - authenticationProcessingFilter bean and tell it - what authenticationManager to use, where to send - users upon success and failure and where to find the Siteminder - username and password values. Most people won't need the password - value since Siteminder has already authenticated the user, so it's - OK to use the same username header. - - <bean id="authenticationProcessingFilter" class="net.sf.acegisecurity.ui.webapp.SiteminderAuthenticationProcessingFilter"> + <!-- ======================== SITEMINDER AUTHENTICATION PROCESSING FILTER ======================= --> + <bean id="authenticationProcessingFilter" class="net.sf.acegisecurity.ui.webapp.SiteminderAuthenticationProcessingFilter"> <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> @@ -1657,14 +1657,20 @@ public aspect DomainObjectInstanceSecurityAspect implements InitializingBean { </bean> Note that your daoAuthenticationProvider - above will expect the password property to match what it expects. - Since authentication has already been handled by Siteminder and + above will expect the password property to match what it expects. In + this case, authentication has already been handled by Siteminder and you've specified the same HTTP header for both username and - password, daoAuthenticationProvider can simply - make sure the username and password values match. + password, so you can code + daoAuthenticationProvider to simply make sure the + username and password values match. 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 daoAuthenticationProvider + should simply be to assign roles and other properties needed by + subsequent method interceptors, etc. Finally we need to tell the - filterChainProxy to include + filterChainProxy to include the authenticationProcessingFilter in its operations. @@ -1682,6 +1688,16 @@ public aspect DomainObjectInstanceSecurityAspect implements InitializingBean { </value> </property> </bean> + + In summary, once the user has authenticated through + Siteminder, their header-loaded request will be brokered by + filterChainProxy to authenticationProcessingFilter, which in turn + will grab the user's identity from the SM_USER request header. The + user's identity will then be passed to the authenticationManager and + finally daoAuthenticationProvider will do the work of authorizing the user + against back-end databases, etc. and loading the UserDetails + implementation with roles, username and any other property you deem + relevant.