Re: XACML J2SE[TM] Platform Policy Profile

[Anne Anderson <Anne.Anderson@sun.com>]

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