directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject [TRIPLESEC]Re: Triplesec... storing permissions in ldap
Date Thu, 28 Dec 2006 18:55:06 GMT

On Dec 28, 2006, at 8:23 AM, Alex Karasulu wrote:

> David Jencks wrote:
>> Right now triplesec is basically using strings as permissions, and  
>> they
>> are stored as multi-valued attributes like so:
>> objectclass ( NAME 'policyRole'
>>     SUP top
>>     MUST ( roleName )
>>     MAY  ( grants $ denials $ description ) )
>> objectclass ( NAME 'policyProfile'
>>     SUP top
>>     MUST ( profileId $ user )
>>     MAY  ( grants $ denials $ roles $ userPassword $ description $
>> safehausDisabled ) )
>> or as a bit of ldif:
>> dn:
>> roleName=mockRole5,ou=roles,appName=mockApplication,ou=applications,d 
>> c=example,dc=com
>> objectClass: top
>> objectClass: policyRole
>> grants: mockPerm9
>> grants: mockPerm7
>> grants: mockPerm5
>> grants: mockPerm4
>> denials: mockPerm6
>> roleName: mockRole5
>> (this includes my local modification so roles can have denials).
> FYI now with denials in roles the set wise calculation of effective
> permissions will need to account for denials in roles.  This also  
> brings
> about the issue of permission precedence since some denials may now
> clash with grants.  A policy around how this will be handled is  
> needed.

I figure that in guardian both role and policy need a grant  
Permissions and a deny Permissions.  For either one, a permission is  
implied if the grant Permissions implies it AND the denies  
Permissions doesn't imply it

grants.implies(p) && !denies.implies(p)

>> After looking around at I think we can  
>> store
>> 99% of them with 3 strings:
>> className
>> permissionName
>> action
> I think we can create a special permission type (objectClass) called a
> javaPermission that adds the extra className and action attributes:
> permissionName is already present.  This new javaPermission basically
> extends the existing string permission objectClass.

I think it makes more sense to model the existing string permissions  
as a kind of java permission and look for a good datamodel for java  
>> and possibly depending on how ldap datamodels work
>> grant/deny
> Why would you add a grant and deny attribute to a permission?
>> Within a role or profile, these 3 or 4 strings are needed to get a
>> unique permission.
> Ahh ok I see the confusion.  You mean a grant or deny on a Role or a
> Profile and not in the permission object itself.
> Basically the Role or Profile (in ldap) will refer to the permission
> that it grants or denies.  In the API there may be a reference to the
> actual Permission object.
>> I've been trying to learn about ldap schemas, the data model,  
>> ldif, etc
>> by figuring out how to fit this info into ldap but I'm pretty  
>> bewildered
>> and maybe someone with non-zero experience could review and  
>> improve my
>> suggestion below or suggest how to proceed.
> No problem let me take a look ...
>> It looks to me as if one way to proceed would be to have the  
>> className
>> with permissionNames grouped under each labelled grant or deny, then
>> with the actions as attributes on the permission.  Does the following
>> schema do this?
>> attributetype (
>>         NAME 'action'
>>         DESC 'action for a permission'
>>         EQUALITY caseExactMatch
>>         SUBSTR caseExactSubstringsMatch
>>         SYNTAX )
> Ok defining an action attribute ... this looks ok minus the need for a
> good OID.  Also you might want the attribute to be actions  
> (plaural) if
> it can be multivalued?
>> objectclass ( NAME 'className'
>>     SUP top
>> objectclass ( NAME 'grant'
>>     SUP top
>>     MAY  ( action )
>> objectclass ( NAME 'deny'
>>     SUP top
>>     MAY  ( action )
> Hmmm this is not a good idea.  I would design the grants and  
> denials as
> attributes that can be included within the objectClass of a Role and a
> Profile.  These attributes should just associate a permission with the
> Role or Profile as would a foreign key into another table in RDBMS  
> land.
> So let's say you define a ldap objectClass called javaPermission for
> your permission like so:
> objectclass ( TBD NAME 'javaPermission'
> 	SUP policyPermission
>         AUXILIARY
>         MUST ( className )
> 	MAY ( action )
>> I'm imagining a dn something like
>> grant=/servlet/ 
>> *,,roleName= 
>> peon,applicationName=foo,....
> Hmmm I think you may have a slight missunderstanding on how to use  
> a DN
> in designing the directory.  NP though I don't think we need to mess
> with the directory's hierarchy that much.  The organization we have  
> will
> work.
>> with attributes like
>> action=POST,GET
>> action=INDEX
> Ok you need to make action into a multivalued attribute and perhaps  
> call
> it actions but your whole view of how to organize the DIT needs some
> work.  Let's take it step by step.  For now our current structure is
> well formulated which in turn effects the DN used.  Just keep in mind
> the DN is merely like a primary key for looking stuff up.  So when you
> look up a permission the DN need not have all the aspects of the
> permission listed within it.
> If the permission name uniquely identifies the permission within a
> context of the system then we can simply keep that permission under a
> context and use the permission name as the relative name of the
> permission entry.
> Does this make sense?

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

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:

xample, dc=com
objectClass: top
objectClass: policyRole
roleName: mockRole1

xample, dc=com
objectClass: top
objectClass: permClass

dn: grant=mockPerm0,,  
xample, 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.

>> Some of my other questions are...  AUXILIARY or STRUCTURAL?
> AUXILIARY is best I would warn against using STRUCTURAL  
> objectClasses in
> general but sometimes you have to.  Here I think we may need to use
> STRUCTURAL objectClasses for permissions when we really used  
>  This is because an entry needs at least one STRUCTURAL  
> objectClass.  An
> entry can have any number of AUXILIARY objectClasses.
> This would take too long to explain but here's the gist of it in a
> manner easily understood by Java programmers ...
> ObjectClasses are like Java classes and Interfaces.  Certain  
> inheritance
> rules are similar.  AUXILIARY objectClasses are like interfaces, where
> an entry can actually have several AUXILIARY objectClasses in use for
> it.  STRUCTURAL objectClasses are like concrete classes where an entry
> can really have only one STRUCTURAL objectClass.  An entry must have a
> STRUCTURAL objectClass defined for it.
> An ABSTRACT objectClass is like an abstract Java class.  You cannot
> create an object from and ABSTRACT objectClass and hence you cannot  
> have
> an entry with just an ABSTRACT objectClass.
>> What if anything ties the object classes together in a tree, so e.g.
>> grant and deny occur "inside" className?  Should there be MAY  
>> ( grant $
>> deny) in the className objectclass?
> I think you are confusing a few concepts.  The structure of the  
> tree is
> governed by other kinds of complex schema constructs like
> dITStructureRules and nameForms however we need not talk about these
> right now.
>> The actions and possibly the grant/deny are likely to have lots of
>> bizarre punctuation, such as the commas in the example above.  How  
>> does
>> one deal with that in ldap?
> This is not a problem unless we start using those attributes within  
> the
> DN of the entry which we should not.  Basically the syntax of the  
> action
> attribute will determine the valid values for these attributes that we
> define.

I think that the permission name (which I am thinking will be more or  
less as it is today modelled as grant=permissionName or  
deny=permissionName) can also have bizarre punctuation and need to be  
part of a dn.  Maybe you can find some other way.... I sure haven't  
seen how to associate a set of values except using an objectclass.
>> Many thanks for any help, and I hope this isn't too much of a user  
>> list
>> question :-)
> No problem at all.  Let's just step carefully on some of your changes
> until we all have a grasp of what they entail overall wrt schema  
> changes
> and other things they will impact.

I think hammering this out in the sandbox will be a good idea.

many thanks
david jencks

> Alex
> <akarasulu.vcf>

View raw message