1 2 3 Previous Next 30 Replies Latest reply: Dec 5, 2006 2:37 PM by Anil Saldhana Go to original post RSS
  • 15. Re: Generalizing the JACC service
    Scott Stark Master

    The ProtectionDomain is not a legacy api. It just happens that today the CodeSource is not used by the current JAAC policy implementation. It certainly will be usable in the future, and this is the way most people configure their java2 security policies.

    "zumrani" wrote:

    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.


    Its wrong to consider that the application is being forced to determine the caller identity. JACC is an authorization contract, not authentication. If you are not leveraging the current caller information established by the container, you are replacing this and as such, assuming the role of determining the authenticated identity. The only question here is whether there should be an application pluggable policy for mapping an unauthenticated caller to a particular PD. The JAAS login modules already have a notion of unauthenticatedIdentity, and if a secured resource is hit, this identity will be established.

    You really need to describe exactly what the context of the null identity is as it seems to me that you are wanting a caller identity even in the context of accessing an unsecured resource. This is an ambiguous part of the servlet security contract and tomcat does not call out to its Realm to trigger any identity authentication for such a resource.


  • 16. Re: Generalizing the JACC service
    Woodler Expert

    despite the danger of beating a dead horse, what is the difference between what the current code does, and the proposal of providing a fallback inside the policy?
    Right now JaccAuthorizationRealm.establishSubjectContext() does exactly what this argument is about. It first checks the PolicyContext for an available Subject, and only if that is not there, it falls back to try and make sense out of the provided principal (which comes from the HttpServletRequest.getCallerPrincipal())

    So why not have the Policy first check the ProtectionDomain, and if none is provided, fall back to the PolicyContext and get the Subject from there, rather then throwing a SecurityException if no PD is provided. I don't see where this would introduce any more or less authorization related functionality then what the current JACC code does already.... I have to admit that I'm not an expert in this field, but I don't understand your argumentation. Feel free to ignore me if this is starting to be a silly argument, but I just don't get it so far. After all this is not critical, we can go either way in the implementation, this is only for my ego. I'd like to understand it ;)

    The other argument that I wanted to raise is that of custom user code that would like to use this security feature. What if a Servlet or a Portlet wants to create new permission classes and do security checks against the policy with them? Wouldn't it be better to provide a simplified API that takes care of the principal/subject determination rather then forcing that client code to get the subject from the PolicyContext (which as I understand it, would require the custom code to be configured in the J2SE policy file to be allowed to access the subject via the PolicyContext....)

  • 17. Re: Generalizing the JACC service
    Scott Stark Master

    Something has to set the caller identity. Any fallback has to rely on some component establishing the caller identity. The PolicyContext is not magically populated by nothing out of the ether surrounding the jboss server. Its populated by the authentication interceptors in the web and ejb containers. The simplified api is a dicussion for the authentication service (http://www.jboss.com/index.html?module=bb&op=viewtopic&t=67191).

    Once simple change could be an extension to the PolicyContext is a ProtectionDomain handler.

  • 18. Re: Generalizing the JACC service
    Woodler Expert

    I'm using this technique in the portal, and everything works as expected. Everything but one thing: the configured permission class is not added to the external permission types. So when I place the following mbean into the jboss-service.xml :

     <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 to validate 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>
     <attribute name="ExternalPermissionTypes">org.jboss.portal.core.security.jacc.PortalObjectPermission</attribute>
     </mbean>
    


    and in code I do :
     Policy policy = Policy.getPolicy();
     if (policy instanceof DelegatingPolicy){
    
     DelegatingPolicy delegatingPolicy = (DelegatingPolicy)policy;
     Class[] types = delegatingPolicy.getExternalPermissionTypes();
    


    then types.length is always 0

    I can work around it by testing for this condition and setting the permission class 'by hand', but that introduces code dependency to 4.0.3

    My question is: is there something I'm doing wrong, or is the external permission types injection not working here?



  • 19. Re: Generalizing the JACC service
    Scott Stark Master

    How is this being installed as the java.security.Policy? Just creating a DelegatingPolicy via an xmbean does not do this.

  • 20. Re: Generalizing the JACC service
    Woodler Expert

    in the same jboss-service.xml I also have :

     <mbean
     code="org.jboss.security.jacc.SecurityService"
     name="jboss.security:service=JACCSecurityService"
     xmbean-dd="">
     <xmbean>
     <description>The JACC security Policy service</description>
     <operation>
     <description>The start lifecycle operation</description>
     <name>start</name>
     </operation>
     <operation>
     <description>The stop lifecycle operation</description>
     <name>stop</name>
     </operation>
     </xmbean>
     </mbean>
    


    before the

     <mbean
     code="org.jboss.security.jacc.DelegatingPolicy"
     ......
    




  • 21. Re: Generalizing the JACC service
    Scott Stark Master

    You are missing the PolicyName setting which allows the SecurityService to install a preconfigured instance:

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


    Without this a new DelegatingPolicy instance is created that has no external permissions. The SecurityService installs the PolicyAttributeName attribute value as java.security.Policy, and this is not an instanceof DelegatingPolicy. The permissions would need to be obtained from the jmx ExternalPermissionTypes attribute, not by casting the Policy.


  • 22. Re: Generalizing the JACC service
    Woodler Expert

    and just when you think it's all working ....

    I followed your advice , and everything seemed to work. Now I started to work on redeployment issues and discovered that things derail on re deployment. I investigated a bit more and here is what I found:

    1) if the mbean descriptor entries are in the jboss?service.xml in the
    portal sar, everything works as expected: there is one DelegatingPolicy
    instance that was created by the DelegatinPolicy mbean entry, and it is
    available to all the right places. Policy.getPolicy() returns it, and
    the PolicyConfigurationFactory uses it as well

    the issue here is that when I redeploy the sar , the mbean entry for
    the Delegating policy creates a new instance, and now the
    Policy.getPolicy() returns the new instance, and the
    PolicyConfigurationFactory still has the old instance, hence the
    Policy.implies() fails since it checks against the wrong
    DelegatingPolicy instance

    2) if I take the mbean descriptor entries out of the sar into a
    separate file that I place into the deploy folder (I tried
    security?service.xml and jboss?service.xml) then the security service's
    start() method gets called much later then in 1), or at least appears to be, and as a result the AbstractWebDeployer kicks in before the DelegatingPolicy mbean , and has already a DelegatingPolicy installed by the time the DelegatingPolicy mbean gets a chance (this instance of the DelegatingPolicy doesn't know of the external permissions since it was not created via the DelegatingPolicy mbean entry, but rather via the
    JBossPolicyConfigurationFactory's constructor). As a result of that, the
    Policy.implies() check fails since the policy doesn't consider the
    PortalObjectPermission as a jaccPermission and hence delegates to the
    J2SE Policy to do the check.

    here are the mbean entries:

     <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 to validate 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>
     <attribute name="ExternalPermissionTypes">org.jboss.portal.core.security.jacc.PortalObjectPermission</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>
    



  • 23. Re: Generalizing the JACC service
    Woodler Expert

    and one more thing that I noticed:

    the constructor of the JBossPolicyConfigurationFactory does the following check:

     Policy p = Policy.getPolicy();
     if( (p instanceof DelegatingPolicy) == false )
     {
     // Assume that the installed policy delegates to the DelegatingPolicy
     p = DelegatingPolicy.getInstance();
     }
     policy = (DelegatingPolicy) p;
    


    If the installed Policy is infact an instance of the DelegatingPolicy, then what gets returned from the Policy.getPolicy() is never a DelegatingPolicy instance, but rather a DelegatingPolicy$PolicyProxy


  • 24. Re: Generalizing the JACC service
    Scott Stark Master

     

    "mholzner" wrote:
    and just when you think it's all working ....

    Since the jacc service is a vm global notion, it should not be bundled in the portal sar. If there are startup issues when seperating the jacc service, you need to introduce the required depends statements on the dependee services such as the tomcat sar.


  • 25. Re: Generalizing the JACC service
    Scott Stark Master

     

    "mholzner" wrote:

    ...
    If the installed Policy is infact an instance of the DelegatingPolicy, then what gets returned from the Policy.getPolicy() is never a DelegatingPolicy instance, but rather a DelegatingPolicy$PolicyProxy


    This still should not be causing duplicate creation of the DelegatingPolicy since the DelegatingPolicy.getInstance() is a singleton factory method. The only way a duplicate should result is if there is an improper duplicate deployment of the jbosssx.jar into a scoped deployment. I'll look at what a redeployment of the jacc service does.

  • 26. Re: Generalizing the JACC service
    Anil Saldhana Master

    Had a cursory look at the Sun's open source xacml implementation over the weekend. They have a very liberal license.

    Plus the concept of PolicyFinderModule(s) that can locate policy files matches closely with our current pattern of LoginModule(s)/ServerAuthModule(s) used in the Security Layer. This default XACML implementation can be extended to provide a stackable JBoss policy modules in for Authorization.

    http://cvs.sourceforge.net/viewcvs.py/sunxacml/sunxacml/com/sun/xacml/finder/PolicyFinderModule.java?rev=1.4&view=markup

    http://sunxacml.sourceforge.net/config.html

    With the new Authorization Service that has Authorization Managers decoupled from the Authentication Managers (unlike the legacy JaasSecurityManagers), we can have very interesting Authorization infrastructure setup, that is independent and pluggable.

  • 27. Re: Generalizing the JACC service
    Anil Saldhana Master

    Scott, currently the PolicyConfiguration.linkConfiguration is not complete because it fails to link the internal ContextPolicy. (It is not implemented)

    Here is a basic implementation that I did in the portal jacc layer (forked jacc layer).

    ContextPolicy.java
    
    void linkConfiguration(ContextPolicy link)
     throws PolicyContextException
     {
     Enumeration en = this.excludedPermissions.elements();
     while(en != null && en.hasMoreElements())
     link.excludedPermissions.add((Permission)en.nextElement());
    
     en = this.uncheckedPermissions.elements();
     while(en != null && en.hasMoreElements())
     link.uncheckedPermissions.add((Permission)en.nextElement());
     if(!rolePermissions.isEmpty())
     link.rolePermissions.putAll(rolePermissions);
     }
    


    Basically the perms and roles from the parent get added into the child. The logic can be changed to just use the linked ContextPolicy to make the decisions (as this copying of perms/roles is not ideal)

    This worked for my usecase.

  • 28. Re: Generalizing the JACC service
    Dan Lee Newbie

    Is there any plan to implement doAs for JAAS in the near future?

  • 29. Re: Generalizing the JACC service
    Scott Stark Master

    Start a new thread for describing that you mean as doAs. The Subject.doAs mechanism is purely a function of the java2 security model at the base level.