3 Replies Latest reply on May 13, 2002 10:21 AM by jwkaltz

    User Registration and Security

    onthemark

      I have a J2EE application that requires the ability for users to register with the application when they visit the page, and this creates a new account for the user. This account can then be used in subsequent visits to the web page in order to authenticate the user. I know that J2EE does not currently support user registration for applications, as the security is primarily declarative, but I figure that somebody must have faced this problem before, and I am looking for a way to get around it.

      The application is trying to make use of a security wrapper around several entity beans such that when a call is made to access stored data, the wrapper will look at the current user, and determine which data they are permitted to view.

      The problem I am having is that the wrapper is currently unable to get the current user, unless the userid is passed throughout the application (ugh!!!).

      Is there any way to implement the user registration and have it use the J2EE security features so that I can access the caller principal through the EJBContext? Any help on this subject would be greatly appreciated because I have been stuck on this for a while...

        • 1. Re: User Registration and Security
          jwkaltz

          > The application is trying to make use of a security
          > wrapper around several entity beans such that when a
          > call is made to access stored data, the wrapper will
          > look at the current user, and determine which data
          > they are permitted to view.
          >
          > The problem I am having is that the wrapper is
          > currently unable to get the current user, unless the
          > userid is passed throughout the application
          > (ugh!!!).
          > (...)

          I'm not sure I understand what is bothering you in this approach. To me, it makes sense that when you add a wrapper
          you would have to pass the userid/password to it as parameters in a method of the wrapper (probably the constructor)
          Your servlet would read the userid (probably from the http session) and call your wrapper instead of calling the entity beans directly. Or you can define the wrapper class such that you would give it the userid only once (after login) and store a reference to it in the http session; after that it would be quite transparent to the users of that class.

          • 2. Re: User Registration and Security
            onthemark

            I understand what you are saying, and I currently do save a userid in the http session, however, the servlet does not talk directly to the entity beans (or wrapper for that matter). There is a group of session beans that handle requests from the servlet controller, and then call the wrapped entity beans. So now, it becomes much more messy to pass the userid around, which was what I mentioned in my first post. If there is an approach which would allow me to access the userid from the entity bean wrapper, without the session beans knowing, then that is what I would like to do.

            I believe that the getCallerPrincipal() method in the EJBContext interface would help me here, but I don't know how this gets set without using the J2EE security mechanisms.

            • 3. Re: User Registration and Security
              jwkaltz

              > I believe that the getCallerPrincipal() method in the
              > EJBContext interface would help me here, but I don't
              > know how this gets set without using the J2EE
              > security mechanisms.

              AFAIK the getCallerPrincipal() only works in your JBoss EJB if you specify the security stuff in your deployment.
              From the client's perspective, the userid gets bound to the JBoss invocation layer by using
              org.jboss.security.ClientLoginModule

              So I guess there is no easy way to implement what you want. Maybe writing your own SecurityInterceptor is the way to go, but I have no experience with that.