Announcement Announcement Module
Collapse
No announcement yet.
Writing a custom authentication mechanism Page Title Module
Move Remove Collapse
This topic is closed
X
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Writing a custom authentication mechanism

    Hey,

    I am currently investigating whether I can use Acegi security as part of a new project I am involved with.

    The project already relies quite heavily on Spring and as such, using Acegi for the security model seems to make sense.

    The problem I have is that we have a requirement for a rather strange and unique login mechanism which is not covered by Acegi out of the box. I assume I need to write a custom authentication mechanism but have not got a good idea where to start.

    Does anybody have any help or advice on how to do such a thing?

    Even a web based article on the subject would be good.

    Thanks for the help.

    Pete
    Last edited by PeteSlater; Jan 4th, 2006, 10:32 AM. Reason: I meant to write custom, not customer :)

  • #2
    Well, you can take a look at the how the existing providers are implemented, but you'll probably get more feedback if you can expand on what you mean by a "rather strange and unique login mechanism" and explain a bit more about your application requirements. For example, you haven't even say whether it's a web application you're writing.

    Comment


    • #3
      I got the same problem

      Hi.
      I must admit i have the same problem. I am trying to sort out how to implement my custom sql and stuff. I see in some examples there ref. to a class called PasswordDaoAuthenticationProvider. This is not part of the 1.0 RC-1 as fare as i could find... So what are the alternatives to that in the latest release?

      I find all this config a bit hard to get started with. So much to be set up in the right order :P

      -Erik

      Comment


      • #4
        My mecanism;
        I have more then one unique field in my db that ppl can use to log on.
        E.g. username, phonenumber or email..

        I also use an bigint id and no username in my role_user relation.

        Is this an easy fix?

        -Erik

        Comment


        • #5
          Clarification

          Sorry for the vagueness of my original post, I will endeavour to clarify it somewhat.

          We are developing a web based application and have a requirement to split user authentication over two ( or more! ) pages.

          For example, the user could enter the system and be presented with an initial set of authetication questions ( maybe a username and password for example ).

          Once that is entered, they could then be taken to a second page with yet more authentication questions ( date of birth or mothers maiden name for example ).

          Only when these details have been captured would we want to try to properly authenticate the user and allow them onto the system.

          My investiagtion to date has not borne fruit. I am thinking I will need to write my own Authentication Provider as well as a custom Authentication object to hold the authentication details.

          A simple username/password combination will not suffice in this instance as we will be needing additional authentication information as described above.

          Any assistance would be much appreciated.

          Thank you.

          Comment


          • #6
            Ah, "custom" is a bit clearer (I've changed the thread title too...)

            If you have a complicated workflow for the authentication process, it might be simpler to implement this separately using standard Spring controllers, for example, especially if there is a single entry point to your application and the user has to log in to proceed (rather than being asked to log in when they try to access something protected). This is often the case with things like online banking.

            If the user successfully completes the workflow, you can create the authentication object in your code and populate the session attribute used by
            HttpSessionContextIntegrationFilter to maintain the security context across requests. It's stored under the key defined by:

            HttpSessionContextIntegrationFilter.ACEGI_SECURITY _CONTEXT_KEY

            You can then redirect them to the Acegi-secured part of your application.

            If you want authentication that kicks in on demand, you can use the AuthenticationProcessingFilterEntryPoint class, but set the loginFormUrl property to point to your login workflow controller.
            http://acegisecurity.sourceforge.net...ntryPoint.html

            I think that should work Ok.
            Last edited by Luke Taylor; Jan 4th, 2006, 04:37 PM. Reason: Typo

            Comment


            • #7
              Luke,

              Thanks for the help and the prompt reply.
              I will be examining your suggestion in more detail tomorrow

              Thanks again.

              Pete

              Comment


              • #8
                Hi,

                When you mention Spring Controllers are you refering to Spring MVC Controller?
                If so, we are not using that part of Spring.
                We are simply using JSF as the presentation technology.

                Ideally I would like to lock down the entire application leaving only a couple of pages available to the general public. These pages would be the ones needed as part of the authentication process. Everything else could then only be accessed once the user has been authenticated.

                Does this make sense?

                Thanks.

                Pete

                Comment


                • #9
                  Pete,
                  We needed to write custom authentication module for our project and this is how I did it.
                  ---------------------------------------------------

                  Wrote a class that implements net.sf.acegisecurity.UserDetails interface. This class has custom (aka additional) fields that we need to keep track of.

                  Wrote a class that extends net.sf.acegisecurity.providers.dao.AbstractUserDet ailsAuthenticationProvider.

                  public class MyProvider extends AbstractUserDetailsAuthenticationProvider {

                  public UserDetails retrieveUser(String userName,
                  UsernamePasswordAuthenticationToken userNamePasswdAuthToken) throws AuthenticationException {

                  //get the username/password from params
                  //perform custom authentication that authenticates and also returns a role list (list of strings)
                  //if user is valid, Create UserDetails object and add role strings to GrantedAuthorities
                  //else throw BadCredentialsException

                  }

                  }

                  Used this class in acegi security config file as one of the providers used by authenticationManager bean.

                  ---------------------------------------------------

                  Hope this helps.

                  Regards
                  Mandar

                  Comment


                  • #10
                    Originally posted by PeteSlater
                    Hi,

                    When you mention Spring Controllers are you refering to Spring MVC Controller?
                    If so, we are not using that part of Spring.
                    We are simply using JSF as the presentation technology.

                    Ideally I would like to lock down the entire application leaving only a couple of pages available to the general public. These pages would be the ones needed as part of the authentication process. Everything else could then only be accessed once the user has been authenticated.

                    Does this make sense?

                    Thanks.

                    Pete

                    Yes, I was referring to Spring controllers, but that was only as a suggestion. You need some kind of login "wizard" which goes through the login steps and finally sets up the context, but how you implement it is pretty much up to you.

                    Comment

                    Working...
                    X