6 Replies Latest reply on Dec 15, 2001 4:25 PM by luke_t

    Principal does not propagate from servlet to EJB

    mhellkamp

      I have a web app running on JBoss-2.4.3_Tomcat-3.2.3 that has secured jsps and EJBs. I am successfully authenticating via form based authentication and it appears that the security manager is successfully checking roles to ensure that the user has access to the secured components. However, when I make a call to getCallerPrincipal() I am getting the "guest" principal rather than the one associated with the currently logged in user.

      I did notice that when doesUserHaveRole() is being called in JaasSecurityManager the Principal being passed in is null (although this parameter is ignored in the method).

      Any ideas on what I am doing wrong?

      Mark

        • 1. Re: Principal does not propagate from servlet to EJB

          What security domain have you set up for your application? Is sounds as if you are accidentally using the "simple" domain which provides the behaviour you describe. From auth.conf:

          simple {
          // Very simple login module:
          // any user name is accepted.
          // password should either coincide with user name or be null,
          // all users have role "guest",
          // users with non-null password also have role "user"
          org.jboss.security.auth.spi.SimpleServerLoginModule required;
          };

          • 2. Re: Principal does not propagate from servlet to EJB
            mhellkamp

            I'm using a custom login module in my own defined domain. The login module seems to be working fine. In fact, the same code works in Joss-2.4.4_Tomcat-3.2.4-beta (which has other problems that prevent me from using it) so I don't think that is the issue.

            • 3. Re: Principal does not propagate from servlet to EJB
              mhellkamp

              I did finally get this to work. The page I was accessing in my web app was not secured, so Tomcat was not passing the user data with the request. Is this a bug or a feature? Other app servers I have deployed this application on (Orion and Weblogic) do not do this, and I haven't found any reference to this behavior in the spec. Any insights would be appreciated.

              Mark

              • 4. Re: Principal does not propagate from servlet to EJB

                OK, so your custom login module has the unauthenticated identity set to "guest", is that what you were saying. Ignore my previoust post 'cos I was getting mixed up with roles and you were talking about principal names. When you said you were getting the "guest" principal I didn't realise you were using your own login module.

                So you're saying that when an already logged in user loads an unsecured page and which calls an EJB, then the principal associated with the call is wrongly reported as the "unauthenticatedIdentity" specified in auth.conf? If so then I would say this was probably a bug, though why would you want to provide unsecured web access to a secured EJB?

                Are you absolutely sure that the web request was made as part of a session in which the user was definitely logged in?

                • 5. Re: Principal does not propagate from servlet to EJB
                  mhellkamp

                  That is what was happening. In my application, the principal carries extra information that is needed to process requests in the EJB layer, so I need to know who is logged in during the session. On the other application servers I have deployed on, the principal is associated with all of the calls regardless of whether the EJB or JSP is secured.

                  • 6. Re: Principal does not propagate from servlet to EJB

                    This seems to make it even more sensible to secure the urls that allow you to access those EJBs - if you have to be logged in to use them then why expose those urls as unprotected?

                    In any case, I think the principal should always be set if someone has logged in. I don't know what the situation is in the latest releases.