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

[zumrani <do-...@jb...>]

"sco...@jb..." wrote : 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.
  | 

I agree that we need to attach appropriate meaning to null ProtectionDomain(PD). I am not the expert on the subject, but it looks like that ProtectionDomain is part of legacy Policy API which is carried forward into JACC. Except Principal[], JACC does not care about other properties of PD. Moreover, from the application's point of view, if it is doing dynamic resources/permissions, it relies on the container to find the appropriate Subject/Identity of the user. From that perspective a null PD could mean that the container should get one for the application. Without container finding the identity, the application will be forced to create a dummy PD containing Principal[] from the PolicyContext. Though it is possible, but from the application's perspective it is cumbersome to do do. Hence I feel that if PD is null then the JACC layer should find the appropriate Identity/Subject.


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

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