3 Replies Latest reply on Sep 16, 2012 4:55 PM by rodakr

    JBoss AS 7.1.1.Final custom login module for remoting and custom principal

    sraue

      For remoting we have made a custom login module which extends org.jboss.security.auth.spi.AbstractServerLoginModule.

      The overwritten method getIdenttity() returns a custom principal - ApplicationPrincipal.

      We can access the principal inside our ejbs via

       

      @Resource

      public SessionContext sessionContext;

       

      ....

      Principal principal = sessionContext.getCallerPrincipal();

       

      ....

       

      but we get a ClassCastException when we try to cast the returned Principal into ApplicationPrincipal.

      On the other hand principal.getClass().getName() returns the expected class name.

       

      The problem is that our login module is deployed as a jboss module (<jboss-home>/modules) - inside a jar which also

      contains ApplicationPrincipal. The ear containing our ejb.jar which contains our ejbs also contains a copy of ApplicationPrincipal.

      The problem is that our custom login module and the ApplicationPrincipal are loaded by one class loader and our

      ejbs and the ApplicationPrincipal copy are loaded by another class loader. The ApplicationPrincipal from the login module which we get

      by calling sessionContext.getCallerPrincipal() in the ejb is no ApplicationPrincipal known by the ejbs.

       

      What can we do to solve this problem?

       

      I have tried to put the custom login module code into our ear and adjusted the "module" attribute value of <login-module>

      in our standalone.xml to deployment.<app-name>.ear.<ejb-jar-name>.jar but it did not work. Exception on the remote client was:

       

      javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed

       

      As a separate module and the respective <login-module> configuration in standalone.xml the authentication works fine with our login module

      - we only have the described ClassCastException problem.

        • 1. Re: JBoss AS 7.1.1.Final custom login module for remoting and custom principal
          jingjingjiang1986

          I encouter a problem like this, sessionContext.getCallerPrincipal() always returns a SimplePrincipal instance, and its name is "anonymous", I expected that it would return a customed principal which implements the interface Principal.

           

          At client side, I implement a LoginModule, in the method commit(), add a my own customed principal, then call the remote EJB.

          • 2. Re: JBoss AS 7.1.1.Final custom login module for remoting and custom principal
            rick-rainer.ludwig

            I have exactly the same issue with JBoss 7.1.1. For the ClassCastException itself, I do not have a solution, but I have a workaround which works until I have a clean and staight solution.

             

            When retrieving the principal via

             

            @Resource

            public SessionContext sessionContext;

            ...

            Principal principal = sessionContext.getCallerPrincipal();

             

            I check the name of the instantiated class via

             

            principal.getClass().getName(). equals(MyExpectedPrincipalClass.class.getName())

             

            to assure the correct implementation and to avoid later exceptions. Then I work with reflection to access fields and method via getMethod() and getField(). It works fine, but it is quite ugly. Does anyone have a better idea?

            • 3. Re: JBoss AS 7.1.1.Final custom login module for remoting and custom principal
              rodakr

              Solution for me was, login modul is deployed as jboss modul. No packages from my login module are included in any deployments!.

              my login modul is defined in standalone.xml as global, so any class loaders can find it.

              I still had to add my login modul as dependency to some othe jboss provided modules...  you see while testing which modul get problems, so you add your login modul to this modul as dependecy...