directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [Triplesec] Using objectClass inheritence
Date Sat, 11 Aug 2007 15:10:58 GMT

On Aug 11, 2007, at 12:59 AM, Alex Karasulu wrote:

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

I'm not sure this is the whole picture.  My impression was that the  
policyPermission name attribute had to  uniquely identify the  
permission within its parent.  This would mean that it can't be the  
same as the permJavaName which is definitely not a unique id under  
any circumstances: you actually need the permJavaClass, the  
permJavaName, and the permJavaActions to completely identify a  
permission.  So, in my copy of the schema, permName is described as  
likely to be meaningless:

attributetype ( 1.3.6.1.4.1.18060.0.4.6.2.201
         NAME 'permName'
         DESC 'the case sensitive name of a permission within the  
system, often a meaningless unique id'
         EQUALITY caseExactMatch
         SUBSTR caseExactSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

Given this, what advantage is it to have javaPermission subclass  
policyPermission?  It seems to me that the only effect is to prevent  
using javaPermission in other contexts where it might turn out to be  
useful.

thanks
david jencks



>
> HTH,
> Alex
>
>
>


Mime
View raw message