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.
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
One way to fix this would be to have an MBean wrapper for DelegatingPolicy
that gets hold of the underlying DelegatingPolicy via
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: