gmane.comp.ldap.umich

ldap model to provide rights to people/groups

Hi,

I have some trouble designing an LDAP model. I have to setup something in which I can lookup what right a person has to access a certain module.
This has to be generic in respect of where the peoples/groups are stored in the directory. So it could be implemented in different LDAP organisations.

I came up with the following:
* a structural myModule class with some text attributes (version)
* a structural myMember class with one text attribute which describes the access and a link to a user/group somewhere in the directory

Now I make a hierarchy like:
cn=moduleA,ou=Modules : with a myVersion text attribute
cn=user1,cn=moduleA,ou=Modules : with myMode (read/write etc string) attribute and myTargetDN DN attribute which points somewhere.

Attached are the schema & ldif sample (all created with the Apache DS eclipse plugins)

My questions are:
* does this make any sense. Or is there hardly anything to say about it without the exact project information etc
* can I put an index on the myTargetDN? Because this one will be searched for mostly I think: 'is current user allowed to access this module.'
* should I make more use of auxiliary classes? (couldn't find a decent structural class where I could base myModule on)
* Any ideas on where can I find more info about LDAP modelling? (besides this mailing list ;-)

Thanks a lot for your time/feedback.

greetings, Wessel

Attachment (my.schema): application/octet-stream, 700 bytes

headers

Dieter Kluenter | 13 Oct 14:25

Re: ldap model to provide rights to people/groups

"Wessel Louwris" <wessel.louwris@...> writes:

> Hi,
>
> I have some trouble designing an LDAP model.  I have to setup something in which I can lookup what
> right a person has to access a certain module.
> This has to be  generic in respect of where the peoples/groups are stored in the directory. So it
> could be implemented in different LDAP organisations.
>
> I came up with the following:
> * a structural myModule class with some text attributes (version)
> * a structural myMember class with one text attribute which describes the access and a link to a user
> /group somewhere in the directory
>
> Now I make a hierarchy like:
> cn=moduleA,ou=Modules  : with a myVersion text attribute
>   cn=user1,cn=moduleA,ou=Modules : with myMode (read/write etc string) attribute and myTargetDN DN
> attribute which points somewhere.
>
> Attached are the schema & ldif sample (all created with the Apache DS eclipse plugins)
>
> My questions are:
> * does this make any sense. Or is there hardly anything to say about it without the exact project
> information etc

As you don't describe your project it is hard to comment on your
schema. But you may face some problems as your objectclass myModule
requires the attribute type commonName, depending on your directory
vendor, you may have to include an other structural objectclass.

> * can I put an index on the myTargetDN? Because this one will be searched for mostly I think: 'is
> current user allowed to access this module.

You only can create an equality index, as this attribute type provides no
substring rules.

> * should I make more use of auxiliary classes? (couldn't find a decent structural class where I could
> base myModule on)

It has always been good practice to design  based on standard track
objectclasses and extend classes to individual requirements. 

> * Any ideas on where can I find more info about LDAP modelling? (besides this mailing list 

http://www.guug.de/veranstaltungen/ldapcon2007/slides/Design-of-a-Directory-Information-Tree-presentation.pdf

-Dieter

--

-- 
Dieter Klünter | Systemberatung
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6
53°08'09,95"N
10°08'02,42"E

headers

Dustin Puryear | 13 Oct 18:02

Re: ldap model to provide rights to people/groups

Details were in short supply in that original email, agreed.

I'm a little confused why the traditional roles or group membership model won't work here? I can see the need to create an aux or even structural objectclass for the application information, but assigning rights should be a snap and could use what is already there.

Or am I missing something?

> "Wessel Louwris" <wessel.louwris-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:
>
>> Hi,
>>
>> I have some trouble designing an LDAP model. I have to setup something
>> in which I can lookup what
>> right a person has to access a certain module.
>> This has to be generic in respect of where the peoples/groups are
>> stored in the directory. So it
>> could be implemented in different LDAP organisations.
>>
>> I came up with the following:
>> * a structural myModule class with some text attributes (version)
>> * a structural myMember class with one text attribute which describes
>> the access and a link to a user
>> /group somewhere in the directory
>>
>> Now I make a hierarchy like:
>> cn=moduleA,ou=Modules : with a myVersion text attribute
>> cn=user1,cn=moduleA,ou=Modules : with myMode (read/write etc string)
>> attribute and myTargetDN DN
>> attribute which points somewhere.
>>
>> Attached are the schema & ldif sample (all created with the Apache DS
>> eclipse plugins)
>>
>> My questions are:
>> * does this make any sense. Or is there hardly anything to say about it
>> without the exact project
>> information etc
>
> As you don't describe your project it is hard to comment on your
> schema. But you may face some problems as your objectclass myModule
> requires the attribute type commonName, depending on your directory
> vendor, you may have to include an other structural objectclass.
>
>> * can I put an index on the myTargetDN? Because this one will be
>> searched for mostly I think: 'is
>> current user allowed to access this module.
>
> You only can create an equality index, as this attribute type provides no
> substring rules.
>
>> * should I make more use of auxiliary classes? (couldn't find a decent
>> structural class where I could
>> base myModule on)
>
> It has always been good practice to design based on standard track
> objectclasses and extend classes to individual requirements.
>
>> * Any ideas on where can I find more info about LDAP modelling? (besides
>> this mailing list ;-)
>
> http://www.guug.de/veranstaltungen/ldapcon2007/slides/Design-of-a-Directory-Information-Tree-presentation.pdf
>
> -Dieter
>
> --
> Dieter KlÃ¼nter | Systemberatung
> http://www.dpunkt.de/buecher/2104.html
> GPG Key ID:8EF7B6C6
> 53Â°08'09,95"N
> 10Â°08'02,42"E
>
>
> --
> This message was scanned by ESVA and is believed to be clean.
> Click here to report this message as spam.
> http://esva.puryear-it.com/cgi-bin/learn-msg.cgi?id=
>
>
>

--
Dustin Puryear
President and Sr. Consultant
Puryear Information Technology, LLC
225-706-8414 x112
http://www.puryear-it.com

Author, "Best Practices for Managing Linux and UNIX Servers"
http://www.puryear-it.com/pubs/linux-unix-best-practices/

headers

Adam Tauno Williams | 14 Oct 04:12

Re: ldap model to provide rights to people/groups

On Mon, 2008-10-13 at 11:02 -0500, Dustin Puryear wrote:
> Details were in short supply in that original email, agreed.
> I'm a little confused why the traditional roles or group membership
> model won't work here? I can see the need to create an aux or even
> structural objectclass for the application information, but assigning
> rights should be a snap and could use what is already there.
> Or am I missing something?

Ditto, the above.  And with the advantage that most [all?] LDAP tools
understand groupOfNames and provide some support for group management.

headers

Wessel | 14 Oct 11:21

Re: ldap model to provide rights to people/groups

Adam Tauno Williams wrote:
> On Mon, 2008-10-13 at 11:02 -0500, Dustin Puryear wrote:
>   
>> Details were in short supply in that original email, agreed.
>> I'm a little confused why the traditional roles or group membership
>> model won't work here? I can see the need to create an aux or even
>> structural objectclass for the application information, but assigning
>> rights should be a snap and could use what is already there.
>> Or am I missing something?
>>     
>
> Ditto, the above.  And with the advantage that most [all?] LDAP tools
> understand groupOfNames and provide some support for group management
Thanks for your help all. I guess I'm the one who is missing something 
The pdf in the link from Dieter earlier was helpful, because I did not 
know about the "traditional roles or group membership model".

I'll describe what the project is about: we are building a portal 
(hippo-portal, based on jetspeed) where there will be all kind of 
portlets on the pages. You have to authenticate first (ldap).  Which 
portlets somebody can see, or what they can do in the porlet (read-only, 
read/write for example) is depended on who you are.

I'm experimenting with the groupOfNames below my Module container, and 
it looks like I can skip some of my custom classes with that.

Thanks a lot.

Wessel

headers

Adam Tauno Williams | 14 Oct 12:52

Re: ldap model to provide rights to people/groups

> >> Details were in short supply in that original email, agreed.
> >> I'm a little confused why the traditional roles or group membership
> >> model won't work here? I can see the need to create an aux or even
> >> structural objectclass for the application information, but assigning
> >> rights should be a snap and could use what is already there.
> >> Or am I missing something?
> > Ditto, the above.  And with the advantage that most [all?] LDAP tools
> > understand groupOfNames and provide some support for group management
> Thanks for your help all. I guess I'm the one who is missing something 
> The pdf in the link from Dieter earlier was helpful, because I did not 
> know about the "traditional roles or group membership model".
> I'll describe what the project is about: we are building a portal 
> (hippo-portal, based on jetspeed) where there will be all kind of 
> portlets on the pages. You have to authenticate first (ldap).  Which 
> portlets somebody can see, or what they can do in the porlet (read-only, 
> read/write for example) is depended on who you are.

We have much the same thing with the sites we use; access is based on
group membership.  We authenticate the user and then query all the
groups the user is a member of, and then we cache that list in the
session.  What objects the user can see/manipulate is tied to group
membership.

> I'm experimenting with the groupOfNames below my Module container, and 
> it looks like I can skip some of my custom classes with that.