EJB3 security - Skip authorization for @PermiAll?

[jaikiran]

I was looking at a thread in the EJB3 forum which was talking about poor performance of a bean method invocation when the bean is marked with a @SecurityDomain, as compared to a similar bean without any @SecurityDomain. The bean is like this:

@Stateless
@Local(Ping.class)
@SecurityDomain(unauthenticatedPrincipal = "anonymous", value="other")
@PermitAll
@LocalBinding (jndiBinding=BeanWithSecurityDomain.JNDI_NAME)
public class BeanWithSecurityDomain implements Ping
{

   public static final String JNDI_NAME = "SecurityDomainBean";
   
   /**
    * @see org.jboss.ejb3.test.perf.Ping#ping()
    */
   public String ping()
   {
      return "pong1";
   }

}

Notice the use of @PermitAll. In the EJB3 security related interceptor org.jboss.ejb3.security.RoleBasedAuthorizationInterceptorv2 i notice that even if the class/method is marked for @PermitAll, the code leads to a authorization call:

 boolean isAuthorized = helper.authorize(ejbName, 
                             mi.getMethod(), 
                             sc.getUtil().getUserPrincipal(), 
                             iface, 
                             ejbCS, 
                             sc.getUtil().getSubject(), 
                             callerRunAs, 
                             contextID,
                             new SimpleRoleGroup(methodRoles));

The authorization call is expensive.

My understanding of @PermitAll was that we would skip this authorization altogether. Is there any reason why we have to authorize even when the bean is marked for @PermitAll?

[anil.saldhana]

That behaves as an "unchecked" operation. Now either we can centralize all security operations in the security layer (including the @PA check) or we can add code to the integration layer (here the ejb3 interceptor) to not invoke the security layer, for performance benefit.

For this particular case, it makes sense to do the latter.

[anil.saldhana]

Also I think I will have to eventually fix the security helper classes to take in method arguments that are small in number and not a mile long.

[dlofthouse]

Is this only the authorization this is looking to skip or the authentication as well?

[jaikiran]

[e-mail] wrote:

That behaves as an "unchecked" operation. Now either we can centralize all security operations in the security layer (including the @PA check) or we can add code to the integration layer (here the ejb3 interceptor) to not invoke the security layer, for performance benefit.

For this particular case, it makes sense to do the latter.

While discussing this with Carlo, he brought up an interesting point related to auditing - Does skipping this authorization from the integration points (like this EJB3 code) result in any side-effects to any security auditing that might be happening through the security APIs? If yes, then maybe centralizing this kind of optimization within the security layer would be a better option.

[jaikiran]

[e-mail] wrote:

Is this only the authorization this is looking to skip or the authentication as well?

This specific RoleBasedAuthorizationInterceptorv2 will just skip authorization. Authentication will (and rightly should) continue happening for a bean marked with @PermitAll.