EJB3 Jacc Integration

[anil.saldhana]

Kabir writes:

First post:
Should ejb 3 be calling Policy.setPolicy()? The only place I
> can find this being called is in
> org,jboss.security.jacc.SecurityService.start() and stop().
>
> I don't know if this is of any help, but what seems to happen
> on startup is:
>
> 1) TomcatDeployer deploys the http invoker, and calls the
> JBossPolicyConfigurationFactory. It's call to
> Policy.getPolicy() returns a PolicyFile and so it calls
> DelegatingPolicy.getInstance() which creates a new DelegatingPolicy.
>
> 2) The JaccPolicyProvider mbean starts up and creates another
> DelegatingPolicy, which is set as the policy using
> Policy.setPolicy() when the SecurityService starts.
>
> Later, when deploying the jacc test the Policy.getPolicy()
> call returns a proxy for the policy created by the
> JaccPolicyProvider in 2). Since the proxy is not an instance
> of DelegatingPolicy, but wrapping the actual policy it calls
> DelegatingPolicy.getInstance(), this call does not create a
> new instance but returns the DelegatingPolicy set up by the
> TomcatDeployer in 1) to which permissions are added.
>
> The JaccAuthorizationInterceptor calls Policy.getPolicy() and
> uses the policy from 2) which has no permissions.

Second Post:
What is happening is the TomcatDeployer ends up in
DelegatingPolicy.setInstance(), which caches the policy in the singleton.

A DelegatingPolicy instance is created for the JaccPolicyProvidet service
via its constructor, a proxy to which is created by the JaccSecurityService
as the arg for Policy.setPolicy(). This DelegatingPolicy instance is not set
as the DelegatingPolicy singleton.

The EJB 3 installation ends up in JaccPolicyProviderFactory. The
Policy.getPolicyCall() returns the installed proxy to the DelegatingPolicy
installed by the JaccPolicyProvider service. This has the wrong type and so
we call DelegatingPolicy.getInstance() and get the one cached in
DelegatingPolicy.

One way to fix this would be to have an MBean wrapper for DelegatingPolicy
that gets hold of the underlying DelegatingPolicy via
DelegatingPolicy.getInstance().

The Portal project had a recent integration with Jacc. Currently the DelegatingPolicy is not externalized in Portal. It still uses the Singleton approach of obtaining the DelegatingPolicy.

An issue that I know of is:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=79431

[starksm64]

The jacc tests configs configure the DelegatingPolicy singleton via an xmbean service deployment:

<server>
 <mbean code="org.jboss.security.jacc.DelegatingPolicy"
 name="jboss.security:service=JaccPolicyProvider"
 xmbean-dd="">
 <xmbean>
 <attribute access="read-only" getMethod="getPolicyProxy">
 <description>The java.security.Policy implementation</description>
 <name>PolicyProxy</name>
 <type>java.security.Policy</type>
 </attribute>
 <attribute access="read-write" getMethod="getExternalPermissionTypes"
 setMethod="setExternalPermissionTypes">
 <description>The types of non-javax.security.jacc permissions that
 should be validated against this policy</description>
 <name>ExternalPermissionTypes</name>
 <type>[Ljava.lang.Class;</type>
 </attribute>
 <operation>
 <name>listContextPolicies</name>
 <return-type>java.lang.String</return-type>
 </operation>
 </xmbean>
 <!-- Not used, just here to test that custom permissions don't break the
 current behavior of javax.security.jacc.* permissions.
 -->
 <attribute name="ExternalPermissionTypes">org.jboss.security.srp.SRPPermission</attribute>
 </mbean>
 <mbean code="org.jboss.security.jacc.SecurityService"
 name="jboss.security:service=JaccSecurityService"
 xmbean-dd="">
 <xmbean>
 <descriptors>
 <injection id="MBeanServerType" setMethod="setMBeanServer" />
 <injection id="ObjectNameType" setMethod="setObjectName" />
 </descriptors>
 <attribute access="read-write" getMethod="getPolicyName" setMethod="setPolicyName">
 <description>The policy provider MBean name</description>
 <name>PolicyName</name>
 <type>javax.management.ObjectName</type>
 </attribute>
 <attribute access="read-write" getMethod="getPolicyAttributeName"
 setMethod="setPolicyAttributeName">
 <description>The Policy attribute name on the PolicyName MBean</description>
 <name>PolicyAttributeName</name>
 <type>java.lang.String</type>
 </attribute>
 <operation>
 <name>start</name>
 </operation>
 <operation>
 <name>stop</name>
 </operation>
 </xmbean>
 <attribute name="PolicyName">jboss.security:service=JaccPolicyProvider</attribute>
 <attribute name="PolicyAttributeName">PolicyProxy</attribute>
 </mbean>
</server>

In any configuration the DelegatingPolicy and java.security.Policy needs to be setup before any usage of the jacc apis. Something similar is needed in the ejb3/jacc configuration.

[starksm64]

The ejb3/build-test.xml/jacc-test target is just a variation of the all config:

 <target name="jacc-test" depends="init">
 <create-config baseconf="all" newconf="ejb3-jacc">
 <patternset>
 <include name="conf/**"/>
 <include name="deploy*/**"/>
 <include name="lib/**"/>
 </patternset>
 </create-config>
 <start-jboss conf="ejb3-jacc" host="${node0}"/>
 <wait-on-host/>
 <antcall target="test" inheritRefs="true">
 <param name="test" value="jacc"/>
 </antcall>
 <stop-jboss/>
 <wait-on-shutdown conf="ejb3-jacc"/>
 </target>

The all config does not configure jacc. The tomcat service does not have the jacc based realm configured, and there is no jacc-service.xml type of setup of the DelegatingPolicy/Policy. This should be leveraging the jacc config from the testsuite module. The following is an example from the testsuite:

 <target name="tests-jacc-security"
 description="Tests run against a jboss server with JACC configured">
 <!-- Create the ssl enabled tomcat config -->
 <create-config baseconf="default" newconf="jacc">
 <patternset>
 <include name="conf/**"/>
 <include name="deploy/hsqldb-ds.xml"/>
 <include name="deploy/jbossweb*.sar/**"/>
 <include name="deploy/jbossws.sar/**"/>
 <include name="deploy/jbossws14.sar/**"/>
 <include name="deploy/client-deployer-service.xml"/>
 <include name="deploy/ear-deployer.xml"/>
 <include name="deploy/ejb-deployer.xml"/>
 <include name="deploy/jmx-invoker-service.xml"/>
 <include name="deploy/jmx-console.war/**"/>
 <include name="deploy/jbossjca-service.xml"/>
 <include name="deploy/jboss-local-jdbc.rar"/>
 <include name="deploy/mail-service.xml"/>
 <include name="deploy/jms/**"/>
 <include name="deploy/jboss-aop.deployer/**"/>
 <include name="deploy/jboss-aop-jdk50.deployer/**"/>
 <include name="lib/**"/>
 </patternset>
 </create-config>
 <server:start name="jacc"/>

 <mkdir dir="${build.reports}"/>
 <mkdir dir="${build.testlog}"/>

 <property name="jbosstest.secure" value="true"/>
 <property name="java.security.auth.login.config"
 value="${build.resources}/security/auth.conf"/>
 <propertyset id="jacc-tests-props">
 <propertyref prefix="java.security.auth"/>
 </propertyset>

 <run-junit junit.patternset="jacc.includes"
 junit.configuration="JACC"
 junit.syspropertyset="jacc-tests-props" />

 <server:stop name="jacc"/>
 </target>

I need to see if the testsuite/src/resource/tests-configs can be reused from the ejb3 module.

[kabirkhan]

The ejb3 jacc test has a config under ejb3/src/resources/test-configs/ejb3-jacc which sets up the DelegatingPolicy and JaccSecurityService - it was lifted from the main testsuite. The problem was Tomcat was not set up to depend on the JaccSecurityService. This has been fixed