Groups and Roles

[zanfolim]

Hi,

I am planning to use Acegi in an application that has a need to split users in groups. I´ve noticed there seems to be some mixing in the terms 'group' and 'role', so this is what I think they mean:

- role: the user privileges to the system: this would be the administrator or the regular user roles;
- group: the group is a collection of users, possibly with the same roles, but working on different departments for example.

So, I could have two users with the role 'regular user', one of them being part of group 'department A' and another one being part of 'department B'.

The way it seems to me is that the 'role' tells the application wich transactions a given user can execute and the 'group' will help in the ACL control: for example, 2 regular users, one from department A and other one from department B, they both can access the transaction 'listCars', but they can only see the cars that belong to their group.

Given this, I understand that I could use Authorities to represent both 'role' and 'group' and that I would associate a given object indentity in the 'acl_permission' table with 2 records, one for the user who created the object and another one for the primary group the user belongs to.

Does anyone have a similar scenario and implemented something similar? This primary group would be something that would vary if the user has access to more than one application, so I am not sure I could have just one primary group (maybe I would have to have a 'chgrp' like function in my application....)

Thanks, both for any comments and for the great work in Acegi,

Tedi

[Ben Alex]

Generally "groups" are what people use to bundle users together. "Roles" are then typically assigned to "groups". ACL permissions can be assigned to a "recipient", which is typically a "role" or a "principal".

Acegi Security makes no use of groups. If you think about it, we only use roles and principals directly. Accordingly, groups are more an administrative convenience.

Your best bet is to write a custom AuthenticationDao which understands which groups a given username/principal belongs to. Whatever table schema (or LDAP schema etc) you use should be queried and each of the roles indirectly held via a group member should be added to the returned UserDetails.

Both the ACL system, and also the standard AccessDecisionVoter (and particularly RoleVoter) will then just work with roles, as groups never made it into the Acegi Security system.

Your only challenge with this seems to be creating a new object and assigning some ACL entries against it. There are no prescribed rules in this regard, but it's typical to have a top-level object (via the ACL permissions hierarchy) where you assign global default permissions to particular roles. For example, ROLE_EVERYONE might have read permission by default, and ROLE_ADMINISTRATOR might have administer permission by default. The exact permissions will depend on what is appropriate for your application, recalling that you can revoke permissions at lower levels of the ACL hierarchy.

I would urge you not to introduce the concept of groups into the ACL receipient infrastructure, although having said that there is no technical prohibition on it (due to Acegi Security's interface-based design). The benefit of avoiding groups (except at the AuthenticationDao level) is that you will not need to customise much - if any - Acegi Security code.

[dlevine]

Hello, I'm in a similar situation and was wondering if anything had changed over the past two years in this sense, or if I should still follow Ben Alex's advice below?

I am using acegi for security in an app, but am not able to get the fine grained control I need. I need to be able to limit certain pages/function to members of a certain ROLE within a certain GROUP. I am the BOSS role of the IT group, so I can access the admin users page for GROUP=IT. Similarly, if I am the BOSS of the HR group I can access the admin users page for GROUP=HR.

I understand why this makes sense for me to map in my application separately, but it does also seem like a lot of duplication for me to define roles IT_BOSS and HR_BOSS and map those separately down to roles and groups and users in my system. The worst part is that I have to manually do the work everywhere I use Acegi API/tags to translate from Acegi roles to the correct group limitations.

Thanks for any thoughts!

[zanfolim]

Saw your message just now.
Yes, we followed Ben´s advice here and it is working fine for us.

HTH,

Tedi

[chromaticbum]

Hello everyone,

I am having a hard time understanding how I could make it so that administrators in my system could define custom roles.

Let me describe the scenario:
1. I would like users to be able to be part of multiple roles.
2. I would like users that have permission to be able create new roles.
3. I would like roles to determine which classes of secured object users can create, read, edit, delete. (so if a role has this permission set, the users that are part of that role can perform any of these operations to any instances of this object class)
4. I would like roles to determine which instances of secured objects users can edit, read, and delete. (so a user of this role can perform these three operations on only specific instances of the secured object)

The only way I see this being possible is the following:
Make roles themselves secured objects in my database
Assign specific secured objects ACE's that give these secured roles various permissions.
Write a custom AuthenticationDao that populates the UserDetails object with the user-defined roles.
The place that I am having a lot of difficulty with is how do I then secure my service layer with this setup? Normally we use the annotation:
@Secure({"ROLE_USER", ...}) for securing the service layer, how do we do this when new roles can be introduced by users?
Also, I am not sure how I could use ACL voters in this scenario either, I am thinking I would have to write a custom voter that checks every role a user is part of against the object action in question.

I see many holes with my approach, such as decoupling roles as secured objects, instead of keeping them inside of the spring security. Also, I think there should be a way to do this without writing custom voters, but I can't figure it out.

Any help would be appreciated,
Thank you,
Hollin Wilkins

[chromaticbum]

Nevermind,

Reading through Ben's post I realize how this can be accomplished now without any problem.

Thank you all!
- Hollin

[magicduncan]

Ben,

Is your advice to avoid using Groups still applicable since the implementation of http://jira.springframework.org/browse/SEC-272?

Cheers