Announcement Announcement Module
Collapse
No announcement yet.
Filters and UserDetailsServiceImpl Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Filters and UserDetailsServiceImpl

    Hello together,

    Ive got some questions to Spring Security.

    I read that the necessary filters for securing a webapplications are the following:

    SecurityContextPersistenceFilter
    UsernamePasswordAuthenticationFilter
    ExceptionTranslationFilter
    FilterSecurityInterceptor

    Furthermore I read that by using the http-element of the security namespace these filters are automatically generated:

    SecurityContextPersistenceFilter
    ExceptionTranslationFilter
    FilterSecurityInterceptor

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

    Code:
      	<sec:authentication-manager>
      		<sec:authentication-provider user-service-ref="myUserDetailsService" >
                            <sec:password-encoder hash="md5" ref="passwordEncoder">
                                    <sec:salt-source ref="saltSource"/>
                            </sec:password-encoder>
      		</sec:authentication-provider>
      	</sec:authentication-manager>
    
      <bean id="myUserDetailsService" class="project.business.logic.UserDetailsServiceImpl">
          <property name="projectDao" ref="projectDao"/>
      </bean>
    I would be very grateful for an answer! Thank you! :-)

  • #2
    Originally posted by jeeper View Post
    Hello together,


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

    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


    • #3
      Thanks for your answer!
      -> 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? :-)

      sorry for reasking again..

      Comment


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

        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?

        Comment


        • #5
          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


          • #6
            Originally posted by jeeper View Post
            thanks for explaining. but it must be always something which calls the UsernamePasswordAuthenticationFilter right? without this filter, authentication won't work?
            No, you don't need it. You might be using Basic authentication instead, for example. Or X.509 authentication.

            Comment


            • #7
              ok.

              in the documentation is written:

              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.

              8.1 FilterSecurityInterceptor
              8.2 ExceptionTranslationFilter
              8.3 SecurityContextPersistenceFilter
              8.4 UsernamePasswordAuthenticationFilter
              thats why I thought the four of them are needed.

              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?
              Last edited by jeeper; Mar 10th, 2011, 12:13 PM.

              Comment


              • #8
                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


                • #9
                  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


                  • #10
                    Originally posted by jeeper View Post
                    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.
                    If you read UsernamePasswordAuthenticationFilter section it states:

                    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.
                    Originally posted by jeeper View Post
                    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


                    • #11
                      Hello, thanks for your answer!
                      Originally posted by rwinch View Post
                      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

                      if these two sentences are correct, I guess, I finally understand it

                      Comment


                      • #12
                        Sounds like you got it

                        Comment


                        • #13
                          great! thanks for your help!

                          Comment

                          Working...
                          X