Spring Security 3.0.0.M2 Released

[Luke Taylor]

We're pleased to announce the second milestone release for Spring Security 3.0.0, which contains some notable changes to the configuration namespace which you should be aware of. Full details can be found in the changelog as usual, but the most notable change is that the use of the "decorator" style namespace elements has been discontinued.

To summarize the namespace changes:

• Namespace elements which create an AuthenticationProvider instance must be declared as children of the <authentication-manager>.
• The use of <custom-authentication-provider> has been dropped. Use <authentication-provider ref='yourProviderBeanName'> as a child of the <authentication-manager> element.
• <custom-filter> should no longer be used to decorate filter beans, but used with a ref="yourFilterBean" attribute as a child of the <http> block.
• <custom-after-invocation-provider> declarations should be replaced by <after-invocation-provider ref='yourProviderBeanName'>
  within the <global-method-security> element.
• The session-controller-ref has been moved to the concurrent-session-control element (SEC-1197).

All namespace configurations must now include the <authentication-manager> element in order to instantiate the AuthenticationManager (it is no longer created internally). These changes are also described in the updated manual and are used in the sample applications.

The blog entry on the M1 release is also still relevant so please read that if you haven't tried any of the 3.0.x releases yet.

[skal111]

Hello Luke, thank you for this new release. I wanted to give it a try this morning by upgrading my project from Spring M3 to M4 and Spring Security M1 to M2. When changing my namespace configuration to match M2 requirements I get the following error and I'm kinda lost.

This is what I used to have with M1 :

<security:authentication-provider>
   <security:user-service>
      <security:user name="user" password="user" authorities="ROLE_USER" />
      <security:user name="supervisor" password="supervisor" authorities="ROLE_SUPERVISOR" />
      <security:user name="admin" password="admin" authorities="ROLE_ADMIN" />
   </security:user-service>
</security:authentication-provider>

And in one of my classes I would retrieve the DaoAuthenticationProvider through autowiring in order to run some tests

@Autowired
private DaoAuthenticationProvider authenticationProvider ;

Everything was working fine.

Now when switching to M2 I changed my xml config file according to your post and M2 sample apps :

<security:authentication-manager>
   <security:authentication-provider>
      <security:user-service>
         <security:user name="user" password="user" authorities="ROLE_USER" />
         <security:user name="supervisor" password="supervisor" authorities="ROLE_SUPERVISOR" />
         <security:user name="admin" password="admin" authorities="ROLE_ADMIN" />
      </security:user-service>
   </security:authentication-provider>
</security:authentication-manager>

When I start my application the DaoAuthenticationProvider is no longer autowired :

Caused by: org.springframework.beans.factory.BeanCreationException: Could not autowire field: private org.springframework.security.authentication.dao.DaoAuthenticationProvider test.com.colleos.core.security.abstracts.AbstractSecurityTest.authenticationProvider; nested exception is org.springframework.beans.factory.NoSuchBeanDefinitionException: No unique bean of type [org.springframework.security.authentication.dao.DaoAuthenticationProvider] is defined: Unsatisfied dependency of type [class org.springframework.security.authentication.dao.DaoAuthenticationProvider]: expected at least 1 matching bean

I'm lost since looking at the updated documentation it reads that the <authentication-provider> element creates a DaoAuthenticationProvider bean

Thanks for your help.

[Luke Taylor]

Hi,

That's a consequence of just adding the providers as inner beans, directly to the list of providers, rather than registering them individually. They are no longer autowiring candidates. I've opened an issue to use bean references instead.

http://jira.springsource.org/browse/SEC-1225

Thanks for the feedback!

[pmularien]

Thanks Luke! I was just looking at moving to 3.0M4 today

[wshafiq]

After changes introduced in M2, I can't figure out a way to use concurrent session controller with a custom pre-authenticated authentication provider. I am using a explicitly configured FilterChainProxy in my application.

The only way to pass session-controller reference to ProviderManager is through concurrent-session-control element in http. But, if I use the http element, I end up creating two instances of ProviderManager, one (parent) by the authentication-manager element and second (child) by the http element. The sessionController attribute in parent ProviderManager refers to a NullConcurrentSessionController and has no knowledge of session controller configured within the http element.

Is there something I am missing?

[Luke Taylor]

I'm currently trying to redesign concurrent session control to overcome some of the issues with implementing it through the ProviderManager:

http://jira.springsource.org/browse/SEC-1229

Unfortunately moving it into the web layer will probably make the configuration requirements a bit more complex, especially if people are using custom login filters.