2 Replies Latest reply on Jul 28, 2013 12:33 PM by atijms

    Why does JBoss bother with a security domain for local EJB beans?

    atijms

      JBoss (WildFly) has always made it an explicit requirement to activate security on an EJB bean via extra proprietary mechanisms.

       

      (in)famous is the  @org.jboss.ejb3.annotation.SecurityDomain annotation for JBoss AS 7. Starting from JBoss AS 7.2, there is a default domain (other), but all methods without any explicit security annotations are DenyAll by default. Since this is not what the Java EE spec demands (non-annotated methods, either at method level or class level are accessible by default), there is again JBoss specific configuration available to override this.

       

      The problem with all of this is that it makes things very hard for portable applications. If all Java EE implementations required this kind of configuration, we could easily be looking at some 12 orso vendor specific annotations on a bean and/or 12 proprietary deployment-descriptors. Then realize that proprietary configuration has a higher tendency to change between revisions of the same implementation, and the number can be even much higher than that

       

      https://docs.jboss.org/author/display/AS72/Securing+EJBs states the following:

       

      The Java EE spec doesn't mandate a specific way to configure security domain for a bean. It leaves it to the vendor implementations to allow such configurations, the way they wish.
      

       

      I don't fully understand why a local EJB bean, especially one that's packaged in a .war, even needs to know about a security domain. In a web application, authentication starts at the beginning of a request. In case of JBoss/WldFly the Valve SecurityContextAssociationValve then puts an authenticated identity (Subject) into a securityContext, where e.g. org.jboss.as.security.service.SimpleSecurityManager picks it up. This SimpleSecurityManager is what e.g. the EJBContext uses to verify security constraints.

       

      I can understand that remote EJB beans would have to know about a security domain, since like Servlets they are an entry point into the application, but why is this necessary for local EJB beans? What am I missing?

        • 1. Re: Why does JBoss bother with a security domain for local EJB beans?
          wdfink

          Did you say that you can't deploy the EJB's without any security annotation?

          If you did not add such annotation the local beans should be available by injection.

          • 2. Re: Why does JBoss bother with a security domain for local EJB beans?
            atijms

            Did you say that you can't deploy the EJB's without any security annotation?

            If you did not add such annotation the local beans should be available by injection.

             

            I don't think that is exactly what I meant. I don't have any operational problems.

             

            What I'm trying to understand is why the entire concept of an explicit "security domain" is needed in JBoss for local EJB beans. The EJB 3.1 spec mentions the general concept in 17.6.2, but it seems targetted at remote bean invocations. For local beans it seems to me that the EJB container can just use the (trusted) authenticated identity that was established prior to a call to a local EJB.

             

            In the current situation, JBoss requires a security domain to be set. This was relaxed a bit in AS 7.2, where the security domain is defaulted, but when it's defaulted so-called unchecked methods (methods with no explicit security constraints) are set to DenyAll. I think it's extremely rare that this is what users want, so in practice users still have to be bothered with this concept of specifying a security domain just for EJB beans.

             

            This makes the already much too complicated security setup of Java EE applications even more complicated and especially makes EJB (lite) beans a special case when packaged directly into a war. As said, seemingly there's no need for this extra complication at all, but maybe I'm overlooking something and there is indeed a reason that I completely missed.