Announcement Announcement Module
Collapse
No announcement yet.
Different authentications for front-end and back-end Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Different authentications for front-end and back-end

    Hi,

    I am new to Spring Security and I am trying to learn and use this framework in my web project. I have got a question here.

    Is it possible to have different authentication configurations for the system front-end and back-end as in login, register, logout pages, etc. I plan to have a different UI for the system back-end. Also I am using different entities (and classes) for front-end user and back-end administrator.

    FYI, I am using Spring MVC 3 and Hibernate 3.6. I am not asking for the complete solution but I hope someone can provide me with some useful reference or sample code.

    Thank you!

  • #2
    Spring Security 3.1.x (currently still in Milestone release) provides better built in support for this than 3.x. See the Advanced Namespace Configuration for details.

    Comment


    • #3
      Try to use more then one authentication-providers, deferent intercept URLs. Usefull link in previous answer.

      Comment


      • #4
        Originally posted by rwinch View Post
        Spring Security 3.1.x (currently still in Milestone release) provides better built in support for this than 3.x. See the Advanced Namespace Configuration for details.
        Try to use more then one authentication-providers, deferent intercept URLs. Usefull link in previous answer.
        Thanks rwinch and evgenij! However is the method applicable for Spring Security 3.0.x? After all 3.1.x is still a milestone release.

        Thank you once again!

        Comment


        • #5
          Try to use more then one authentication-providers, deferent intercept URLs. Usefull link in previous answer.
          After reading some reference documents, I realised what I want cannot be achieved by using different intercept URLs since I need seperate http element to define different login, logout, register, denied pages, etc.

          So I think I have to use Spring Security 3.1.x since it allows multiple http elements, at the mercy of the milestone release. Another question regarding this approach is how can I set which authentication-provider to inject in the http element? This is because I will have two authentication-provider elements which ultimately point to two different database tables respectively (front-end user and back-end administrator). I think the author of the following thread has the same problem as me.

          Comment


          • #6
            You can still do this with 3.x, but you will need to understand the Spring Security Architecture, may need some custom code, and you will not be able to use the namespace configuration. You could do it by creating two FilterChainProxy's and wiring them both in your web.xml. To learn how to configure w/out the namespace you can checkout this blog post. Note that 3.1.x makes this setup pretty trivial, but doing this w/ 3.x will likely be pretty difficult if you are not pretty familiar with the architecture.

            Comment


            • #7
              Originally posted by rwinch View Post
              You can still do this with 3.x, but you will need to understand the Spring Security Architecture, may need some custom code, and you will not be able to use the namespace configuration. You could do it by creating two FilterChainProxy's and wiring them both in your web.xml. To learn how to configure w/out the namespace you can checkout this blog post. Note that 3.1.x makes this setup pretty trivial, but doing this w/ 3.x will likely be pretty difficult if you are not pretty familiar with the architecture.
              Thanks for the reply. In that case I think I will use 3.1.x but how can I set which authentication-provider to use for each of the http elements? As I said I will have two different authentication-provider elements for the separate http elements.

              Thank you!

              Comment


              • #8
                Currently there is still no easy way to support different authentication managers for different http elements. The intention is that you can stack AuthenticationProvider's and have each of them tried in succession.

                Comment


                • #9
                  Originally posted by rwinch View Post
                  Currently there is still no easy way to support different authentication managers for different http elements. The intention is that you can stack AuthenticationProvider's and have each of them tried in succession.
                  Do you mean I have to create different custom filters for each of the Authentication Providers and then add them to the http elements by using the custom-filter tag? I was somehow inspired by the following blog post which shows how to integrate facebook connect by adding a custom filter. Is the process similar?
                  Code:
                  http://blog.kadirpekel.com/2009/11/09/facebook-connect-integration-with-spring-security/
                  Thank you!

                  Comment


                  • #10
                    I mean that you can have multiple AuthenticationProviders in the same AuthenticationManager (stack them). The AuthenticationProvider looks at the Authentication in AuthenticationProvider.supports to see if it can authenticate that type of token before trying to authenticate it. If it returns false it does not attempt to process that token. So if you have different types of Authentication objects (i.e. a TwitterToken, FacebookToken, etc) being populated by your filters you can reuse the same AuthenticationManager so long as the AuthenticationProviders only validate the Authentication they should.

                    Comment


                    • #11
                      Originally posted by rwinch View Post
                      I mean that you can have multiple AuthenticationProviders in the same AuthenticationManager (stack them). The AuthenticationProvider looks at the Authentication in AuthenticationProvider.supports to see if it can authenticate that type of token before trying to authenticate it. If it returns false it does not attempt to process that token. So if you have different types of Authentication objects (i.e. a TwitterToken, FacebookToken, etc) being populated by your filters you can reuse the same AuthenticationManager so long as the AuthenticationProviders only validate the Authentication they should.
                      Oh that sounds easier than creating custom filters. I have just implemented and tested the front-end user authentication successfully. I will try to implement other authentication providers including back-end admin, facebook, etc by using your approach.

                      Thanks a million, rwinch!

                      Comment

                      Working...
                      X