directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [Triplesec] Using objectClass inheritence
Date Sat, 11 Aug 2007 07:59:43 GMT
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

Mime
View raw message