Concept of groups vs concept of roles

Question

Hi!
I'm designing an LDAP structure mainly for authentication and authorization of users. I want to use the LDAP server for applications, intranet (different platforms like linux, NT, ...) and portals.
I read the Admin guide about groups and roles and found, that there aren't that many reasons for using roles instead of groups. The only real difference is (as I understood) that when using roles, I don't have to search for the the groups a user is member of, because every user contains the nsrole attribute with all the roles he is member of.
One big reason for not using roles is, that they are quite specific for iPlanet Directory Server. If one ever changes to another product (for example OpenLDAP) the roles concept may or may not be the same. When using groups I don't have that problem.
(If my information about that is incorrect please conradict!)
A mixture of groups and roles is a quite bad idea because if I put a group in a role, the "nsrole" attribute is added only to the group but not the the members of the group, so if I use roles, I should stick to them and should not use any groups.
As I told at the beginning, I am planning an LDAP structure. I don't have any "real life LDAP-experience" so if your experience is different, please tell me.
Thanks in advance for your opinion!
Florian

Answer 1

1. Why there could be a problem without scopes in
groups. If I have two companies and each of them has
a group "employees". Two companies would probably be
separated in two different subtrees, so I just use a
dynamic group, where I can specify a subtree where
groupmembers can be located or I use static groups,
where I define each entry.You see, you had to make a choice on which group type you could use - not because one was more convenient for defining members for the problem at hand, but because only one would work at all.
One thing I did not mention about roles advantages: they all work the same way - if a new role type were invented, applications written to work with roles prior to the new role, would still work with that role type. Groups types are so different that forward compatibility is not possible - mostly because to even use groups, applications have to do all the work to do common things like, enumerate the group, enumerate the groups an entry belongs to, test for group membership etc.
>
2. The coding logic for group evaluation with dynamic
and static groups and even mixtures of it is quite
complicated, it is much easier to ask an entry for a
roledn and thats it, but do most clients support
roles? Probably not. But then roles have not been around as long. I don't have any hard data on how many apps use roles - you would be surprised how hard it is to get that data for a developer.
As far as I know roles are not used in any
other LDAP Server. Well, the Sun DS, and the Netscape DS (which admittedly were once the same thing) both support the same roles.
So you can optimize an
applications implementing a role based queries, but
if you have a OpenLDAP environment you also need a
possibility to use groups. Talk to the OpenLDAP people about that. I believe they (at one time at least) decided to support the Netscape slapi interface - roles have interface components in that api.
I do understand what you are saying - there isn't an RFC, so other servers don't support roles. Well, I'm sorry, I never got around to it. To be perfectly frank, a lot of LDAP RFCs/Drafts merely describe some proprietary mechanism which other servers never adopt. Some even describe mechanisms that nobody has ever implemented.
When it comes down to it, it is only you who can decide whether being able to move to OpenLDAP or some other server without any reimplimentation is an important consideration. Every server will have features not supported by others, and if your choice is to use only those that are commonly supported, then that is your choice.
Roles will allow much less complex coding in order to use them and they are much faster than equivalent client side operations, but the price is non-comformance with other servers. But when that non-conformance simply boils down to entries which merely "describe" the groups without adding application level functionality - how much have you really lost? Well, until you need to change server vendor you have only gained, and then you'll need to put in the effort you saved ealier.
On the other side, what
application do support roles right now? (I really
don't know)Apart from applications by vendors that also supply DS I don't know either - but support for features such as this need to come from customers of those products. It is surprisingly simple to add support for roles in a product (for most it will almost be free) - much simpler than for groups.