views:

32

answers:

1

I have a web-app configured with spring security which gets users and roles from an ldap tree.

I have a dn ou=User,dc=application for users and, for role, ou=Groups,dc=application .

Every role is an entry in the second subtree and the association is made by attribute member in role entry.

Actually i have 5 different role access (ROLE_A, ROLE_B, ROLE_C, ROLE_D, ROLE_E) : every role gives grant to access to a specific url. Every role are independent.

Role subtree schema (very simple and incomplete)

ou=Groups,dc=application . --cn=A --cn=B --cn=C --cn=D --cn=E

Now I have to satisfy a request to insert 3 new roles (ROLE_F, ROLE_G, ROLE_H) that can be assigned following a fixed schema : - ROLE_F can be assigned only if user is in role to ROLE_B, ROLE_D, - ROLE_G can be assigned only if user is in role ROLE_C or ROLE_E - ROLE_H can be assigned only if user is in role ROLE_A or ROLE_B

Which is the best pratice to manage these 3 new roles? Shall I consider them as independent and managed dependency in application or what else?

Thanks

A: 

Is there any reason that the new roles might need to be managed as separate items, in that either now or maybe someday in the future e.g. the permissions granted by ROLE_F will not apply to 100% of the ROLE_B people? If so, then I would say they should be managed separately, even if you only suspect that someday they might need to be separate... after all, you might as well put in the little extra effort now to save trouble in the future.

But if all you're really need to do is add new permissions (e.g. those granted by ROLE_F) to the existing groups (ROLE_B in this example), then there's no need for new roles.

ewall
ROLE_F (like ROLE_G and ROLE_H) contains, special actions permissions (administration functions), so they will not apply to 100% of the ROLE_B people. Another specific is that the specific role_f will be assigned (or not) only if the user has ROLE_B or ROLE_D. Another questions that I have, is how to implement this scenario in my ldap server.
Lorenzo Pasquinelli
Unfortunately, these new permissions added by these new roles couldn't be associated to the existing groups, otherwise I associate these to actual groups.
Lorenzo Pasquinelli