0 Replies Latest reply on Jun 19, 2004 1:28 PM by Oguz Ibram

    JAAS doAsPrivileged with a null AccessControlContext

    Oguz Ibram Newbie

      This is not a specific JBoss question.
      But JBoss is our app server.

      I make my JAAS-based authorisations being wrapped by an JBoss-EJB providing an EJB method


      with a null as AccessControlContext argument. This has the effect that
      for each new user access control an empty stack with ProtectionDomain[0] is constructed internally by JAAS.

      The wrapped exampleEJB.doAsPrivileged is invoked on the JSP side. Inside the PrivilegedExceptionAction I wanted to do invocation of the protected operation rather to call AccessController.checkPermission inside the action as is given as example everywhere.

      The access control should start on the server-side and inside the method
      that does realise any protected operation:

      class exampleEJB ... {

      doSomething {

      Does anyone know, if this is possible without getting code source access control problems?? Because when I have an action like exampleEJB.doSomething as argument to the doAsPrivileged, then the just
      "refreshed" accesscontrolcontext gets one method call onto the stack and the stack will look like this:

      Stack 1:

      When inside the action at the jsp side, I would have called directly the checkpermission, than I would have only one method on the stack:

      Stack 2:

      This class is in the system domain and so authorisation is really based exclusively onto the Subject's permissions.

      But I would rather have the permission checks on the server side inside the protected method. However, do I get some problems with the stack 1??? In which domain is the exampleEJB.doSomething-method?? In the domain where the JSP is stored that calls the EJB???

      I had a problem with JAAS on JBoss a few time ago. Thanks to a very good answer, I had found my way.

      I needed the JAAS-based authorisation in my project.

      1- JBossSX provides the J2EE declarative role-based access control

      2- EJB SecurityInterceptor were an alternative but are not an EJB 2.0 standard.

      I hope, JACC will help in future with this problem.