Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3
    • Fix Version/s: 1.3
    • Component/s: Server
    • Labels:
      None

      Description

      There should be the option of using container-based autnetication.

      Here are some ideas from an old post in the mailing list:

      Been thinking a lot about container based authentication - primarily,
      because of my interest in the CAS integration which is necessary for
      an OFBiz integration (search for OFBizCasAuthenticationHandler.java
      class for details)

      Here a few thoughts.

      in J2EE, the way to get the user is via the following code:

      java.security.Principal principal = request.getUserPrincipal();
      if(principal != null)

      { String username = principal.getName(); // usw. usf. }

      If we used the UserPwdAuthModule in UserAuth.scala as a basis, we
      could use the following code combined with the code above to get the
      user:

      user <- UserAuth.find(By(UserAuth.authKey, name),
      By(UserAuth.authType,
      moduleName)).flatMap(_.user.obj) or
      User.find(By(User.nickname, name))

      We could take use the S object in lift to get the request and then get
      the UserPrincipal. Probably with "S.request"

      The only I don't know is how to make this Container-based authmodule
      be the default that works without a UI that implicitly calls it.

      One idea is to remove the following lines from Boot.scala
      UserAuth.register(UserPwdAuthModule)
      UserAuth.register(OpenIDAuthModule)

      and replace them with
      UserAuth.register(ContaionerAuthModule)

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

      object ContainerAuthModule extends AuthModule {

      def moduleName: String = "upw"

      def performInit(): Unit = {
      LiftRules.dispatch.append {
      case Req("authentication" :: "login" :: Nil, _, PostRequest) =>
      val from = S.referer openOr "/"

      (for {
      java.security.Principal principal = S.Request.getUserPrincipal();
      if(principal != null)

      { String username = principal.getName(); user <- UserAuth.find(By(UserAuth.authKey, username), By(UserAuth.authType, moduleName)).flatMap(_.user.obj) or User.find(By(User.nickname, username)) userAuth <- UserAuth.find(By(UserAuth.user, username), By(UserAuth.authType, moduleName)) }
      1. cm_login.jsp
        0.7 kB
        Vladimir Ivanov
      2. ESMELdap_ads.properties
        0.8 kB
        Vladimir Ivanov
      3. jetty-login.properties
        0.0 kB
        Vladimir Ivanov
      4. pom.xml
        16 kB
        Vladimir Ivanov
      5. server_ads.xml
        7 kB
        Vladimir Ivanov
      6. server_plain.xml
        6 kB
        Vladimir Ivanov
      7. tomcat-users.xml
        2 kB
        Vladimir Ivanov
      8. web.xml
        2 kB
        Vladimir Ivanov

        Activity

        Hide
        Dick Hirsch added a comment -
        Show
        Dick Hirsch added a comment - Here are details how to do this: http://www.assembla.com/wiki/show/liftweb/How_to_use_Container_Managed_Security
        Hide
        Ethan Jewett added a comment -

        Moving to release 1.2 (tentative)

        Show
        Ethan Jewett added a comment - Moving to release 1.2 (tentative)
        Hide
        Vladimir Ivanov added a comment -

        It's possible to use BASIC(DIGEST) or FORM type of container-managed authentication. I have some questions:
        1. Is it ok if container-managed authentication will be associated with specific URL, for example 'cm/login'? It then will be specified in web.xml as a secured resource. When user is directed to this URL, container-managed authentication will first take place. After that, we will be able to get user credentials and store user information in session in a new AuthModule an according with example from Lift Wiki above.
        2. What user-related information should be stored in ESME database? Usually container-managed authentication retreives user data from some external source such an LDAP. I think it will also be possible to get role (group) information via Lift LDAP API when it will be available.

        Show
        Vladimir Ivanov added a comment - It's possible to use BASIC(DIGEST) or FORM type of container-managed authentication. I have some questions: 1. Is it ok if container-managed authentication will be associated with specific URL, for example 'cm/login'? It then will be specified in web.xml as a secured resource. When user is directed to this URL, container-managed authentication will first take place. After that, we will be able to get user credentials and store user information in session in a new AuthModule an according with example from Lift Wiki above. 2. What user-related information should be stored in ESME database? Usually container-managed authentication retreives user data from some external source such an LDAP. I think it will also be possible to get role (group) information via Lift LDAP API when it will be available.
        Hide
        Dick Hirsch added a comment -

        Regarding 1) This is fine to hook the container-based authentication to a particular URL. A first test could be to use MemoryRealm in Tomcat.

        Regarding 2) LDAP integration would be ideal to get roles and / or provide authentication. I looked at the LDAP support in Lift but it is tightly linked to the MegaProtoUser and I didn't know how to separate them.

        Show
        Dick Hirsch added a comment - Regarding 1) This is fine to hook the container-based authentication to a particular URL. A first test could be to use MemoryRealm in Tomcat. Regarding 2) LDAP integration would be ideal to get roles and / or provide authentication. I looked at the LDAP support in Lift but it is tightly linked to the MegaProtoUser and I didn't know how to separate them.
        Hide
        Vladimir Ivanov added a comment -

        I've implemented very simple variant of container-managed authentication using an example from Lift Wiki. When user access http://your_host_port_and_context/cm/login URL, it's redirected to login form (sorry, I've added primitive JSP containing only login/password fields) by container. After user fills and submits this form, credentials are checked by container and in case successful authentication and authorization it's possible to save user info to/retreive user info from DB in new AuthModule. Right now only username (nickname) is saved. Of course role list and additional user's attributes should be retreived from external source (LDAP).

        I used org.mortbay.jetty.security.HashUserRealm (it is configured in maven-jetty-plugin) which reads username/password/role mappings from plaintext file: jetty-login.properties, it should be placed into the root dir of server module. Primitive login/error JSP page cm_login.jsp should be placed into webapp dir. Other modified files are web.xml, Boot.scala and UserAuth.scala where module is registered and defined. I've attached all these files to current issue.

        It would be great if someone of our more experienced developers checks this auth module - it might have been implemented completly wrong.

        Show
        Vladimir Ivanov added a comment - I've implemented very simple variant of container-managed authentication using an example from Lift Wiki. When user access http://your_host_port_and_context/cm/login URL, it's redirected to login form (sorry, I've added primitive JSP containing only login/password fields) by container. After user fills and submits this form, credentials are checked by container and in case successful authentication and authorization it's possible to save user info to/retreive user info from DB in new AuthModule. Right now only username (nickname) is saved. Of course role list and additional user's attributes should be retreived from external source (LDAP). I used org.mortbay.jetty.security.HashUserRealm (it is configured in maven-jetty-plugin) which reads username/password/role mappings from plaintext file: jetty-login.properties, it should be placed into the root dir of server module. Primitive login/error JSP page cm_login.jsp should be placed into webapp dir. Other modified files are web.xml, Boot.scala and UserAuth.scala where module is registered and defined. I've attached all these files to current issue. It would be great if someone of our more experienced developers checks this auth module - it might have been implemented completly wrong.
        Hide
        Dick Hirsch added a comment -

        What things can we apply in a patch and what things would go into documentation.

        I assume that cm_log.jsp, web.xml, jetty-login.properties go into documentation

        Boot.scala + UserAuth.scala go into a patch

        Have you tried using Tomcat?

        Show
        Dick Hirsch added a comment - What things can we apply in a patch and what things would go into documentation. I assume that cm_log.jsp, web.xml, jetty-login.properties go into documentation Boot.scala + UserAuth.scala go into a patch Have you tried using Tomcat?
        Hide
        Vladimir Ivanov added a comment -

        It's OK from my point of view. One note: pom.xml and ESMEProject.scala should include servlet-api compile-time dependency.

        Haven't tried with Tomcat yet. Next thing I want to try - net.liftweb.ldap.LDAPVendor and whether it's possible to retreive groups/attributes with it.

        Show
        Vladimir Ivanov added a comment - It's OK from my point of view. One note: pom.xml and ESMEProject.scala should include servlet-api compile-time dependency. Haven't tried with Tomcat yet. Next thing I want to try - net.liftweb.ldap.LDAPVendor and whether it's possible to retreive groups/attributes with it.
        Hide
        Hudson added a comment -

        Integrated in ESME #546 (See https://hudson.apache.org/hudson/job/ESME/546/)
        Initial implementation for ESME-214: Add container-based authentication.

        Show
        Hudson added a comment - Integrated in ESME #546 (See https://hudson.apache.org/hudson/job/ESME/546/ ) Initial implementation for ESME-214 : Add container-based authentication.
        Hide
        Vladimir Ivanov added a comment -

        Tested on Tomcat 6 with user-password-role mapping in tomcat-users.xml file and MemoryRealm in server.xml config file. I've been able to successfully login, but user home page has been broken.

        Show
        Vladimir Ivanov added a comment - Tested on Tomcat 6 with user-password-role mapping in tomcat-users.xml file and MemoryRealm in server.xml config file. I've been able to successfully login, but user home page has been broken.
        Hide
        Vladimir Ivanov added a comment -

        I've modified new auth module, in case authentication performed by container via LDAP server, it's possible now to retreive additional user attributes from LDAP server (if ldap integration is enabled in ESMELdap.properties file, otherwise authentication performed by container via plain text (see jetty-login.properties and pom.xml for Jetty) or xml file (see server_plain.xml and tomcat-users.xml) ). I tested LDAP integration of ESME app (delpoyed on Tomcat 6) with both 389 Directory Server (Red Hat Directory Server) and MS Active Directory (I've included sample Tomcat's server.xml conf files for 389 and AD as well as sample ESMELdap.properties for both directory servers).

        You are welcome to review code and test it in your environment.

        Show
        Vladimir Ivanov added a comment - I've modified new auth module, in case authentication performed by container via LDAP server, it's possible now to retreive additional user attributes from LDAP server (if ldap integration is enabled in ESMELdap.properties file, otherwise authentication performed by container via plain text (see jetty-login.properties and pom.xml for Jetty) or xml file (see server_plain.xml and tomcat-users.xml) ). I tested LDAP integration of ESME app (delpoyed on Tomcat 6) with both 389 Directory Server (Red Hat Directory Server) and MS Active Directory (I've included sample Tomcat's server.xml conf files for 389 and AD as well as sample ESMELdap.properties for both directory servers). You are welcome to review code and test it in your environment.
        Hide
        Dick Hirsch added a comment -

        This would be cool if we could use the apache ldap....

        Show
        Dick Hirsch added a comment - This would be cool if we could use the apache ldap....
        Hide
        Vladimir Ivanov added a comment -

        If you wish, I can test it on Apache Directory Server as well.

        Show
        Vladimir Ivanov added a comment - If you wish, I can test it on Apache Directory Server as well.
        Hide
        Dick Hirsch added a comment -

        That would be cool > >you've got to start blogging about this stuff ;>

        Show
        Dick Hirsch added a comment - That would be cool > >you've got to start blogging about this stuff ; >
        Hide
        Ethan Jewett added a comment -

        How about setting up a separate Apache-only instance on our test VM?

        Show
        Ethan Jewett added a comment - How about setting up a separate Apache-only instance on our test VM?
        Hide
        Dick Hirsch added a comment -

        Good idea: ESME-Tomcat -Apache-Directory, etc

        Show
        Dick Hirsch added a comment - Good idea: ESME-Tomcat -Apache-Directory, etc
        Hide
        Vladimir Ivanov added a comment -

        I've deployed Apache Directory Server on local machine and tested it. Since server.xml and ESMELdap.properties files are essentially the same for all directory server, I've left my files only for ADS as an example. Hopefully, I'll write blog entry on this weekend.

        Show
        Vladimir Ivanov added a comment - I've deployed Apache Directory Server on local machine and tested it. Since server.xml and ESMELdap.properties files are essentially the same for all directory server, I've left my files only for ADS as an example. Hopefully, I'll write blog entry on this weekend.
        Hide
        Hudson added a comment -

        Integrated in ESME #551 (See https://hudson.apache.org/hudson/job/ESME/551/)
        ESME-214: set 'default' flag to false for container-managed authentication module. Renamed key in ldap property file.

        Show
        Hudson added a comment - Integrated in ESME #551 (See https://hudson.apache.org/hudson/job/ESME/551/ ) ESME-214 : set 'default' flag to false for container-managed authentication module. Renamed key in ldap property file.

          People

          • Assignee:
            Unassigned
            Reporter:
            Dick Hirsch
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development