6 Replies Latest reply on Jul 29, 2002 12:07 PM by okellya

    org.jboss.security.auth.spi.IdentityLoginModule

    boris2

      I'm working with JBoss 2.4.4 and trying to use this LoginModule implementation in the auth.conf as a way to mark certain beans with a role. In my configuration file, I have an entry like this:

      restricted-bean {
      org.jboss.security.auth.spi.IdentityLoginModule required principal=restricted-bean roles=RESTRICTED;
      };

      Then I deploy a bunch of stateless session beans, each of which is configured to run-as RESTRICTED. I've included a jboss.xml file into each ear that declares a java:/jaas/restricted-bean security-domain, and followed all the instructions (I think). For now, the respective ejb-jar.xmls give the RESTRICTED role permission to invoke all methods (*) on each session bean. The beans deploy just fine, and invoke fine too.

      Except when one of these beans invokes another, I get the following situation: when the invoked bean uses its EJBContext instance to check caller properties, getCallerPrincipal() returns "restricted-bean" as it should, but isCallerInRole( "RESTRICTED" ) returns false.

      I've looked into the source code for org.jboss.security.auth.spi.IdentityLoginModule and I don't see any reason why the role doesn't get registered. Is there some problem with the way this login module handles its "roles" option? Are those roles not the same thing as checked by isCallerInRole()? Is there some sort of a catch that I should be aware of? Am I just completely missing the point?

      Thanks in advance for any ideas.
      -Boris

        • 1. Re: org.jboss.security.auth.spi.IdentityLoginModule
          annegret

          You must specify a security-role-ref in ejb-jar.xml for all roles used in isCallerInRole()


          <ejb-name>MySessionSB</ejb-name>
          xxx.MySessionSBHome
          xxx.MySessionSB
          <ejb-class>xxx.MySessionSBBean</ejb-class>
          <session-type>Stateful</session-type>
          <transaction-type>Container</transaction-type>
          <security-identity>
          <run-as>
          <role-name>RESTRICTED</role-name>
          </run-as>
          </security-identity>
          <security-role-ref>
          <role-name>RESTRICTED</role-name>
          <role-link>RESTRICTED</role-link>
          </security-role-ref>


          Annegret

          • 2. Re: org.jboss.security.auth.spi.IdentityLoginModule
            rlentell

            Boris,

            I am seeing a similar thing with 2.4.3. I am using a custom LoginModule to set the roles. Everything executes properly, but isCallerInRole returns false.

            However, if I use the code in this thread to check the Roles it returns with the proper Roles set.

            http://main.jboss.org/thread.jsp?forum=49&thread=2953

            I am not sure where the difference lies.

            Ryan

            • 3. Re: org.jboss.security.auth.spi.IdentityLoginModule
              boris2

              Thanks for your ideas, guys.

              I am properly referencing the role in the EJB descriptor, and the very same EJB descriptor works as expected under Weblogic.

              Ryan, I checked out your suggestion, but it still doesn't seem to quite work right. It does work (under 2.4.4) when the role is assigned to the actual bean that is trying to access it (through the bound Subject, as per the code you referenced). But, what I'm interested in is checking the roles of the caller (which is what I thought isCallerInRole is supposed to be for.) However, even when a caller bean has the role (as verified from within that bean through the hack you referenced), the invoked bean does not see that role in its runtime bound Subject (and I don't think it should, either.)

              I've spent some time looking through the 2.4.4's JaasSecurityManager code, and I'm now convinced that the misbehavior is not a "feature" of JBoss but indeed a bug having to do both with broken LoginModule handling and with dysfunctional caller tracking. Amazingly enough, caller identity is tracked properly when it comes to method permissions so that a caller bean cannot invoke methods on a target bean without having the appropriate role. I haven't looked at the 3.0 code in CVS (frankly, I don't have any more time), but hopefully the JBoss developers will correct the problem in the future.

              A "workaround" that'll have to suffice for me is a System property to flag JBoss environment, and depending on whether the property is set either proceeding with role-specific code (on well-behaved app servers) or assuming defaults (on JBoss) -- which isn't too unsafe since at least the JBoss method permissions can filter out unauthorized callers.

              • 4. Re: org.jboss.security.auth.spi.IdentityLoginModule
                boris2

                Uhm, I just realized the first "paragraph" above addressed to Ryan doesn't make much sense without further clarification... The invoking bean has the RESTRICTED role, while the bean being invoked is configured with </use-caller-identity> in its run-as segment. The invoked bean does not see the caller identity. If I do not set up a security domain for the invoked bean in the jboss.xml, its EJBContext throws an exception complaining there's no security context when I try to invoke isCallerInRole() (even though it's supposed to use caller identity.) If I do set up a security domain, getCallerPrincipal() returns the principal assigned to the bean through its LoginModule, instead of the principal of the caller that it's supposed to return!

                • 5. Re: org.jboss.security.auth.spi.IdentityLoginModule
                  okellya


                  I'm experiencing similar difficulties. It appears
                  to me that I'm setting everything correctly and yet only
                  the JBoss specific subject code works. IsCallerInRole
                  always returns false. Is this a known bug? If so are there
                  any workarounds?

                  thanks,

                  Alan

                  • 6. Re: org.jboss.security.auth.spi.IdentityLoginModule
                    okellya

                    I failed to mention in my previous post that the version
                    of JBoss I'm using is 2.4.6.