Here are some of the external pages mentioning Spring Security. If you've - found another, please let us know. -
FilterChainProxy class.manageability.org.- If you wish to try out this project, you are probably - looking for the - spring-security-xx.zip - file, which contains all of the officially released - JARs, a copy of all documentation, and two WAR - artifacts. The two WAR artifacts are from the Contacts - Sample and the Tutorial Sample application. The Tutorial - Sample consists of a "bare bones" configuration that - will get you up and running quickly, whereas the - Contacts Sample illustrates more advanced features. -
- -- The spring-security-xx-src.zip is intended for use with - IDEs. It does not contain the files needed to compile - Spring Security. It also does not contain the sources to - the sample applications. If you need any of these files, - please download from SVN. -
-- The official release ZIP files are available from - the - - Sourceforge File Release System - - . -
-- The Spring Security JARs are also available via the - - Central Maven Repository - - . -
-- Detailed instructions on downloading from CVS and - building from source are provided on the - Building with Maven - page. -
-- If you don't wish to access SVN directly, we provide - - nightly snaphot builds - - for your convenience. These should contain both source and binary - jars. The archive files are labelled with both the build date and the - subversion revision number used for the build. -
-Acegi Security is an open source project that provides comprehensive authentication - and authorisation services for enterprise applications based on - The Spring Framework. - Acegi Security can authenticate using a variety of pluggable providers, and - can authorise both web requests and method invocations. - Acegi Security provides an integrated security approach across - these various targets, and also offers access control list (ACL) capabilities to - enable individual domain object instances to be secured. At an implementation - level, Acegi Security is managed through Spring's inversion of control and - lifecycle services, and actually enforces security using interception through - servlet Filters and Java AOP frameworks. In terms of AOP framework support, Acegi - Security currently supports AOP Alliance (which is what the - Spring IoC container uses internally) and AspectJ, although additional frameworks - can be easily supported.
- -Let's assume you're developing an enterprise application based on Spring. - There are four security concerns you typically need to address: authentication, - web request security, service layer security (ie your methods that implement - business logic), and domain object instance security (ie different domain objects - have different permissions). With these typical requirements in mind: -
Ah-see-gee. Said quickly, without emphasis on any part. - Acegi isn't an acronym, name of a Greek God or anything similarly - impressive - it's just letters #1, #3, #5, #7 and #9 of the alphabet.
- -It's official name is Spring Security, - although we're happy for it to be abbreviated to - Acegi Security. Please don't just call it Acegi, though, - as that gets confused with the name of the company that maintains Acegi - Security.
80% of support questions are because people have not defined
- the necessary filters in web.xml, or the filters are being
- mapped in the incorrect order. Check the
- Reference Guide, which
- has a specific section on filter ordering.
The next most common source of problems stem from custom
- AuthenticationDao implementations that simply don't properly
- implement the interface contract. For example, they return null instead
- of the user not found exception, or fail to add in the
- GrantedAuthority[]s. Whilst DaoAuthenticationProvider
- does its best to check the AuthenticationDao returns a valid
- UserDetails, we suggest you write the
- UserDetails object to the log and check it looks correct.
A common user problem with infinite loop and redirecting to the login page - is caused by accidently configuring the login page as a "secured" resource. - Generally make sure you mark your login page as requiring ROLE_ANONYMOUS. -
If you are securing web resources and they dont seem to be matched in the URL patterns, - check the objectDefinitionSource in the FilterSecurityInterceptor. - If you are using the CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON setting, - then the URL patterns configured MUST be in lowercase. -
- For example, making a request ending in /someAction.do will need - to be configured as: /someaction.do (Note the case). -
-<property name="objectDefinitionSource"> - <value> - CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON - PATTERN_TYPE_APACHE_ANT - /index.jsp=ROLE_ANONYMOUS,ROLE_USER - /someaction.do=ROLE_USER - <value> -</property> -- -
A common user requirement is to disable / lock an account after a number of failed login attempts. - Acegi itself does not provide anything "out of the box", however in your application you can implement - and register an org.springframework.context.ApplicationListener. Inside your application - event listener you can then check for an instanceof the particular AuthenticationFailureEvent - and then call your application user management interface to update the user details. -
- For example: -
- public void onApplicationEvent(ApplicationEvent event) {
-
- // check failed event
- if(event instanceof AuthenticationFailurePasswordEvent){
- // call user management interface to increment failed login attempts, etc.
- . . .
- }
- }
-
-
- There are three things you must do to make a user password change take affect: -
The most important things to post with any support requests on the
- Spring Forums are your
- web.xml, applicationContext.xml (or whichever
- XML loads the security-related beans) as well as any custom
- AuthenticationDao you might be using. For really odd problems,
- also switch on debug-level logging and include the resulting log.
Acegi Security uses Commons Logging, just as Spring does. So you use the
- same approach as you'd use for Spring. Most people output to Log4J, so
- the following log4j.properties would work:
In most cases write an AuthenticationDao which returns
- a subclass of User. Alternatively, write your own
- UserDetails implementation from scratch and return that.
Acegi Security targets enterprise applications, which are typically - multi-user, data-oriented applications that are important to - the core business. Acegi Security was designed to provide a portable and effective - security framework for this target application type. It was not designed for securing - limited privilege runtime environments, such as web browser applets.
- -We did consider JAAS when designing Acegi Security, but it simply - wasn't suitable for our purpose. We needed to avoid complex JRE configurations, - we needed container portability, and we wanted maximum leveraging of the Spring IoC - container. Particularly as limited privilege runtime environments were not - an actual requirement, this lead to the natural design of Acegi Security as - it exists today.
Acegi Security already provides some JAAS integration. It can today authenticate - via delegation to a JAAS login module. This means it offers the same level of JAAS - integration as many web containers. Indeed the container adapter model supported by - Acegi Security allows Acegi Security and container-managed security to happily - co-exist and benefit from each other. Any debate about Acegi Security and JAAS - should therefore centre on the authorisation issue. An evaluation of major - containers and security frameworks would reveal that Acegi Security is by no - means unusual in not using JAAS for authorisation.
-There are many examples of open source applications being preferred to - official standards. A few that come to mind in the Java community include - using Spring managed POJOs (rather than EJBs), Hibernate (instead of entity beans), - Log4J (instead of JDK logging), Tapestry (instead of JSF), and Velocity/FreeMarker - (instead of JSP). It's important to recognise that many open source projects do - develop into de facto standards, and in doing so play a legitimate and beneficial - role in professional software development.
Yes. If you've written something and it works well, please feel free to share it. - Simply email the contribution to the - acegisecurity-developers list. If you haven't yet - written the contribution, we encourage you to send your thoughts to the same - list so that you can receive some initial design feedback.
-For a contribution to be used, it must have appropriate unit test coverage and - detailed JavaDocs. It will ideally have some comments for the Reference Guide - as well (this can be sent in word processor or HTML format if desired). This - helps ensure the contribution maintains the same quality as the remainder of - the project.
We also welcome documentation improvements, unit tests, illustrations, - people supporting the user community (especially on the forums), design ideas, - articles, blog entries, presentations and alike. If you're looking for something - to do, you can always email the - acegisecurity-developers list and we'll be - pleased to suggest something. :-)
The following policies and procedures are intended to ensure that Spring Security will - continue to achieve its project objectives and support the community in the context of an - expanding development team. - -
- The following was unanimously supported by the community supporting following - discussion - on acegisecurity-developer. The policies and procedures below represent version 1.0 - and are effective 1 August 2005. -
Thanks for your help in connection with the above. If you have any suggestions for improving these - policies and procedures, please use the acegisecurity-developer list to raise them. - -
- Ben Alex
- Project Admin
-
-
- $Id$ - - - -
Many open source and commercial products either use Acegi Security or at least - support it. Following is a partial list of such products. If you've integrated Spring - Security with some other product, please let us know (preferably with a URL - to some page explaining the integration/use)... - -
Sometimes we get asked can Acegi Security be used without Spring. - This page provides a detailed answer.
Acegi Security started out as a method interceptor for Spring IoC container
- managed beans. Typically such beans provide services layer functions.
- Over time Acegi Security grew to offer authentication services, ThreadLocal management,
- web request filtering, extra AOP support,
- ACL features, additional authentication mechanisms and so on (for those interested,
- see our change log).
There's plenty written about why the - Spring Framework - is a good fit for modern applications. If you're not familiar with the benefits - Spring offers, please take a few minutes to learn more about it. In numerous - situations Spring will save you many months (or even years) of development time. - Not to mention your solutions will be better architected - (designed), better coded (implemented), and better supported (maintained) in the future. -
Acegi Security relies on the Spring IoC container to wire its classes, and execute lifecycle
- methods such as afterPropertiesSet(). Some Acegi Security classes also
- publish events to the ApplicationContext, although you could provide a mock
- implementation of ApplicationContext easily enough which no-ops the method.
- In other words, if you particularly didn't want Spring in your application, you could
- avoid its use by writing equivalent getter, setter and lifecycle invocation processes
- in standard Java code. This is a natural consequence of the Spring way of development,
- which emphasises framework independence (it is not because we think there are good
- reasons people would not use Spring).
If it sounds too hard (it's not) or counter-productive (it is) to replace Spring's IoC - services, don't forget you can always deploy Acegi Security and the Spring - IoC container solely for configuring Acegi Security. Spring does not mandate its - use in every part of your application. It will work quite successfully doing nothing more than - acting as a configuration mechanism for Acegi Security. Whilst some may regard this as excessive, - it's really no different than the traditional approach of every framework having its very - own XML or other proprietary configuration system. The main difference is that Spring is an - actual de facto standard, and you can gradually introduce it to other parts of your application - over time (if desired).
Acegi Security does not use any other Spring capabilities. Most notably, the
- entire architecture is based around Filters, not Spring's MVC framework.
- This allows it to be used with any MVC framework, or even with just straight JSPs.
- Acegi Security uses the AOP Alliance and AspectJ interfaces for method interception -
- it does not use any Spring-specific interfaces. As a consequence, Acegi Security is very
- portable to applications that do not leverage any of Spring's capabilities. We should note
- there are several very simple data access objects (DAOs) that use Spring's JDBC abstraction
- layer, although each of these are defined by a simple interface and it is very common in
- even native Spring-powered applications for these to be re-implemented using the application's
- persistence framework of choice (eg Hibernate).
-
-
In summary, we recommend you take a look at Spring and consider using it in your - applications. Irrespective of whether you do so or not, we strongly recommend you use it - for configuration and lifecycle management of Acegi Security. If that is also not desired, - Acegi Security can easily be executed without Spring at all, providing you implement - similar IoC services. Acegi Security has very minimal dependencies directly on Spring, - with it being useful in many non-Spring applications and with non-Spring frameworks. - - -
Several changes were made between version 0.3 and 0.4 of the project. -These changes increased the modularity of the code, enhanced unit testing, -made package roles clearer, and added compelling alternatives to container -adapters and using web.xml security constraints to protect HTTP resources. - -
Unfortunately, changes to the API and package locations were required. The -following should help most casual users of the project update their -applications: - -
-We hope you find the new features useful in your projects. - - - -
The following should help most casual users of the project update their -applications: -
-There are also lots of new features you might wish to consider for your -projects. These include CAS integration, pluggable password encoders -(such as MD5 and SHA), along with pluggable salt sources. We hope you find -the new features useful in your projects. - - - - -
-The following should help most casual users of the project update their -applications: -
- String username = authentication.getPrincipal();
- if (authentication.getPrincipal() instanceof User) {
- username = ((User) authentication.getPrincipal()).getUsername();
- }
-
- public User loadUserByUsername(String username)
- throws UsernameNotFoundException, DataAccessException {
-
- to:
-
- public UserDetails loadUserByUsername(String username)
- throws UsernameNotFoundException, DataAccessException {
-
-
- Existing concrete implementations would be returning User, which implements
- UserDetails, so no further code changes should be required.
-
- <filter>
- <filter-name>Spring Security Auto Integration Filter</filter-name>
- <filter-class>net.sf.acegisecurity.util.FilterToBeanProxy</filter-class>
- <init-param>
- <param-name>targetClass</param-name>
- <param-value>net.sf.acegisecurity.ui.AutoIntegrationFilter</param-value>
- </init-param>
- </filter>
-
-
- <bean id="autoIntegrationFilter" class="net.sf.acegisecurity.ui.AutoIntegrationFilter"/>
-
--The following should help most casual users of the project update their -applications: -
-The following should help most casual users of the project update their -applications: - -
-The following should help most casual users of the project update their -applications: - -
ContextHolder and all of its
- related classes have been removed. This significant change was made for the sake of consistency
- with the core Spring project's approach of a single ThreadLocal per use case,
- instead of a shared ThreadLocal for multiple use cases as the previous
- ContextHolder allowed. This is an important change in 0.9.0. Many applications
- will need to modify their code (and possibly web views) if they directly interact with the old
- ContextHolder. The replacement security ThreadLocal is called
-
- SecurityContextHolder and provides a single getter/setter for a
- SecurityContext.
- SecurityContextHolder guarantees to never return a null SecurityContext.
- SecurityContext provides single getter/setter for Authentication.ContextHolder,
- SecureContext and Context to directly call SecurityContextHolder
- and work with the SecurityContext (instead of the now removed Context
- and SecureContext interfaces).
- SecureContext ctx = SecureContextUtils.getSecureContext();
-
- to:
- SecurityContext ctx = SecurityContextHolder.getContext();
-
-
- <bean id="httpSessionContextIntegrationFilter" class="net.sf.acegisecurity.context.HttpSessionContextIntegrationFilter">
- <property name="context"><value>net.sf.acegisecurity.context.security.SecureContextImpl</value></property>
- </bean>
-
- to:
- <bean id="httpSessionContextIntegrationFilter" class="net.sf.acegisecurity.context.HttpSessionContextIntegrationFilter">
- <property name="context"><value>net.sf.acegisecurity.context.SecurityContextImpl</value></property>
- </bean>
-
- Context
- implementations, your applications no longer need to perform checking of null and
- unexpected Context implementation types.AbstractProcessingFilter has changed its getter/setter approach used for customised
- authentication exception directions. See the
- AbstractProcessingFilter JavaDocs to learn more.AnonymousProcessingFilter now has a removeAfterRequest property, which defaults to true. This
- will cause the anonymous authentication token to be set to null at the end of each request, thus
- avoiding the expense of creating a HttpSession in HttpSessionContextIntegrationFilter. You may
- set this property to false if you would like the anoymous authentication token to be preserved,
- which would be an unusual requirement.LoggerListener has changed. See the net.sf.acegisecurity.event package.
- <bean id="loggerListener" class="net.sf.acegisecurity.providers.dao.event.LoggerListener"/>
-
- to:
- <bean id="loggerListener" class="net.sf.acegisecurity.event.authentication.LoggerListener"/>
- <authz:authentication> JSP tag will generally need to set the operation
- property equal to "username", as reflection is now used to retrieve the property displayed.net.sf.acegisecurity.wrapper.ContextHolderAwareRequestFilter should note that it has been
- renamed to net.sf.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter.-The following should help most casual users of the project update their -applications: -