Hi David,

On 8/10/07, David Jencks <david_jencks@yahoo.com> wrote:

SNIP ...

> We can easily accommodate both this simplified use of permissions
> while
> allowing for the more complex cases where the implies() method is more
> involved by extending the policyPermission objectClass.  As you may
> already
> know we can create objectClass subtypes.  I'm thinking we can create a
> javaPermission subtype which inherits from policyPermission which
> contains
> the fully qualified class name of the permission implementation
> along with
> parameters used to initialize it.  This can be used with the implies
> () method
> of the permission to reach access control decisions.

This looks a lot like what I did in my branch:

#
------------------------------------------------------------------------
-----
# Java permission support
#
------------------------------------------------------------------------
-----

attributetype ( 1.3.6.1.4.1.18060.0.4.6.2.208
         NAME 'permJavaClass'
         DESC 'the java class for a permission'
         EQUALITY caseExactMatch
         SUBSTR caseExactSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.18060.0.4.6.2.209
         NAME 'permJavaName'
         DESC 'the name of a java permission'
         EQUALITY caseExactMatch
         SUBSTR caseExactSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

attributetype ( 1.3.6.1.4.1.18060.0.4.6.2.210
         NAME 'permJavaActions'
         DESC 'the actions of a java permission'
         EQUALITY caseExactMatch
         SUBSTR caseExactSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

objectclass ( 1.3.6.1.4.1.18060.0.4.6.3.205 NAME 'javaPermission'
     SUP top
     AUXILIARY
     MUST ( permJavaClass $ permJavaName )
     MAY ( permJavaActions )
     )

but I don't think I understand the "subtype" idea.  

Yeah I think you missed it here.  Basically your javaPermission class would
extend the policyPermission objectClass using the SUP property above and
hence would not need to have permJavaName like so:

objectclass ( 1.3.6.1.4.1.18060.0.4.6.3.205 NAME 'javaPermission'
     SUP policyPermission
     AUXILIARY
     MUST ( permJavaClass )
     MAY ( permJavaActions )
     )


What would I do
to make this a subtype of policyPermission? 

Answer is above.

 What is the advantage of
making this a subtype of  policyPermission rather than an independent
objectclass?

This would allow the system to treat all permissions the same when a non-java
client is pulling policy information.  Depending on the permission implementation
this may result in correct or incorrect evaluation by a non-java client which may
just ignore this information.  However nothing would break because schema wise
it would still be a policy permission and handled accordingly instead of requiring
special handling code in non-Java clients.

Java clients may then recognize special JSE based permissions and handle them
accordingly in addition to handling simple policy permissions in the guardian API.

The divide we're dealing with here comes from the fact that we have two kinds of
permissions which can be considered by Java clients:

   1). Simple binary permissions whose evaluation is based on their existing or not existing
        to authorize access
   2). JSE permissions which require implies() evaluation to authorize access

Some applications will never need JSE permissions and would most likely prefer this
simpler model.  However in your case with the JACC implementation we need to factor
in the J2E permission's implies() method to evaluate authorization decisions.

Many will choose the simpler route especially if the same policy information needs to
be accessed through different languages since the implies() method cannot be evaluated
by non-Java clients.

HTH,
Alex