Nice article. Fills in a few gaps in the Spring Security documentation!

Hello Willie,

Do I need a custom UserDetailsServiceImpl for this?

Because I tried to do this with JdbcDaoImpl, like this:

<-- 2 -- >

class="org.springframework.security.userdetails.jdbc.JdbcDaoImpl"

p:userDao="accountDao" />

but I received a NotWritablePropertyException:

SEVERE: Servlet /FlexServer threw load() exception org.springframework.beans.NotWritablePropertyException: Invalid property 'userDao' of bean class [org.springframework.security.userdetails.jdbc.JdbcDaoImpl]: Bean property 'userDao' is not writable or has an invalid setter method. Does the parameter type of the setter match the return type of the getter? at org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:787) at org.springframework.beans.BeanWrapperImpl.setPropertyValue(BeanWrapperImpl.java:643)

Thanks in advance, and for this very interesting article (as usual),

Greets, Jochen

Correct me if i am wrong but the line number 5 in listing 4:

Object salt = saltSource.getSalt(userDetails); 

is bound to return in the variable salt the Long representing the id of the object account. So why not use the id directly. That way we would simplify the code to something like this:

public void registerAccount(Account account) {  
accountDao.save(account);  
account.setPassword(passwordEncoder.encodePassword(password,  account.getId())); 
accountDao.save(account);  
} 

Am I oversimplifying. Please correct me if I am wrong since I will be using this stuff in a project. Thanks for the nice article.

Stole

I was a little hasty while submitting the post previously. The code should have read:

public void registerAccount(Account account) {  
 accountDao.save(account);  
 account.setPassword(
    passwordEncoder.encodePassword(account.getPassword(), account.getId()));
 accountDao.save(account);
} 

Stole

Ah. Sometimes one has to say a lot more in order not to repeat oneself.

The answer as to why you shouldn't change the code is simple. It may seam as a simplification to you, but in fact doing what you're proposing will make it harder to change the salt afterwards.

In case you want to switch from the id to something else as the salt you could simply change it in your security config.

p:userPropertyToUse="id" /> 

The main reason I would offer is this. There are two cases where you access the password: during account creation, and during authentication. A DaoAuthenticationProvider handles the authentication case and to use that, you need to inject it with a salt source. By using that same salt source during registration, you don't have to worry about manually syncing the two cases in the event that you decide to use something other than the ID: you would just change the XML configuration of the salt source itself.

Know that response is pretty late but hopefully it helps anyway.

...another way to say the same thing is that this is basically a DRY move.

I initially found your article because I couldn't find any documentation in Spring on how they mix the salt with the password. Thanks for letting me know about the braces e.g. password {salt}. By the way, how did you find that out? I'm frustrated that I couldn't find that from my reading of the documentation.

Decided to read your article and it cleared up a lot of confusion I had about the configuration - especially surrounding the authentication provider. I was declaring an authentication manager bean and the necessary list of providers. Nice to know I didn't need to do that but simply had to use the security:custom-authentication-provider tag!

Great article - thank you.

PUK

I've got a question about configuration. I've got two configuration files: security in one xml config (referenced from web.xml), and another xml config for the main dispatcher servlet (dispatcher-servlet.xml).

I already have a userDAO which is configured in the dispatcher-servlet.xml. This needs to be dependency injected into the UserDetailsService so I've repeated the userDAO bean in the security xml config too. This repitition is bad.

Additionally, I want to use the password encoder and salt source within a controller bean. Therefore I need to DI the password encoder and salt source beans into the controller bean. They're defined in different xml files.

How does someone get around this problem?

Thanks,

PUK

@PUK: Glad to know the article helped. Yeah, on the namespace config, that's a pretty nice feature. Behind the scenes it's still creating all the beans you'd normally create, but in effect the namespace config amounts to a domain-specific language that makes config more convenient and intuitive.

As far as finding out about the braces, it's been far enough back in time that I can't say for sure, but I'm about 90% confident that I had to dig into the source for that little gem. :-)

On your UserDao question and password encoder questions, I agree with you that DRY applies here. What I would do in the case you describe is have three separate bean config files:

1. an applicationContext.xml for high-reuse object like the UserDao
2. an applicationContext-security.xml for security objects so you can take advantage of the XML default namespace feature (so you don't have to repeat the "security:" prefix everywhere, and
3. a main-servlet.xml (or whatever you want to call it) for your web config. The web config will be able to see your applicationContext.xml but not vice versa.

Just make sure you load the app configs from the context loader instead of from the DispatcherServlet.

@Willie: I really appreciate the immediate response! Previous to reading it I had arrived at this solution:

1. applicationContext.xml (basically empty)
2. commonBeans.xml (userDao and a couple of other beans)
3. applicationContext-security.xml (import on commonBeans.xml followed by security configs)
4. dispatcher-servlet.xml (import on commonBeans.xml followed by servlet configs)

This solution was born out of my lack of knowledge and assumptions of the contexts and configuration files. I had figured that each xml file might only be able to reference beans known to its file. I was also unsure about the hierarchy of the contexts.

Obviously I was worried about my "solution" because of the duplication of beans in memory and this was set to grow because security and servlet both need message sources from i18n, etc).

The bit in your response about the web config being able to see the applicationContext.xml was a revelation. The common stuff is in applicationContext.xml and it all works very well.

I know you must be very busy with books, blogs, and your own development so thanks again!

PUK