6 Replies Latest reply on Mar 21, 2004 6:16 PM by ahardy66

    custom login module using AbstractServerLoginModule

    ahardy66

      I wrote a custom login module extending the AbstractServerLoginModule. I have successfully set it up so that it is being called when I try to access a protected page on my website, and it looks up the user and roles via a local-tx-datasource.

      I can see from the logging output that it initializes correctly and access the DB to get the data and check the password. However it rejects every login attempt.

      I have overridden AbstractServerLoginModule's login, initialize, and abort. I can see JBoss calls my subclass's getIdentity and getRoleSets(). I have a hunch that it might be a problem in commit() but I can't tell.

      Also, in my login() method I set the superclass's loginOk to true.

      I can't locate the problem.

      I am unable to turn on the logging trace in AbstractServerLoginModule either, so it's difficult to see what's going on. Surely

       <category name="org.jboss.security.auth">
       <priority value="TRACE" />
       </category>

      will do it? I tried the full class name too.

      I have my own custom module-options declared in login-config.xml - but AbstractServerLoginModule doesn't need any, is that right?

      For reasons unknown, the login fails, despite my login() method returning true. Any advice greatly appreciated.

      Adam


        • 1. Re: custom login module using AbstractServerLoginModule
          ahardy66

          I'm just wondering whether my problem could be down to the Principal class that I'm using.

          I subclassed it to provide my own functionality on top of Principal. Could jbosssx be objecting to it?

          • 2. Re: custom login module using AbstractServerLoginModule
            starksm64

            The AbstractServerLoginModule.loginOk field must be set to true in order for commit to do anything as documented in the javadoc. The setting of the TRACE level is incorrect, use:

            <category name="org.jboss.security.auth">
             <priority value="TRACE" class="org.jboss.logging.XLevel"/>
             </category>
            


            • 3. Re: custom login module using AbstractServerLoginModule
              ahardy66

              I'm with you so far. I have logging on trace and I can see it all happening, and it succeeded, stone the crows.

              BUT then having surmounted that hurdle, it fell at the next one. Tomcat threw a 403 access denied error on the protected pages.

              So, the roles must be up the creek. I was using AbstractServerLoginModule.createGroup() to create my 'Roles' group, which puts a nestableGroup in the Subject, and tomcat can't handle it.

              That is actually recommended by the javadoc for createGroup(), that I should use the method.

              But I abandoned it and created a SimpleGroup instead - safely or not, I'm not sure. No doubt when I come to secure the EJB layer, it may come back to haunt me. Am I OK or am I still doing it wrong?

              • 4. Re: custom login module using AbstractServerLoginModule
                ahardy66

                Here's the code in my subclass:

                 /**
                 * This is required by the parent class. It puts the gargantus role
                 * objects which we fetched during login() into a group
                 * for the parent class to commit.
                 * @return group array containing the Roles group
                 */
                 protected Group[] getRoleSets() throws LoginException
                 {
                 log.trace("getRoleSets() returning " + this.roles.toString());
                
                 Group groups[] = new Group[1];
                 Set principals = super.subject.getPrincipals();
                
                 //next line creates NestedGroup - tomcat doesn't see it
                 //groups[0] = super.createGroup("Roles", principals);
                
                 //next 2 lines instead of JBoss superclass:
                 groups[0] = new SimpleGroup("Roles");
                 principals.add(groups[0]);
                
                 for (int x = 0; x < roles.size(); x++)
                 {
                 GargantusRole role = (GargantusRole) this.roles.get(x);
                 groups[0].addMember(new NestablePrincipal(role.getName()));
                 }
                 log.trace("adding our roles to subject");
                
                 return groups;
                 }
                
                


                I get the following trace from the security manager afterwards that confirms this: (when using super.createGroup(), the roles trace shows no roles)

                TRACE [org.jboss.security.plugins.JaasSecurityManager.GargantusRealm] updateCache, subject=Subject:
                 Principal: GargantusUser: adam
                 Principal: Roles(members:user,admin,manager)
                


                • 5. Re: custom login module using AbstractServerLoginModule
                  ahardy66

                  It seems to work the way I have programmed it, which violates what the javadoc in the AbstractServerLoginModule class tells me to do.

                  Is the AbstractServerLoginModule wrong when it nests the Roles group within another nestable group?

                  I doesn't show up correctly in the logging - the log statement above is my implementation's output. When I don't override AbstractServerLoginModule's default roles method, then the logging shows no roles added.

                  There must be something wrong with it or my implementation. I don't see this as acceptable.

                  Adam

                  • 6. Re: custom login module using AbstractServerLoginModule
                    ahardy66

                    Basically I am trying to establish whether this is a bug in the class, a deficiency in the documentation, or a bug in my code.


                    To summarise:

                    AbstractServerLoginModule.createGroup() creates Roles that tomcat cannot handle, leading to no roles being loaded for the user.