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 Fri, 10 Aug 2007 21:26:36 GMT

On Aug 10, 2007, at 2:14 PM, Alex Karasulu wrote:

> Hi David,
>
> I just wanted to list some ideas that I have on how we can bridge  
> this gap
> between simple language agnostic permissions presently in Triplesec  
> with
> Java permissions.
>
> First I want to stress why it is important to remain language and  
> platform
> neutral and I think you will agree with this line of thought.  Even  
> though the
> server is written in Java on top of ApacheDS we want it to be  
> applicable for
> use on any platform with any language.  This way .NET, PHP and many
> other clients can leverage the same system.
>
> However as you noted, and I agree fully, in Java we need more than the
> presence of a permission to determine if someone is authorized to  
> access
> a resource or perform some operation.  This is due to the open  
> ended nature
> of evaluating the implies() method of a Java permission.
>
> 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.  What would I do  
to make this a subtype of policyPermission?  What is the advantage of  
making this a subtype of  policyPermission rather than an independent  
objectclass?

thanks
david jencks

n.b. the oids are not final, obviously :-)
>
> This is something I would like to do along with reading and fully  
> evaluating
> that NIST paper so I can then look into the best way to model roles/ 
> groups
> in Triplesec.
>
> Alex
>


Mime
View raw message