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]Re: Triplesec... storing permissions in ldap
Date Fri, 29 Dec 2006 01:57:05 GMT

On Dec 28, 2006, at 1:55 PM, David Jencks wrote:
<big snip>

>
> Not entirely.
>
> First of all, I don't think I explained one of my thoughts, which  
> is that keeping a list of all permissions used in an application  
> doesn't really have any value.  In general there's an infinite set  
> of possible permissions for an application and there's no practical  
> way to enumerate all of them.  To my eyes the only thing the  
> permissions are currently used for is to construct the admin role,  
> and this is not something that is generally useful: it certainly  
> has no universal definition in jacc or j2ee.  I would prefer to  
> have some button on a gui to collect all the permissions in defined  
> roles and profiles and add them to a particular role (or profile)
>
> Assuming you agree with this, we will be storing permissions  
> associated with role and profile.  To construct a permission  
> instance we need:
>
> permission class
> permission name
> permission action
> grant/deny
>
> In relational terms, these are all part of the primary key.  IIUC  
> to directly express this in ldap you get dns with something like  
> a=foo+b=bar+c=baz,ou=groupId,....... which I have not yet seen in  
> practice and looks confusing to me.  I thought it would be easier  
> to deal with if instead we treated it as several levels:
>
> role or profile
>
> permission class
>
> [grant,deny]= permission name
> with actions as a multivalued attribute for the permission name.
>
> This results IIUC in the ldif to install a StringPermission with no  
> actions looking something like:
>
>
> dn:  
> roleName=mockRole1,ou=roles,appName=mockApplication,ou=applications,dc 
> =example, dc=com
> objectClass: top
> objectClass: policyRole
> roleName: mockRole1
>
> dn: permClassName=org.safehaus.triplesec.guardian.StringPermission,  
> roleName=mockRole1,ou=roles,appName=mockApplication,ou=applications,dc 
> =example, dc=com
> objectClass: top
> objectClass: permClass
> permClassName: org.safehaus.triplesec.guardian.StringPermission
>
> dn: grant=mockPerm0,  
> permClassName=org.safehaus.triplesec.guardian.StringPermission,  
> roleName=mockRole1,ou=roles,appName=mockApplication,ou=applications,dc 
> =example, dc=com
> objectClass: top
> objectClass: permGrant
> grant: mockPerm0
>
> It might be clearer to look at the schema and code to handle this  
> in guardian-ldap and admin-api in sandbox/triplesec-jacc.  It's  
> entirely possible I've missing something basic and there's a better  
> way to handle this.... but (obviously :-) I haven't seen it yet.
>

so the schema for the above is

attributetype ( 1.2.6.1.4.1.22555.1.1.1.3.208
         NAME 'permClassName'
         DESC 'java class for a set of permission'
         EQUALITY caseExactMatch
         SUBSTR caseExactSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.2.6.1.4.1.22555.1.1.1.3.209
         NAME 'grant'
         DESC 'name for a granted permission'
         EQUALITY caseExactMatch
         SUBSTR caseExactSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.2.6.1.4.1.22555.1.1.1.3.210
         NAME 'deny'
         DESC 'name for a denied permission'
         EQUALITY caseExactMatch
         SUBSTR caseExactSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.2.6.1.4.1.22555.1.1.1.3.211
         NAME 'action'
         DESC 'action for a permission'
         EQUALITY caseExactMatch
         SUBSTR caseExactSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

objectclass ( 1.2.6.1.4.1.22555.1.1.1.4.205 NAME 'permClass'
     SUP top
     AUXILIARY
     MUST ( permClassName )
     )

objectclass ( 1.2.6.1.4.1.22555.1.1.1.4.206 NAME 'permGrant'
     SUP top
     AUXILIARY
     MUST ( grant )
     MAY  ( action )
     )

objectclass ( 1.2.6.1.4.1.22555.1.1.1.4.207 NAME 'permDeny'
     SUP top
     AUXILIARY
     MUST ( deny )
     MAY  ( action )
     )


Note that there are two objectClasses that are the same structure,  
permGrant and permDeny.  This doesn't thrill me.

I guess another way to handle this is with another component in the  
dn, something like:

dn:  
roleName=mockRole1,ou=roles,appName=mockApplication,ou=applications,dc=e 
xample, dc=com
objectClass: top
objectClass: policyRole
roleName: mockRole1

dn: permClassName=org.safehaus.triplesec.guardian.StringPermission,  
roleName=mockRole1,ou=roles,appName=mockApplication,ou=applications,dc=e 
xample, dc=com
objectClass: top
objectClass: permClass
permClassName: org.safehaus.triplesec.guardian.StringPermission

dn: permName=mockPerm0, ou=grants,  
permClassName=org.safehaus.triplesec.guardian.StringPermission,  
roleName=mockRole1,ou=roles,appName=mockApplication,ou=applications,dc=e 
xample, dc=com
objectClass: top
objectClass: permName
grant: mockPerm0


with schema something like

attributetype ( 1.2.6.1.4.1.22555.1.1.1.3.208
         NAME 'permClassName'
         DESC 'java class for a set of permission'
         EQUALITY caseExactMatch
         SUBSTR caseExactSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.2.6.1.4.1.22555.1.1.1.3.209
         NAME 'permName'
         DESC 'name of a permission'
         EQUALITY caseExactMatch
         SUBSTR caseExactSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.2.6.1.4.1.22555.1.1.1.3.211
         NAME 'action'
         DESC 'action for a permission'
         EQUALITY caseExactMatch
         SUBSTR caseExactSubstringsMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

objectclass ( 1.2.6.1.4.1.22555.1.1.1.4.205 NAME 'permClass'
     SUP top
     AUXILIARY
     MUST ( permClassName )
     )

objectclass ( 1.2.6.1.4.1.22555.1.1.1.4.206 NAME 'permName'
     SUP top
     AUXILIARY
     MUST ( permName )
     MAY  ( action )
     )

Is this a better design?  I'm not convinced:

- it has the same number of object classes (we've replaced one of  
permGrant and permDeny with the already existing ou)
- there's one more part in the dn
- there's nothing constraining ou to be grants or denials
- we're leaning on an object class we don't control (ou)

However since I'm a complete beginner here I'd certainly like to hear  
more opinions.

many thanks
david jencks


<another big snip>



Mime
View raw message