[Jboss-dev-forums] [Design of Security on JBoss] - Re: Generalizing the JACC service

[<sco...@jb...>]

So the DelegatingPolicy used as part of the default jboss jacc provider has been extended to support a set of external permissions specified via the ExternalPermissionTypes:


  |    <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>
  | 

This is in the 4.0 codebase for 4.0.3 but won't be a documented feature until 4.0.4. Deployers can introduce custom permissions that associated security interceptors enforce and use the default jboss jacc provider in a somewhat pass-through manner.

A usecase where a null ProtectionDomain was passed to the jacc Policy came up and this is not handled gracefully today. The question is what meaning should be attached to a null ProtectionDomain. One suggestion was that the PolicyContext subject should be consulted. This I do not agree with. 

Another alternative would be some guest identity similar to the unauthenticatedIdentity notion supported by the login modules. Another is to simply fail, albeit more gracefully than an NPE, as identity is not the responsibility of the jacc provider.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3894504#3894504

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3894504