directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: Triplesec... storing permissions in ldap
Date Thu, 28 Dec 2006 13:23:07 GMT
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,dc=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.

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

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

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

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

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


View raw message