[starksm64]

The problem is that two DelegatingPolicy instances are being created:
- one from the Ejb3PolicyConfigurationFactory
- one from the deployers/jacc-service.xml

On my box, its the Ejb3PolicyConfigurationFactory that runs first and sets the DelegatingPolicy.instance value. Its the deployers/jacc-service.xml instance that is installed as the java.security.Policy value, and the java.security.Policy how the EJBJACCPolicyModuleDelegate initiates security checks.

All jacc permission creation access the DelegatingPolicy via the PolicyConfigurationFactory, and this uses the DelegatingPolicy.instance, so context permissions uses one DelegatingPolicy, and the EJBJACCPolicyModuleDelegate uses another.

If I added a dependency to the ejb3.deployer/META-INF/ejb3-deployers-beans.xml Ejb3Deployer on the JaccPolicyProvider:

 <bean name="Ejb3Deployer" class="org.jboss.ejb3.deployers.Ejb3Deployer">
 <property name="type">ejb3x</property>
...
 <depends>jboss.security:service=JaccPolicyProvider</depends>
 </bean>

then the tests pass at a 90% rate on my box.

The Ejb3PolicyConfigurationFactory should be a property that is injected as its in general not sufficient to use the default logic of the javax.security.jacc.PolicyConfigurationFactory to create the DelegatingPolicy.

[anil.saldhana]

TBH, I was not aware of any JACC policy provider for EJB3 being installed as default. I do not support the default installation of any JACC policy providers in EJB3.

We really should be considering a policy provider (DelegatingPolicy) in one central location (such as the legacy conf/jboss-service.xml). By default, this can be commented out. Any independent installation of JACC policy is invitation to subtle issues like this.

What do you think, Scott?

[starksm64]

We need to convert the jacc services to beans so that the DelegatingPolicy.instance can be retrieved as the JaccPolicyProvider bean using a factory:

<deployment xmlns="urn:jboss:bean-deployer:2.0">
 <bean name="JaccPolicyProvider"
 class="org.jboss.security.jacc.DelegatingPolicy">
 <constructor factoryMethod="getInstance"
 factoryClass="org.jboss.security.jacc.DelegatingPolicy"/>
 </bean>

 <bean class="org.jboss.security.jacc.SecurityService"
 name="JaccSecurityService">
 <property name="mbeanServer"><inject bean="JMXKernel" property="mbeanServer"/></property>
 <property name="policy"><inject bean="JaccPolicyProvider" property="policy"/></property>
 </bean>
</deployment>

The SecurityService needs to be pojoized to support this.

[starksm64]

I added a policy property to the SecurityService so that the jacc-beans.xml just becomes:

<deployment xmlns="urn:jboss:bean-deployer:2.0">
 <bean name="JaccPolicyProvider"
 class="org.jboss.security.jacc.DelegatingPolicy">
 <constructor factoryMethod="getInstance"
 factoryClass="org.jboss.security.jacc.DelegatingPolicy"/>
 </bean>

 <bean class="org.jboss.security.jacc.SecurityService"
 name="JaccSecurityService">
 <property name="policy"><inject bean="JaccPolicyProvider" property="policyProxy"/></property>
 </bean>
</deployment>

with this the tests are passing without any dependency from the ejb3 deployer.

[starksm64]

I did a 2.0.2.beta1 release of jbosssx.jar and changed the jacc tests-config to use the jacc-beans.xml.

[anil.saldhana]

I will make the security-jboss-sx project mvn release plugin ready so that we can avoid all the steps you had to do, Scott.

Since the security deployer needs changes based on the new metadata, I can take a look at the ejb3 jacc layer (and its policy installation).

We in fact need to have one JACC policy installation in the AS. If ejb2,web,ejb3,portal etc start installing their policy installation, it will mean more pain.