4 Replies Latest reply on Jul 29, 2003 9:39 AM by sradford

    Jaas & Session Bean methods

    cenos

      Hi,

      I have a Stateless Session Bean that has 2 methods:
      -setX - (with roles Admin and Common)
      -deleteX - (with role Admin)

      That is, a user with Admin role can setX and deleteX, but with Common, it can only setX...

      The problem is that deleteX is inside setX... (if a variable is set, delete is performed - setX (boolean delete))

      When I call deleteX alone, with a user with Common role, the user is not authorized to delete.

      But when I call setX, that calls deleteX, the user with Common role is authorized and can delete...

      Both methods are with 'Required' transaction.

      Is there a way to the deleteX method inside setX be checked again by JaasSecurityManager?

        • 1. Re: Jaas & Session Bean methods
          jarikr

          Try out to call

          ctx.IsUserInRole( "Common" )

          in the setX method, with ctx being the session context of the bean. if it is true, you can throw a SecurityException.

          regards,
          Jari

          • 2. Re: Jaas & Session Bean methods
            cenos

            I have the roles already defined in ejb-jar.xml for each method. If I put the method sessioncontext.IsCallerInRole for deleteX, the previous role definition in ejb-jar is useless...

            Isn't there a way to call again JaasSecurityManager.doesUserHaveRole() in the beginning of each method of my session bean?

            and why isn't JaasSecurityManager authenticating the method (deleteX) inside another method (setX)?

            What is the 'trigger' to call JaasSecurityManager?

            • 3. Re: Jaas & Session Bean methods
              cenos

              Well, a workaround to this is to make an instance of the session bean inside of itself and use this to call the methods...

              • 4. Re: Jaas & Session Bean methods
                sradford

                Don't you need to go via an interface (local/remote) on the SessionBean to trigger the security manager. Just calling this.deleteX() won't allow the container to intercept the method call to do the security checking...