|
|
|
|
@ -12,12 +12,15 @@
|
|
|
|
|
<!-- http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-2.0.xsd" -->
|
|
|
|
|
|
|
|
|
|
<!-- introspect all bean definitions for an explicit object of a "required" type, and if not found, add it. You can turn OFF ones you dont want added via attributes -->
|
|
|
|
|
<security:security-autoconfig exceptionTranslation="disable" sessionContextIntegration="disable" logoutSupport="disable" filterChain="disable" servletRequestEmulation="disabled" anonyomousRoleGranter="disabled"/>
|
|
|
|
|
<security:security-autoconfig exceptionTranslation="disable"
|
|
|
|
|
sessionContextIntegration="disable" logoutSupport="disable"
|
|
|
|
|
filterChain="disable" servletRequestEmulation="disabled"
|
|
|
|
|
anonyomousRoleGranter="disabled" />
|
|
|
|
|
|
|
|
|
|
<!-- autodetect attribute is the default, and an exception is thrown if false, as the expectation is they will write their own legacy <beans> format
|
|
|
|
|
FilterChainProxy bean definition is dissatisfied with the auto approach. The auto approach simply creates a bean definition similar to that shown
|
|
|
|
|
below with the AUTODETECT_ALL_ORDERED_FILTERs. As suggested, this causes a runtime check of app ctx for all javax.servlet.Filter instances, and
|
|
|
|
|
for each that also implemented Ordered, these are automatically applied to the pattern shown (which is **/* in the case of autodetect=true).*-->
|
|
|
|
|
FilterChainProxy bean definition is dissatisfied with the auto approach. The auto approach simply creates a bean definition similar to that shown
|
|
|
|
|
below with the AUTODETECT_ALL_ORDERED_FILTERs. As suggested, this causes a runtime check of app ctx for all javax.servlet.Filter instances, and
|
|
|
|
|
for each that also implemented Ordered, these are automatically applied to the pattern shown (which is **/* in the case of autodetect=true).*-->
|
|
|
|
|
<security:filter-chain id="id" />
|
|
|
|
|
<bean id="dcdc" class="FilterChainProxy">
|
|
|
|
|
<property name="chainConfig">
|
|
|
|
|
@ -30,118 +33,151 @@
|
|
|
|
|
<!-- also provide an OrderedFilterAdapter, impls Filter and Ordered, and can be configured declaratively in Spring XML (eg SiteMesh), setOrder, setDelegate(Filter object) -->
|
|
|
|
|
|
|
|
|
|
<!-- creates a bean definition for an AccessDecisionManager; strategy defaults to AffirmativeBased;
|
|
|
|
|
superclass AbstractAccessDecisionManager requires refactoring so if no setProvider(List) given, it introspects app ctx for all AccessDecisionVoters
|
|
|
|
|
and uses their Ordered interface to apply them; if one doesn't implement Ordered, assume it is Integer.MAX_VALUE -->
|
|
|
|
|
<security:authorization-manager id="id" strategy="consensus|unanimous|affirmative"/>
|
|
|
|
|
superclass AbstractAccessDecisionManager requires refactoring so if no setProvider(List) given, it introspects app ctx for all AccessDecisionVoters
|
|
|
|
|
and uses their Ordered interface to apply them; if one doesn't implement Ordered, assume it is Integer.MAX_VALUE -->
|
|
|
|
|
<security:authorization-manager id="id"
|
|
|
|
|
strategy="consensus|unanimous|affirmative" />
|
|
|
|
|
|
|
|
|
|
<!-- ======================== AUTHENTICATION ======================= -->
|
|
|
|
|
|
|
|
|
|
<!-- sessionCreation defaults to ifRequired. -->
|
|
|
|
|
<security:session-context-integration id="httpSessionContextIntegrationFilter" sessionCreation="never|ifRequired|always" />
|
|
|
|
|
<security:session-context-integration
|
|
|
|
|
id="httpSessionContextIntegrationFilter"
|
|
|
|
|
sessionCreation="never|ifRequired|always" />
|
|
|
|
|
|
|
|
|
|
<!-- The rules are:
|
|
|
|
|
AuthenticationManager interface is implemented by ProviderManager
|
|
|
|
|
So if you have any auto-detection, create a ProviderManager definition
|
|
|
|
|
If ProviderManager.setProvider(List) is never called, auto-detect all AuthenticationProviders from app ctx, using Ordered to resolve their order
|
|
|
|
|
Every authentication mechanism OR provider must start with security:authentication-something
|
|
|
|
|
Use appropriate attrs and elements depending on provider or mechanism
|
|
|
|
|
-->
|
|
|
|
|
<security:authentication-repository id="id" repositoryBeanRef="beanIdOfRepositoryIfUnspecifiedAutoDetectTheirUserDetailsInstance">
|
|
|
|
|
<security:salt-source saltSourceBeanRef="beanRefOfAnExternalEncoder"/> <!-- or allow it to be written inline as an inner bean -->
|
|
|
|
|
<security:password-encoder encoder="md5|md5Hex|sha|shaHex|custom" encoderBeanRef="beanRefOfAnExternalEncoder"/> <!-- same story here, inner beans allowed -->
|
|
|
|
|
AuthenticationManager interface is implemented by ProviderManager
|
|
|
|
|
So if you have any auto-detection, create a ProviderManager definition
|
|
|
|
|
If ProviderManager.setProvider(List) is never called, auto-detect all AuthenticationProviders from app ctx, using Ordered to resolve their order
|
|
|
|
|
Every authentication mechanism OR provider must start with security:authentication-something
|
|
|
|
|
Use appropriate attrs and elements depending on provider or mechanism
|
|
|
|
|
-->
|
|
|
|
|
<security:authentication-repository id="id"
|
|
|
|
|
repositoryBeanRef="beanIdOfRepositoryIfUnspecifiedAutoDetectTheirUserDetailsInstance">
|
|
|
|
|
<security:salt-source
|
|
|
|
|
saltSourceBeanRef="beanRefOfAnExternalEncoder" />
|
|
|
|
|
<!-- or allow it to be written inline as an inner bean -->
|
|
|
|
|
<security:password-encoder
|
|
|
|
|
encoder="md5|md5Hex|sha|shaHex|custom"
|
|
|
|
|
encoderBeanRef="beanRefOfAnExternalEncoder" />
|
|
|
|
|
<!-- same story here, inner beans allowed -->
|
|
|
|
|
</security:authentication-repository>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<security:salt-source>
|
|
|
|
|
<security:system-wide systemWideSalt="12345"/>
|
|
|
|
|
<security-reflection userPropertyToUse="sss"/>
|
|
|
|
|
<security:system-wide systemWideSalt="12345" />
|
|
|
|
|
<security-reflection userPropertyToUse="sss" />
|
|
|
|
|
</security:salt-source>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<!-- the URLs are all mandatory and have no defaults (well, except authenticationUrl) -->
|
|
|
|
|
<security:authentication-form id="id" authenticationUrl="/login" loginFormUrl="/login.html" errorFormUrl="error.html"/>
|
|
|
|
|
|
|
|
|
|
<security:authentication-form id="id" authenticationUrl="/login"
|
|
|
|
|
loginFormUrl="/login.html" errorFormUrl="error.html" />
|
|
|
|
|
|
|
|
|
|
<!-- AuthenticationEntryPoints handled across the system via Ordered interface; every Acegi entry point has an order; the highest order wins and
|
|
|
|
|
is used as the entry point by ExceptionTranslationFilter; for things like BasicAuthenticationfilter, they're smart enough to know they need a
|
|
|
|
|
BasicAuthenticationProcessingFilterEntryPoint, so they use that one; here we have an entryPointOrder to say when we make the BasicEntryPoint,
|
|
|
|
|
we will call setOrder(2) such that this app effectively will use somehing with a higher order as the app-wide default -->
|
|
|
|
|
<security:authentication-basic id="id" realmName="Spring Security Application" entryPointOrder="2"/>
|
|
|
|
|
|
|
|
|
|
is used as the entry point by ExceptionTranslationFilter; for things like BasicAuthenticationfilter, they're smart enough to know they need a
|
|
|
|
|
BasicAuthenticationProcessingFilterEntryPoint, so they use that one; here we have an entryPointOrder to say when we make the BasicEntryPoint,
|
|
|
|
|
we will call setOrder(2) such that this app effectively will use somehing with a higher order as the app-wide default -->
|
|
|
|
|
<security:authentication-basic id="id"
|
|
|
|
|
realmName="Spring Security Application" entryPointOrder="2" />
|
|
|
|
|
|
|
|
|
|
<!-- This is used if they want an out-of-the-bx UserDetailsService; if they write their own, this goes away and they wire a legacy bean definition and then the various
|
|
|
|
|
beans depending on a UserDetailsService will auto-detect it at runtime OR provide a way of setUserDetailsService(UserDetailsService) if to specified explicitly.
|
|
|
|
|
If they fail to provide a repository, the security-autodetect will set one up for them with a few basic in-memory users and pwds -->
|
|
|
|
|
beans depending on a UserDetailsService will auto-detect it at runtime OR provide a way of setUserDetailsService(UserDetailsService) if to specified explicitly.
|
|
|
|
|
If they fail to provide a repository, the security-autodetect will set one up for them with a few basic in-memory users and pwds -->
|
|
|
|
|
<security:principal-repository id="id">
|
|
|
|
|
<security:ldap x="you can do the attributes and suitable nested elements"/>
|
|
|
|
|
<security:jdbc x="you can do the attributes and suitable nested elements"/>
|
|
|
|
|
<security:properties location="resourceStringToPropertiesFile"> <!-- if they specify a resource attrib, that means throw exception if they nest some user-definition data) -->
|
|
|
|
|
<security:user-definition username="ben" password="nottellingYou" enabled="true" it="more stuff if you want">
|
|
|
|
|
<security:granted-authority authority="ROLE_ANONYMOUS"/>
|
|
|
|
|
<ref bean="fooBarAuthority"/>
|
|
|
|
|
<security:ldap
|
|
|
|
|
x="you can do the attributes and suitable nested elements" />
|
|
|
|
|
<security:jdbc
|
|
|
|
|
x="you can do the attributes and suitable nested elements" />
|
|
|
|
|
<security:properties
|
|
|
|
|
location="resourceStringToPropertiesFile">
|
|
|
|
|
<!-- if they specify a resource attrib, that means throw exception if they nest some user-definition data) -->
|
|
|
|
|
<security:user-definition username="ben"
|
|
|
|
|
password="nottellingYou" enabled="true"
|
|
|
|
|
it="more stuff if you want">
|
|
|
|
|
<security:granted-authority authority="ROLE_ANONYMOUS" />
|
|
|
|
|
<ref bean="fooBarAuthority" />
|
|
|
|
|
</security:user-definition>
|
|
|
|
|
</security:properties>
|
|
|
|
|
</security:principal-repository>
|
|
|
|
|
|
|
|
|
|
<!-- makes the filter, but does little else, as it auto-detects everything -->
|
|
|
|
|
<security:authentication-remember-me-filter id="id" rememberMeServicesBeanRef="theId" />
|
|
|
|
|
<security:authentication-remember-me-filter id="id"
|
|
|
|
|
rememberMeServicesBeanRef="theId" />
|
|
|
|
|
|
|
|
|
|
<!-- services should auto-detect UserDetails from app ctx if principalRepository was not specified; key is handled in same way as discussed earlier -->
|
|
|
|
|
<security:authentication-remember-me-services id="id" key="someValue" principalRepositoryBeanRef="jdbcDaoImpl" />
|
|
|
|
|
<security:authentication-remember-me-services id="id"
|
|
|
|
|
key="someValue" principalRepositoryBeanRef="jdbcDaoImpl" />
|
|
|
|
|
|
|
|
|
|
<!-- key is optional; if unspecified, in the NamespaceHandler pick a rnd int and use for all unspecified key properties for acegi beans -->
|
|
|
|
|
<security:anonymous-role-granter " id="id" key="someValue" >
|
|
|
|
|
<security:granted-authority authority="ROLE_ANONYMOUS"/>
|
|
|
|
|
<ref bean="fooBarAuthority"/>
|
|
|
|
|
</security:anonymous-role-granter>
|
|
|
|
|
<security:anonymous-role-granter id="id" key="someValue">
|
|
|
|
|
<security:granted-authority authority="ROLE_ANONYMOUS" />
|
|
|
|
|
<ref bean="fooBarAuthority" />
|
|
|
|
|
</security:anonymous-role-granter>
|
|
|
|
|
|
|
|
|
|
<security:granted-authority id="fooBarAuthority" authority="ROLE_FOOBAR"/>
|
|
|
|
|
<security:granted-authority id="fooBarAuthority"
|
|
|
|
|
authority="ROLE_FOOBAR" />
|
|
|
|
|
|
|
|
|
|
<!-- If LogoutFilter does not have setHandlers populated, introspect app ctx for LogoutHandlers, using Ordered (if present, otherwise assume Integer.MAX_VALUE) -->
|
|
|
|
|
<!-- The logoutUrl and redirectAfterLogout are both optional and default to that shown -->
|
|
|
|
|
<security:logout-support id="logoutFilter" redirectAfterLogoutUrl="/" logoutUrl="/logout"/>
|
|
|
|
|
<security:logout-support id="logoutFilter"
|
|
|
|
|
redirectAfterLogoutUrl="/" logoutUrl="/logout" />
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<!-- ===================== HTTP CHANNEL REQUIREMENTS ==================== -->
|
|
|
|
|
|
|
|
|
|
<!-- channel security out of scope; they use existing bean definition format; the channel filter will auto-detect and use Ordered interface as discussed above -->
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<!-- any kind of ACL support is out of scope; frankly it is too hard for 1.1.0 -->
|
|
|
|
|
|
|
|
|
|
<!-- ensure element name is not overlapping with portlet or spring web flow or tapestry URI patterns, as this filter is incompatible with them -->
|
|
|
|
|
<security:authorization-http-url>
|
|
|
|
|
<security:url-mapping source="xml - the default and no other options" sourceBeanId="referenceToTheirObjectDefinitionSource">
|
|
|
|
|
<security:url-mapping
|
|
|
|
|
source="xml - the default and no other options"
|
|
|
|
|
sourceBeanId="referenceToTheirObjectDefinitionSource">
|
|
|
|
|
<!-- Specify security:uri-patterns in order of processing; each pattern must specify EITHER a regularExpression OR a path, but not both
|
|
|
|
|
and ALL patterns in the url-mapping MUST be of the SAME type (ie cannot mix a regular expression and Ant Path) - give exception if tried -->
|
|
|
|
|
<security:uri-pattern path ="/index.jsp" regularExpression="whatever">
|
|
|
|
|
<security:configuration-attribute attribute="ROLE_A"/>
|
|
|
|
|
<ref bean="someExternalConfigurationAttributeThatIsATopLevelBean"/>
|
|
|
|
|
and ALL patterns in the url-mapping MUST be of the SAME type (ie cannot mix a regular expression and Ant Path) - give exception if tried -->
|
|
|
|
|
<security:uri-pattern path="/index.jsp"
|
|
|
|
|
regularExpression="whatever">
|
|
|
|
|
<security:configuration-attribute attribute="ROLE_A" />
|
|
|
|
|
<ref
|
|
|
|
|
bean="someExternalConfigurationAttributeThatIsATopLevelBean" />
|
|
|
|
|
</security:uri-pattern>
|
|
|
|
|
<security:uri-pattern path ="/**" regularExperssion="whatever">
|
|
|
|
|
<security:configuration-attribute attribute="ROLE_A"/>
|
|
|
|
|
<ref bean="someExternalConfigurationAttributeThatIsATopLevelBean"/>
|
|
|
|
|
<security:uri-pattern path="/**"
|
|
|
|
|
regularExperssion="whatever">
|
|
|
|
|
<security:configuration-attribute attribute="ROLE_A" />
|
|
|
|
|
<ref
|
|
|
|
|
bean="someExternalConfigurationAttributeThatIsATopLevelBean" />
|
|
|
|
|
</security:uri-pattern>
|
|
|
|
|
</security:url-mapping>
|
|
|
|
|
</security:authorization-http-url>
|
|
|
|
|
|
|
|
|
|
<!-- the source refers to use of the relevant concete ObjectDefinitionSource; user can alternately specify their own instance and refer to it
|
|
|
|
|
via the sourceBeanId property; in that case they must specify "custom"; if unspecified, it means it's described as nested elements using the
|
|
|
|
|
security:method-pattern element, and you will therefore create it via the MethodDefinitionSourceEditor (that is what the default source=xml means, too)
|
|
|
|
|
For aspectj and springAop, that means create a MethodSecurityInterceptor and AspectJSecurityInterceptor bean definition respectively (in the case of
|
|
|
|
|
springAop, also create a MethodDefinitionSourceAdvisor); defaults to springAop=true, aspectJ=false -->
|
|
|
|
|
<security:authorization-joinpoint aspectj="false|true" springAop="true|false" >
|
|
|
|
|
<security:url-mapping source="custom|xml|attributes|annotations" sourceBeanId="referenceToTheirObjectDefinitionSource">
|
|
|
|
|
<security:method-pattern type="com.foo.Bar.whateverMethodNamePattern">
|
|
|
|
|
<security:configuration-attribute attribute="ROLE_A"/>
|
|
|
|
|
<ref bean="someExternalConfigurationAttributeThatIsATopLevelBean"/>
|
|
|
|
|
via the sourceBeanId property; in that case they must specify "custom"; if unspecified, it means it's described as nested elements using the
|
|
|
|
|
security:method-pattern element, and you will therefore create it via the MethodDefinitionSourceEditor (that is what the default source=xml means, too)
|
|
|
|
|
For aspectj and springAop, that means create a MethodSecurityInterceptor and AspectJSecurityInterceptor bean definition respectively (in the case of
|
|
|
|
|
springAop, also create a MethodDefinitionSourceAdvisor); defaults to springAop=true, aspectJ=false -->
|
|
|
|
|
<security:authorization-joinpoint aspectj="false|true"
|
|
|
|
|
springAop="true|false">
|
|
|
|
|
<security:url-mapping source="custom|xml|attributes|annotations"
|
|
|
|
|
sourceBeanId="referenceToTheirObjectDefinitionSource">
|
|
|
|
|
<security:method-pattern
|
|
|
|
|
type="com.foo.Bar.whateverMethodNamePattern">
|
|
|
|
|
<security:configuration-attribute attribute="ROLE_A" />
|
|
|
|
|
<ref
|
|
|
|
|
bean="someExternalConfigurationAttributeThatIsATopLevelBean" />
|
|
|
|
|
</security:method-pattern>
|
|
|
|
|
</security:url-mapping>
|
|
|
|
|
<!-- if get time, do a new security:pointcut-pattern -->
|
|
|
|
|
</security:authorization-joinpoint>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<!-- Basically accessDeniedUrl is optional, we if unspecified impl will auto-detect any AccessDeniedHandler in ctx and use it;
|
|
|
|
|
alternately if there are > 1 such handlers, we can nominate the one to use via accessDeniedBeanRef; provide nested elements for
|
|
|
|
|
other props; i do not mind if you move the access denied stuff to a sub-element -->
|
|
|
|
|
<security:exception-translation id="id" accessDeniedUrl="/accessDenied.jsp" accessDeniedBeanRef="theBeanToUse">
|
|
|
|
|
<security:entry-point path="/acegilogin.jsp" https="boolean"/>
|
|
|
|
|
alternately if there are > 1 such handlers, we can nominate the one to use via accessDeniedBeanRef; provide nested elements for
|
|
|
|
|
other props; i do not mind if you move the access denied stuff to a sub-element -->
|
|
|
|
|
<security:exception-translation id="id"
|
|
|
|
|
accessDeniedUrl="/accessDenied.jsp"
|
|
|
|
|
accessDeniedBeanRef="theBeanToUse">
|
|
|
|
|
<security:entry-point path="/acegilogin.jsp" https="boolean" />
|
|
|
|
|
</security:exception-translation>
|
|
|
|
|
|
|
|
|
|
</beans>
|
Vishal Puri