1 Reply Latest reply on May 8, 2003 7:46 PM by Brian Stansberry

    writing a jboss independent LoginModule

    xinping Newbie

      In my custom login module, it implements javax.security.auth.spi.LoginModule and the customer principal implements java.security.Principal. After configuring in Boss, the login worked well. But request.getRemoteUser() or request.getPrincipal returned null?

      Do I have to implement the JBoss specific Principal and Login Module? (Our application has to be application server independent.)

      Thank you for any response.

      Lucy

        • 1. Re: writing a jboss independent LoginModule
          Brian Stansberry Newbie

          Yes, you definitely can write JBoss independent login modules, but they must bind certain objects to the Subject in a way that JBoss understands. Specifically,

          1) You must bind a java.security.acl.Group with a group name of "CallerPrincipal". This group must have a single Principal member, which will be the Principal returned by any calls to EjbContext.getCallerPrincipal().

          2) You must bind a java.security.acl.Group with the group name "Roles". Each member of this group must name a role for which the Subject has permissions.

          For more on this, see the Security chapter in the JBoss Admin book.

          If you follow this pattern, you do not have to import any JBoss classes into your module.

          To be even more platform-independent, you can use a stack of modules. For example, higher modules on the stack authenticate the user's credentials against your db, LDAP, whatever. They store role information and username to the shared state Map. Then you write a JBoss-specific module whose login() method only checks to be sure an earlier module successfully authenticated. The module's commit() method accesses the shared state Map and uses data it finds there to populate the Group objects in the way JBoss needs. If you deploy on another server, you don't have to include the JBoss specific module in the login-config.xml.

          Best,
          Brian