-
1. Re: Why does JBoss bother with a security domain for local EJB beans?
wdfink Jul 28, 2013 12:09 PM (in response to 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.
-
2. Re: Why does JBoss bother with a security domain for local EJB beans?
atijms Jul 28, 2013 12:33 PM (in response to 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.
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.