From 7395e2b9000e5c0b9034320c19d8820b6691afcf Mon Sep 17 00:00:00 2001 From: Luke Taylor Date: Tue, 8 Apr 2008 11:54:29 +0000 Subject: [PATCH] SEC-639: Updated to filter-chain-map syntax. Also removed use of property editor configuration for FilterSecurityInterceptor examples --- src/docbkx/anon-auth-provider.xml | 32 ++++--- src/docbkx/common-auth-services.xml | 59 +++++++------ src/docbkx/secured-objects.xml | 101 +++++++++++------------ src/docbkx/siteminder-auth-provider.xml | 2 +- src/docbkx/supporting-infrastructure.xml | 16 ++-- 5 files changed, 100 insertions(+), 110 deletions(-) diff --git a/src/docbkx/anon-auth-provider.xml b/src/docbkx/anon-auth-provider.xml index 3ae8adabac..fdc334baa7 100644 --- a/src/docbkx/anon-auth-provider.xml +++ b/src/docbkx/anon-auth-provider.xml @@ -67,23 +67,21 @@ example: - <bean id="filterInvocationInterceptor" - class="org.springframework.security.intercept.web.FilterSecurityInterceptor"> - <property name="authenticationManager"><ref bean="authenticationManager"/></property> - <property name="accessDecisionManager"><ref local="httpRequestAccessDecisionManager"/></property> - <property name="objectDefinitionSource"> - <value> - CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON - PATTERN_TYPE_APACHE_ANT - /index.jsp=ROLE_ANONYMOUS,ROLE_USER - /hello.htm=ROLE_ANONYMOUS,ROLE_USER - /logoff.jsp=ROLE_ANONYMOUS,ROLE_USER - /acegilogin.jsp*=ROLE_ANONYMOUS,ROLE_USER - /**=ROLE_USER - </value> - </property> - </bean> - + + + + + + + + + + + " + + +]]> Rounding out the anonymous authentication discussion is the AuthenticationTrustResolver interface, with its corresponding AuthenticationTrustResolverImpl diff --git a/src/docbkx/common-auth-services.xml b/src/docbkx/common-auth-services.xml index e4c6caa5e8..f5a6c9156c 100644 --- a/src/docbkx/common-auth-services.xml +++ b/src/docbkx/common-auth-services.xml @@ -1,7 +1,8 @@ -Common Authentication Services - + + Common Authentication Services -
Mechanisms, Providers and Entry Points +
+ Mechanisms, Providers and Entry Points If you're using Spring Security-provided authentication @@ -18,17 +19,16 @@ Spring Security application will have such an entry, and it looks like this: - - - <filter> - <filter-name>filterChainProxy</filter-name> - <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class> - </filter> + + filterChainProxy + org.springframework.web.filter.DelegatingFilterProxy + - <filter-mapping> - <filter-name>filterChainProxy</filter-name> - <url-pattern>/*</url-pattern> - </filter-mapping> + + filterChainProxy + /* + ]]> The above declarations will cause every web request to be passed @@ -38,30 +38,27 @@ As explained in the filters section of this reference guide, the FilterChainProxy is a generally-useful class that enables web requests to be passed to different filters based on - the URL patterns. Those delegated filters are managed inside the + URL patterns. Those delegated filters are managed inside the application context, so they can benefit from dependency injection. Let's have a look at what the FilterChainProxy bean definition would look like inside your application context: - <bean id="filterChainProxy" - class="org.springframework.security.util.FilterChainProxy"> -<property name="filterInvocationDefinitionSource"> -<value> - CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON - PATTERN_TYPE_APACHE_ANT - /**=httpSessionContextIntegrationFilter,logoutFilter,authenticationProcessingFilter,basicProcessingFilter,securityContextHolderAwareRequestFilter,rememberMeProcessingFilter,anonymousProcessingFilter,exceptionTranslationFilter,filterInvocationInterceptor,switchUserProcessingFilter -</value> -</property> -</bean> + + + + +]]> - Internally Spring Security will use a - PropertyEditor to convert the string presented in - the above XML fragment into a - FilterInvocationDefinitionSource object. What's - important to note at this stage is that a series of filters will be + The filter-chain-map syntax from the security namespace + allows you to define the mapping from URLs to filter chains, using a sequence of + filter-chain child elements. Each of these defines a set of URLs using + the pattern attribute and a chain of filters using the filters + attribute.What's important to note at this stage is that a series of filters will be run - in the order specified by the declaration - and each of those - filters are actually the <bean id> of another - bean inside the application context. So, in our case some extra beans + filters are actually the id of another + bean in the application context. So, in our case some extra beans will also appear in the application context, and they'll be named httpSessionContextIntegrationFilter, logoutFilter and so on. The order that the filters diff --git a/src/docbkx/secured-objects.xml b/src/docbkx/secured-objects.xml index a6a92c0740..8e956d3de1 100644 --- a/src/docbkx/secured-objects.xml +++ b/src/docbkx/secured-objects.xml @@ -347,29 +347,29 @@ if (this.securityInterceptor == null) beans: -<bean id="exceptionTranslationFilter" - class="org.springframework.security.ui.ExceptionTranslationFilter"> - <property name="authenticationEntryPoint"><ref local="authenticationEntryPoint"/></property> -</bean> + + + -<bean id="authenticationEntryPoint" - class="org.springframework.security.ui.webapp.AuthenticationProcessingFilterEntryPoint"> - <property name="loginFormUrl"><value>/acegilogin.jsp</value></property> - <property name="forceHttps"><value>false</value></property> -</bean> + + + + -<bean id="filterSecurityInterceptor" - class="org.springframework.security.intercept.web.FilterSecurityInterceptor"> - <property name="authenticationManager"><ref bean="authenticationManager"/></property> - <property name="accessDecisionManager"><ref bean="accessDecisionManager"/></property> - <property name="objectDefinitionSource"> - <property name="filterInvocationDefinitionSource"> - <security:filter-invocation-definition-source path-type="regex"> - <security:intercept-url pattern="\A/secure/super/.*\Z" access="ROLE_WE_DONT_HAVE"/> - <security:intercept-url pattern="\A/secure/.*\" access="ROLE_SUPERVISOR,ROLE_TELLER"/> - </security:filter-invocation-definition-source> - </property> -</bean> + + + + + + + + + +]]> The ExceptionTranslationFilter provides the bridge between Java exceptions and HTTP responses. It is solely @@ -407,9 +407,12 @@ if (this.securityInterceptor == null) Level Design section of this document. The FilterSecurityInterceptor can be - configured with configuration attributes in two ways. The first is via - a property editor and the application context, which is shown above. - The second is via writing your own + configured with configuration attributes in two ways. The first, + which is shown above, is using the <filter-invocation-definition-source> + namespace element. This is similar to the <filter-chain-map> + used to configure a FilterChainProxy but the <intercept-url> + child elements only use the pattern and access attributes. + The second is by writing your own ObjectDefinitionSource, although this is beyond the scope of this document. Irrespective of the approach used, the ObjectDefinitionSource is responsible for returning @@ -430,8 +433,8 @@ if (this.securityInterceptor == null) little relevance to most users of the FilterSecurityInterceptor. - If using the application context property editor approach (as - shown above), commas are used to delimit the different configuration + When using the namespace option to configure the interceptor, + commas are used to delimit the different configuration attributes that apply to each HTTP URL. Each configuration attribute is assigned into its own SecurityConfig object. The SecurityConfig object is discussed in the High @@ -441,27 +444,26 @@ if (this.securityInterceptor == null) configuration attributes against FilterInvocations based on expression evaluation of the request URL. Two standard expression syntaxes are supported. The default is to treat all - expressions as regular expressions. Alternatively, the presence of a - PATTERN_TYPE_APACHE_ANT directive will cause all - expressions to be treated as Apache Ant paths. It is not possible to + expressions as Apache Ant paths and regular expressions are also supported + for ore complex cases. The path-type attribute is used + to specify the type of pattern being used. It is not possible to mix expression syntaxes within the same definition. For example, the - earlier configuration could be generated using Apache Ant paths as - follows: + previous configuration using regular expressions instead of Ant paths would be + written as follows: - <bean id="filterInvocationInterceptor" - class="org.springframework.security.intercept.web.FilterSecurityInterceptor"> -<property name="authenticationManager"><ref bean="authenticationManager"/></property> -<property name="accessDecisionManager"><ref bean="accessDecisionManager"/></property> -<property name="runAsManager"><ref bean="runAsManager"/></property> -<property name="objectDefinitionSource"> -<value> - CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON - PATTERN_TYPE_APACHE_ANT - /secure/super/**=ROLE_WE_DONT_HAVE - /secure/**=ROLE_SUPERVISOR,ROLE_TELLER -</value> -</property> -</bean> + + + + + + + + + + +]]> Irrespective of the type of expression syntax used, expressions are always evaluated in the order they are defined. Thus it is @@ -474,15 +476,6 @@ if (this.securityInterceptor == null) /secure/super/ pattern would never be evaluated. - The special keyword - CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON causes - the FilterInvocationDefinitionSource to - automatically convert a request URL to lowercase before comparison - against the expressions. Whilst by default the case of the request URL - is not converted, it is generally recommended to use - CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON and - write each expression assuming lowercase. - As with other security interceptors, the validateConfigAttributes property is observed. When set to true (the default), at startup time the diff --git a/src/docbkx/siteminder-auth-provider.xml b/src/docbkx/siteminder-auth-provider.xml index cd46eaef76..e9156e41c7 100644 --- a/src/docbkx/siteminder-auth-provider.xml +++ b/src/docbkx/siteminder-auth-provider.xml @@ -58,7 +58,7 @@ username parameter as well - just don't do this in production! Note that you'll need a - SiteminderAuthenticationProvider + SiteminderAuthenticationProvider configured against your ProviderManager in order to use the Siteminder authentication mechanism. Normally an AuthenticationProvider expects the password diff --git a/src/docbkx/supporting-infrastructure.xml b/src/docbkx/supporting-infrastructure.xml index d2273fa1cd..be53f74f6f 100644 --- a/src/docbkx/supporting-infrastructure.xml +++ b/src/docbkx/supporting-infrastructure.xml @@ -145,13 +145,15 @@ The filter chain is then declared in the application context, using code such as this: - -<bean id="filterChainProxy" class="org.springframework.security.util.FilterChainProxy"> - <sec:filter-chain-map path-type="ant"> - <sec:filter-chain pattern="/webServices/**" filters="httpSessionContextIntegrationFilterWithASCFalse,basicProcessingFilter,exceptionTranslationFilter,filterSecurityInterceptor"/> - <sec:filter-chain pattern="/**" filters="httpSessionContextIntegrationFilterWithASCTrue,authenticationProcessingFilter,exceptionTranslationFilter,filterSecurityInterceptor"/> - </sec:filter-chain-map> -</bean> + + + + + + +]]> + You may notice similarities with the way FilterSecurityInterceptor is declared. Both regular