This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

-> Now Im wondering: Where is the UsernamePasswordAuthenticationFilter generated? Maybe by using the authentication-manager-element?

Also Ive got one problem. I use Spring 3 and Hibernate. I have a DAO-Class which contains the data access methods.
I store the users in a database. I wrote my own UserDetailsServiceImpl, where I use the DAO-Methods to load the necessary informations.

Now Im thinking that maybe something is wrong with my configuration. As I wrote my own implementation, I have my own AuthenticationProvider, is that correct?
In my applicationContext.xml I have the following code. I use user-service-ref which I thought means that I use an DaoAuthenticationProvider.

Did I make something wrong? Am I using a DaoAuthenticationProvider, although I wrote my own implementation? Im confused.
At the moment my database tables are the ones which are recommended (users and authorities), but what if I change them, does my application then not work anymore?

Now Im thinking that maybe something is wrong with my configuration. As I wrote my own implementation, I have my own AuthenticationProvider, is that correct?

You have implemented UserDetailService, not AuthenticationProvider. The namespace creates a DaoAuthenticationProvider which is injected with the UserDetailsService. See the appendix for more information.

At the moment my database tables are the ones which are recommended (users and authorities), but what if I change them, does my application then not work anymore?

If you are implementing your own UserDetailsService, then you can use any table structure you want, as long as the interface contract is supported. Spring Security doesn't care. The standard schema is only used by the default JDBC implementation of UserDetailsService.

Comment

-> Now Im wondering: Where is the UsernamePasswordAuthenticationFilter generated? Maybe by using the authentication-manager-element?
It's created by the form-login element.

Ok, thank you. And its correct, that these four filters are needed for securing a webapplication, right? without form-login, there cant be a authentication

You have implemented UserDetailService, not AuthenticationProvider. The namespace creates a DaoAuthenticationProvider which is injected with the UserDetailsService. See the appendix for more information.

so I use a normal DaoAuthenticationProvider with my own UserDetailsServiceImplementation, which means that everything is correct? :-)

Comment

You can use other types of authentication, so no, you don't need form-login. But you need something.

thanks for explaining. but it must be always something which calls the UsernamePasswordAuthenticationFilter right? without this filter, authentication won't work?

You need a UserDetailsService in order to use DaoAuthenticationProvider, but other than that I don't know whether everything is correct. Have you tried it? Do you actually have an error?

well, everything seems to work. I had problems when I changed my database tables, but it might be that it was because of something different. I did not have the time to look after it yet, but if I cant solve the problem, I will ask here again. First I wanted to make sure that "in theory" the architecture is correct. :-)

Comment

8. Core Security Filters
There are some key filters which will always be used in a web application which uses Spring Security, so we'll look at these and their supporting classes and interfaces first. We won't cover every feature, so be sure to look at the Javadoc for them if you want to get the complete picture.

to clarify it now: for securing a webapplication the three filters (8.1, 8.2, 8.3) AND an authentication possibility, which possibly uses the UsernamePasswordAuthenticationFilter, is needed.

authentication possibilities are basic authentication or form-login authentication... and so on(?).
it doesnt matter if the users data is stored in the xml-file or a database or....(?)

when using form-login, UsernamePasswordAuthenticationFilter is created.

right? :-)

and: for _every_ authentication, an AuthenticationManageris needed, right? you cant secure a webapplication without using an AuthenticationManager?
the AuthenticationManagercan be called be the UsernamePasswordAuthenticationFilter - if this filter does not exist, how is the AuthenticationManager called?

Comment

Peter Mularien | Blog
Author, Spring Security 3 (Book) - Packt Publishing, Available in print and eBook form
SCJP 5, Oracle DBAAny postings are my own opinion, and should not be attributed to my employer or clients.

re: AuthenticationManager, you are correct; except for some special kinds of authentication (I believe CAS is one, IIRC), an AuthenticationManager / AuthenticationProvider is usually used to verify the credentials in the Authentication token.

Keep in mind, however, that Spr Sec is a framework too, so if you have a highly custom environment, it's not necessarily the case that any of these rules hold true!

Comment

Keep in mind, however, that Spr Sec is a framework too, so if you have a highly custom environment, it's not necessarily the case that any of these rules hold true!

thanks for your answer.

does that also mean, that I theoretically can replace those filters ( FilterSecurityInterceptor, ExceptionTranslationFilter, SecurityContextPersistenceFilter) with my own ones? Im just asking because when I read, that those are not replaceable, I believed it
and when you say, that possibly when I customize a lot the rules might not hold true..... (?)

Comment

does that also mean, that I theoretically can replace those filters ( FilterSecurityInterceptor, ExceptionTranslationFilter, SecurityContextPersistenceFilter) with my own ones?

Theoretically you can replace Spring Security with another framework....so yes they can be replaced. Even if you stuck with Spring Security it could be replaced, but under most circumstances you will not need to and that is why http configuration does not allow you to replace them (bean configuration lets you do whatever you want though).

Im just asking because when I read, that those are not replaceable, I believed it
and when you say, that possibly when I customize a lot the rules might not hold true..... (?)

I can see how you might have mistook what you read to mean that the UsernamePasswordAuthenticationFilter is required, but if you re-read it you might be able to interpret it differently.

There are some key filters which will always be used in a web application which uses Spring Security, so we'll look at these and their supporting classes and interfaces first.

We've now seen the three main filters which are always present in a Spring Security web configuration. These are also the three which are automatically created by the namespace <http> element and cannot be substituted with alternatives. The only thing that's missing now is an actual authentication mechanism, something that will allow a user to authenticate. This filter is the most commonly used authentication filter and the one that is most often customized [13]. It also provides the implementation used by the <form-login> element from the namespace. There are three stages required to configure it.

and: for _every_ authentication, an AuthenticationManageris needed, right? you cant secure a webapplication without using an AuthenticationManager?
the AuthenticationManagercan be called be the UsernamePasswordAuthenticationFilter - if this filter does not exist, how is the AuthenticationManager called?

How Authentication is determined is highlighted in the Authentication section of the reference. In short, the SecurityContextHolder is consulted. However you want to populate that is up to you.

Comment

Theoretically you can replace Spring Security with another framework....so yes they can be replaced. Even if you stuck with Spring Security it could be replaced, but under most circumstances you will not need to and that is why http configuration does not allow you to replace them (bean configuration lets you do whatever you want though).

that sounds understandable - thanks!

I can see how you might have mistook what you read to mean that the UsernamePasswordAuthenticationFilter is required, but if you re-read it you might be able to interpret it differently.

you're right

How Authentication is determined is highlighted in the Authentication section of the reference. In short, the SecurityContextHolder is consulted. However you want to populate that is up to you.

so, generally, I do not have to use the AuthenticationManager, as long as I can put somehow a verified Authentication Object in my SecurityContext?

but in general most of the authentication possibilities which Spring Security offers use the AuthenticationManager, just like pmularien said