1 Reply Latest reply on Sep 21, 2003 2:25 AM by jensr

    JAAS and non-container-managed authenticated web-apps.

    jensr

      We have a collection of web-apps that are not using
      container-managed authentication, but call EJBs
      that are security declared (method-permission).
      1) Some are using programmatic authentication
      2) Others are not using any external authentication
      because they are automatically invoked by external
      systems.

      After some frustrating trial-and-errors, we managed to
      get it going with one remaining problem.
      When the container calls ejbPassivate(), a stacktrace
      is thrown telling us that principal is null.
      Clearly, we done something wrong, but what?
      Any help would be highly appreciated.

      We are using JBoss 3.2.2RC3 on JDK 1.4.2

      --- login-config ---
      <application-policy name="foobar">

      <login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="required" >
      <module-option name="dsJndiName">java:/ds/foobar</module-option>
      <module-option name="principalsQuery">SELECT passWord FROM users WHERE userName = ?</module-option>
      <module-option name="rolesQuery">SELECT role, 'Roles' FROM roles WHERE userName = ?</module-option>
      </login-module>

      </application-policy>

      <application-policy name = "client-login">

      <login-module code = "org.jboss.security.ClientLoginModule" flag = "required">
      </login-module>

      </application-policy>

      --- END login-config ---

      The web-apps do not declare any JAAS realm in jboss-web.xml.

      But, the jboss.xml in the ejb-jar file declares
      <security-domain>java:/jaas/foobar</security-domain>

      All ejb interfaces used are local.

      Whenever, a session ejb needs to be created, in a web-app, the following statements are performed
      LoginContext auth = new LoginContext("client-login", new UsernamePasswordHandler(authName, authPwd));
      auth.login();
      Context jndi = new InitialContext();
      FoobarLocalHome h = (FoobarLocalHome)jndi.loopkup("ejb/FoobarLocalHome");
      FoobarLocal f = h.create(...);


        • 1. Re: JAAS and non-container-managed authenticated web-apps.
          jensr

          After some more investigation, I found the answer.
          It was wrong to use explicit authentication inside
          a non-authenticated webapp.

          The solution was instead to declare a run-as role in
          web.xml and unauthenticatedIdentity in login-config.

          To be more concrete.
          --- web.xml ---
          ...

          <servlet-name>Echo</servlet-name>
          <servlet-class>server.web.EchoServlet</servlet-class>
          <run-as>
          <role-name>foobar</role-name>
          </run-as>


          ...
          <security-role>
          <role-name>foobar</role-name>
          </security-role>
          --- END web.xml ---

          --- login-config.xml ---
          <application-policy name = "foobar">

          <login-module code = "org.jboss.security.auth.spi.UsersRolesLoginModule" flag = "required">
          <module-option name = "unauthenticatedIdentity">nobody</module-option>
          </login-module>

          </application-policy>
          --- END login-config.xml ---

          --- bean lookup ---
          private FoobarLocal getBean() {
          FoobarLocalHome h = (FoobarLocalHome) new InitialContext().lookup("ejb/FoobarLocalHome");
          return h.create(...);
          }
          --- END bean lookup ---


          However, there is one remaining problem.
          The web.xml declared run-as for a particular servlet.

          This implies that a JSP based webapp, needs to declare
          a servlet clause with a run-as, for every JSP page that
          a) creates
          and/or
          b) invokes
          a bean.

          It also complicates matter, a lot, for a struts based webapp.
          What I really want to do is simply declare run-as for the
          whole webapp.

          Any comments on this are highly appreciated.