Spring/spring-security
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

SEC-271: Added more security elements

Browse Source
This commit is contained in:
Vishal Puri
2007-05-17 12:30:36 +00:00
parent e7d87275e0
commit 3eb9870162
9 changed files with 216 additions and 110 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
core/src/test/resources/org/acegisecurity/config/authentication-dao-defaults.xml
View File

@@ -15,14 +15,8 @@ http://www.springframework.org/schema/security http://www.springframework.org/sc
<!-- autocreate userDetailsService with dataSource(search in ctx) injected -->
<security:authentication-repository id="authenticationRepository">
<!--<security:salt-source>
<security:system-wide systemWideSalt="12345" />
</security:salt-source>
--><security:password-encoder encoderBeanRef="passwordEncoder"/>
<!-- OR <security:password-encoder>
<security:encoder method="md5"/>
</security:password-encoder>
--></security:authentication-repository>
<security:password-encoder encoderBeanRef="passwordEncoder" />
</security:authentication-repository>
<bean id="userDetailsService"
class="org.acegisecurity.userdetails.jdbc.JdbcDaoImpl">

2
core/src/test/resources/org/acegisecurity/config/logout-filter-with-handlers.xml
View File

@@ -14,7 +14,7 @@ http://www.springframework.org/schema/security http://www.springframework.org/sc
<!-- 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" />
redirectAfterLogoutUrl="/" logoutUrl="/logout"/>
<security:authentication-remember-me-services
id="rememberMeServices" key="someValue" />

172
core/src/test/resources/org/acegisecurity/config/security-namespaces.xml
View File

@@ -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>