OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only

Re: XACML J2SE[TM] Platform Policy Profile

  • 1.  Re: XACML J2SE[TM] Platform Policy Profile

    Posted 04-21-2006 20:25
     MHonArc v2.5.0b2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    xacml message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


    Subject: Re: XACML J2SE[TM] Platform Policy Profile


    Hi Argyn,
    
    I did a quick prototype using Sun's XACML open source that took only a 
    few days.  This convinced me the proposal was feasible, but I did no 
    further work on it.  I can't release my prototype code, although clearly 
    it would take someone only a couple of days to reproduce what I did :-)
    
    There are things that need to be fixed in the proposal.  Here are my 
    "TBD" notes:
    1) Performance
          Cache results based on hashing Protection Domain and requested
          Permission
    2) Threading and recursion issues
          Some objects needed to evaluate a request have permissions of
          their own, so there can be multiple levels of call in play at
          once.
          There needs to be a context consisting of the current
          ProtectionDomain, requested Permission, and current parsed
          Action maintained for each thread.  Callbacks from the
          J2SEAttributeFinderModule to the value retrieval methods in
          XACMLPolicyProvider need to be able to return the values
          associated with the executing thread.
        o Experiment with a couple of approaches, test for efficiency
          Tools to use:
          * java.lang.Thread.currentThread() returns a reference to the
            currently executing Thread object.
          * Thread.setName(String) associates a name with the current
            thread, and Thread.getName() returns that value.
          Could create a random# name for each thread in implies(), set
            it there, and use it to hash into a context table.
          Could create separate instance of J2SEAttributeFinderModule
            for each invocation.  See above under "signed permissions"
    3) My mis-interpretation of how signed Permissions and signed Codesource
        works in Java.
        Actually need to access a keystore and compare the certificate
        there to the certificate associated with the class
        ProtectionDomain.  Currently just comparing name from
        certificate associated with class to name in policy, but class
        could be signed by a bogus certificate having that subject
        name.  Nothing else checks that certificates used to sign
        classes are trusted.
        o Would be efficient to verify certificates used to sign
          classes when the classes are loaded, but do not necessarily
          know where the keystore is at that point.
        o Probably will be efficient to cache signer subject
          names/aliases that have already been verified.
    
    Regards,
    Anne
    
    Argyn wrote On 04/21/06 15:56,:
    > Anne
    > 
    > some time ago i read your work here
    > http://research.sun.com/projects/xacml/J2SEPolicyProvider.html
    > 
    > did it go beyond a proposal? was there any kind of implementation planned?
    > 
    > thanks,
    > argyn
    > 
    > ---------------------------------------------------------------------
    > To unsubscribe from this mail list, you must leave the OASIS TC that
    > generates this mail.  You may a link to this group and all your TCs in OASIS
    > at:
    > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
    > 
    
    -- 
    Anne H. Anderson             Email: Anne.Anderson@Sun.COM
    Sun Microsystems Laboratories
    1 Network Drive,UBUR02-311     Tel: 781/442-0928
    Burlington, MA 01803-0902 USA  Fax: 781/442-1692
    


    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]