I am currently setting up a small server with several applications. Since no Active Directory etc is planned, but I do need a centralized user administration, I decided for LDAP since all applications are capable of authenticating against it.
I have already set up a domain "dc=example,dc=lan". It has two organizational Units. Groups and Users. My plan was, to create a posixGroup for every application, so that a user can be added to each group (if he/she was allowed to use this application).
The structure would then be (example):
for each group
cn=ejabberd,ou=groups,dc=example,dc=lan
where cn=ejabberd is of type "posixGroup"
and for users
cn=user1,ou=users,dc=example,dc=lan
where cn=user1 is of type "posixAccount"
Some, but not all, applications expect the "mail" attribute as login name. Some don't.
My problem is, that searching for users in ou=users is easy as 1,2,3 - searching in "cn=ejabberd,ou=groups,dc=example,dc=lan" is sheer driving me crazy since the users are not a "child" to this group but a "memberuid" attribute.
I have tried different filters and thought about another setup.. Just cannot think of anything different making sense right now.
Am I running down the wrong way, or maybe just blind to what's right in front of me?
I'd be glad for any finger pointing out a direction.
So here is, how I did it:
I created the following structure.
+dc=example,dc=com
+ou=groups
| +employees (PosixGroup)
| +service1 (GroupOfNames)
| +service2 (GroupOfNames)
+ou=users
| +user1 (User Account)
| +user2 (User Account)
etc..
Groups like "service1" and "service2" are of type "GroupOfNames". Furthermore I had to install the "memberOf"-Overlay so I could search for this exact attribute of a user.
This now gives me the possibility to tell each service to use a search filter that returns only the members of one special group, which will be granted access. For instance, ejabberd will use this filter:
"(&(objectClass=inetOrgPerson)(memberof=cn=ejabberd,ou=groups,dc=example,dc=com))"
Found these informations on the following website. Just take care to set the filter case sensitive! "memberOf" will not return any results, since the overlay in this example uses "memberof".
http://www.schenkels.nl/2013/03/how-to-setup-openldap-with-memberof-overlay-ubuntu-12-04/
I suggest you're on the wrong track. You don't want to authenticate by application, you just want to define overall roles that users can be in. The applications can then be defined to require certain role(s) per application funtion, web page, etc. As a limiting case, an application can be a role, but if you set out to define it that way you're overly limiting yourself.
To answer your immediate problem, you only have to search under the ou=Groups item for posixGroups which have memberUID={0} where {0} is the DN of the user. In other words the search filter is
(&(objectClass=posixGroup)(memberUID={0}))
Iterating those search results then gives you the DNs of all the groups of which he is a member.
I have a Redmine installation and would like the ability to grant a user the ability to view (and maybe update) a single issue (not all issues in the project). The catch is that the issue is reported by someone else.
Use Case:
Users A,B, and admin C
admin C creates two bug reports 1 and 2
admin C wants to grant view access to user A on bug 1
admin C wants to grant view access to user B on bug 2
User A should not be able to access bug2
User B should not be able to access bug1
Can this be done with Redmine? I have been messing around with the settings, but I don't see an easy way to accomplish this use case.
If not, are there other bug trackers that do allow for such a use case?
You have at least a couple of more options.
Create a new role 'View Own Issues'. Give it issue visibility to just created or assigned issues, flag "Issues can be assigned to this role" and enable just "View issues" and "Add notes".
Then, you can assign each issue to the proper user.
The advantage with a private issue is that you can have a set of privileged users as Reporters that will still be able to inspect the issue, since it is still public.
The downside is that just one user can be assigned to the issue, therefore you have limited freedom.
Create a subproject that represents a visibility context and add members as needed. Move the issue to the subproject. You can still see the issue at the upper level, where assigned visibility is shown by the 'Project' field.
You cannot assign view permissions on single issues in redmine.
From the top of my head, you may use one of the following approaches in your scenario:
If you have only a limited number of users, you may be able to add different trackers (ACIssues and BCIssues), create two roles (AC and BC), associate user A and C with role AC, user B and C with role BC, and set permissions so that role AC has access to ACIssues, and role BC has access to BCIssues.
Private issues work the way you describe if issue 1 is assigned to user A, and issue 2 is assigned to user B.
The application is written in Ruby on Rails but the problem I am facing is more a design matter than language related.
the system provides service to a number of users to maintain a registry. So it relates persons to things. As such it has a model called Person representing owners and it has a model called User representing those who manage the registry.
Now a new requirement has arisen to allow People to log in and be able to change personal details which it was not required for the original design.
The question is how to refactor the application to allow this new requirement in?
One easy solution is to create Users for each person who request login credentials and link user to person entity but that is not very DRY as some fields such as firstname, surname etc. are in both classes and in particular, that is precisely the data people will be able to change. Besides User and Person are stored in separate tables.
The other possibility I was considering is to make one to extend the other but having data in separated tables it makes it a bit messy. Additionally the logical extension would be User <- Person as an user is (generally) a person but thinking on the implementation Person <- User is quite a lot easier.
One last option could be to scrap User and move login credentials into Person leaving logon fields empty for those who won't log in and half of the fields empty for those just login in.
Can you think of a better solution?
You could think about how this should ideally work if you were to write the application bottom-up, and then figure out how to make a reasonable compromise between that and your current setup. Here are some generic inputs.
As authentication is involved, you need an "Identity" that can be authenticated. This can be e.g. an email address and an associated password, with email verification.
An Identity can potentially be associated to multiple "Roles" and someone authenticated with the identity can choose which role to perform, e.g. "I am now an administrator" vs. "I am now a regular site user", and the role defines the user's current rights for the logged in identity. Or if you don't need that level of complexity, you can say that an Identity is a (single) Role.
You need some tracking between possible "Rights" and the Role the user is performing. E.g. the simplest setup could be the Identity or Role has some boolean can_edit_profile or can_modify_registry properties.
Whenever a user attempts to perform an action which requires certain Rights, it is simply a matter of looking up the corresponding rights set for the Role being performed by the user, to check whether the user is allowed to proceed.
For your application this may just involve adding a 'can_change_registry' property for your user objects, and check whether that property is True for any code accessing that part of the site.
Can anyone tell me, what's the real difference between group and role? I've been trying to figure this out for some time now and the more information I read, the more I get the sense that this is brought up just to confuse people and there is no real difference. Both can do the other's job. I've always used a group to manage users and their access rights.
Recently, I've come across an administration software, where is a bunch of users. Each user can have assigned a module (whole system is split into a few parts called modules ie. Administration module, Survey module, Orders module, Customer module). On top of it, each module have a list of functionalities, that can be allowed or denied for each user. So let's say, a user John Smith can access module Orders and can edit any order, but haven't given a right to delete any of them.
If there was more users with the same competency, I would use a group to manage that. I would aggregate such users into the same group and assign access rights to modules and their functions to the group. All users in the same group would have the same access rights.
Why call it a group and not role? I don't know, I just feel it that way. It seems to me that simply it doesn't really matter :] But I still would like to know the real difference.
Any suggestions why this should be rather called role than group or the other way round?
The divide between role and group comes from concepts of computer security (as opposed to simply resource management). Prof. Ravi Sandhu provides a seminal coverage of the semantic difference between roles and groups.
http://profsandhu.com/workshop/role-group.pdf
A group is a collection of users with a given set of permissions assigned to the group (and transitively, to the users). A role is a collection of permissions, and a user effectively inherits those permissions when he acts under that role.
Typically your group membership remains during the duration of your login. A role, on the other hand, can be activated according to specific conditions. If your current role is 'medical-staff' you might be able to see some of the medical records for a given patient. If, however, your role is also 'physician', you might be able to see additional medical information beyond what a person with just a role of 'medical-staff' can see.
Roles can be activated by time of day, location of access. Roles can also be enhanced/associated with attributes. You might be operating as 'physician', but if you do not have a 'primary physician' attribute or relation with me (a user with 'patient' role), then you cannot see my entirety of medical history.
You could do all that with groups, but again, groups tend to focus on identity, not role or activity. And the type of security aspects just described tend to align themselves better with the later than with the former.
For many cases, for the usage of classifying things together (and nothing more), groups and roles function just the same. Groups, however, are based on identity, whereas roles are meant to demarcate activity. Unfortunately, operating systems tend to blur the distinction, treating roles as groups.
You see a much clearer distinction with application or system-level roles - carrying application or system-specific semantics (like in Oracle roles) - as opposed to 'roles' implemented at the OS level (which are typically synonymous to groups.)
There can be limitations to roles and role-based access control models (like with anything of course):
http://www.lhotka.net/weblog/CommentView,guid,9efcafc7-68a2-4f8f-bc64-66174453adfd.aspx
About a decade ago I saw some research on attribute-based and relationship-based access control which provide much better granularity than role-based access control. Unfortunately, I haven't seen much activity on that realm in years.
The most important difference between roles and groups is that roles typically implement a mandatory access control (MAC) mechanism. You do not get to assign yourself (or others) to roles. A role admin or role engineer does that.
This is superficially similar to UNIX groups where a user can/might be able to assign himself to a group (via sudo of course.) When groups are assigned according to a security engineering process, the distinction blurs a bit, however.
Another important characteristic is that true RBAC models can provide the concept of mutually exclusive roles. In contrast, identity-based groups are additive - a principal's identity is the sum (or conjunction) of the groups.
Another characteristic of a true-RBAC based security model is that elements created for a particular role typically cannot be transitively accessed by someone who does not act under that role.
On the other hand, under a discretionary access control (DAC) model (the default model in Unix), you cannot get that type of guarantee with groups alone. BTW, this is not a limitation of groups or Unix, but a limitation of DAC models based on identity (and transitively, with identity-based groups.)
Hope it helps.
=======================
Adding some more after seeing Simon's well-put response. Roles help you manage permissions. Groups help you manage objects and subjects. Moreover, one could think of roles as 'contexts'. A role 'X' can describe a security context that rule how subject Y access (or does not access) object Z.
Another important distinction (or ideal) is that there is a role engineer, a person that engineers the roles, the contexts, that are necessary and/or evident in an application, system or OS. A role engineer typically is (but does not have to be) also a role admin (or sysadmin). Moreover, the true role (no pun intended) of a role engineer is in the realm of security engineering, not administration.
This is a novel group formalized by RBAC (even if it seldom gets used), one which has typically not been present with group-capable systems.
A group is a means of organising users, whereas a role is usually a means of organising rights.
This can be useful in a number of ways. For example, a set of permissions grouped into a role could be assigned to a set of groups, or a set of users independently of their group.
For example, a CMS might have some permissions like Read post, Create post, Edit post. An Editor role might be able to Read and Edit, but not create (don't know why!). A post might be able to Create and Read etc. A group of managers might have the editor role, while a user in IT, who is not in the managers group, may also have the editor role, even though the rest of his or her group does not.
So while in a simple system groups and roles are often closely aligned, this is not always the case.
A "group" is a collection of users. A "role" is a collection of permissions. That means that when group alpha includes group beta, alpha receives all the users from beta and beta receives all the permissions from alpha. Conversely, you could say role beta includes role alpha and the same conclusions would apply.
A concrete example makes things more clear. Consider "customer support" and "senior customer support". If you think of those collections as groups, then it is clear that customer support users "includes" senior customer support users. However, if you look at them as roles, then it is clear that senior customer support permissions "includes" customer support permissions.
In theory, you could simply have one collection type. However, it would be ambiguous if you were to say that "collection alpha includes collection beta". In that case, you can't tell if the users in alpha are in beta (like a role) or the users in beta are in alpha (like a group). In order to make terminology like "includes" and visual elements like tree views unambiguous, most rbac systems require you to specify whether the collection at issue is a "group" or a "role" at least for the sake of discussion.
Some analogies might help. Framed in terms of set theory, when group alpha is a subset of group beta, then permissions alpha are a superset of permissions beta. Compared to genealogy, if groups are like a tree of descendants, then roles are like a tree of ancestors.
Although there is semantic difference between Roles and Groups (as described above by other answers), technically Roles and Groups seems to be the same.
Nothing prevents you to assign Permissions directly to Users and Groups (this can be considered as a fine-tuning access control).
Equivalently, when User is assigned a Role, it can be considered a role Member, in the same sense when user becomes Member of a Group.
So we can end up with no real difference between Roles and Groups. Both can be considered for grouping Users AND/OR Permissions.
Thus difference is only semantic:
— if it is semantically used for grouping Permissions, it is then a Role;
— if it is semantically used for grouping Users, it is then a Group.
Technically, there is no difference.
NOTE - the following ramblings only makes sense if one is trying to impose security within an organization - that is to say, trying to limit the access to information...
Groups are empirical - they answer the question of "what". They are the "is" in the sense they reflect the existing reality of access. IT people love groups - they are very literal and easy to define. Eventually, all access control ultimately devolves (as we all learned back in middle school...) to answering the question "To what group do you belong?"
Roles, however, are more normative - they guide what "should be". Good managers and HR love "roles" - they don't answer - they ask the question of "Why?" Unfortunately, roles can also be vague and that "fuzziness" can drive (IT) people nuts.
To use the medical example above, if the role of "primary care physician" has more rights (i.e. access to more groups) than the role of an "x-ray technician", this is because people (managers and HR) decided why that needed to happen. In that sense they are "the collective wisdom" of an organization.
Let's say a doctor is given access (membership to a group with access) to financial records of patients. This is normally outside the "role" of a doctor and should be debated. So, no one (no matter how qualified) should have full access to all groups - it invites abuses to power. This is why "role engineering" is so important - without it, you just have group access handed out like so much candy. People will collect (and sometimes horde) group access with no discussion as to the dangers of too much power.
To conclude, the wisdom of well-defined roles helps moderate the dangers of runaway group access. Anyone in an organization can argue for access to a particular group. But once that access is provided, it's rarely given up. Role engineering (along with best-practices like well-defined group descriptions and empowered group access managers) can limit conflicts of interest within an organization, decentralize decision-making and help make security management more rational.
The previous answers are all wonderful. As was stated, the concept of Group vs Role is more conceptual than technical. We have taken the stance that Groups are used for containing users (a user can be in more than one group: i.e. Joe is in the Managers group as well as the IT group [he is a manager in IT]) and for assigning broad privileges (i.e. Our mag card system allows all users in the IT group access to the server room). Roles were used to now add privileges to specific users (i.e. people in the IT group can RDP to servers but cannot assign users or change permissions, people in the IT group with the Admin role can assign users and change permissions). Roles can be made up of other roles as well (Joe has Admin role to add users/privileges and also has DBA role to do database changes to the DBMS on the server). Roles can be very specific as well in that we can make individual user Roles (i.e. JoesRole) that can be very specific for a user. So, to recap, we use Groups to manage users and assign general Roles and Roles to manage privileges. This is also cumulative. The Group the user is in may have Roles assigned (or a list of available Roles) that will give very general privileges (i.e. IT group users have the role ServerRDP that lets them log onto the servers) so that is assigned to the user. Then any Roles the user belongs in will be added in the order they are defined with the last Role having the final say (Roles can Allow, Deny or not apply privileges so that as each Role is applied it will either override previous settings for a privilege or not change it). Once all the Group level Roles and User level Roles have been applied, a distinct security model is created for the user that can be used throughout our systems to determine access and capabilities.
Users are assigned to Roles based on the responsibility they play in any system. For example users in role Sales Manager can perform certain actions such as provide additional discount for a product.
Groups are used to 'group' users or roles in a system for easy management of security. For example a group named "Leadership Group" can have its members from roles Managers, Directors & Architects and individual users who are out of these roles as well. Now you should be able to assign certain privileges to this group.
Purpose of Groups and Roles vary in applications, but mainly what i understood is as follow,
Groups(set of users) are static while Roles(set of permissions) are dynamic with policies, for example based on time from (9 to 6) a group or user may have this role but not that.
You can assign a role to group. You can assign user to group and you can assign role to individual user in any role user. Meaning. Jean Doe can be in Group of SalesDeptartment with role off ReportWritter which allows to print our reports from SharePoint, but in SalesDepartment group, others may not have role of ReportWritter. - In other words, roles are special privileges withing assigned groups. Hope this makes any scenes.
Cheers!!!
This works for us:
Manage user policies through groups (occasionally add additional policies manually to individual users)
Manage service policies through roles (for example a microservice might need access to S3 and it will be granted permissions via a role)
I'm working on a site, which will have several modules that either fully available to certain users, semi available to other users, and unavailable to the rest.
For example:
An 'employee' is able to respond to the customer support tickets assigned to him.
A 'Manager' is able to manage all employees and support tickets in his team, including viewing the tickets of a specific employee.
An 'Admin' is able to manage all managers, employees, and tickets in all teams, as well as some other core functionality.
In addition, on some pages there will be some additional fields shown if the current user is an admin or manager. (E.g links to delete/flag things). These won't be shown to employees.
I want to create one 'Permissions' model which will handle the logic for:
Determining if a user can access the current page or not.
Determining whether a particular part of a page should be displayed or not. (E.g special links for editing/deleting to be shown to admins and managers only).
I need some recommendations/advice for designing this class, particularly what methods it should have in order to accomplish the 2nd requirement.
The way I have approached this problem when it has come up is to give each action that can be taken or piece of information that can be shown it's own Permission. Each User then has a collection of Permissions. From this, you can add other layers of structure to help manage the huge number of permissions that will exist, such as hierarchies or categories of permissions.
Once that is in place, you can either have the various parts ask the User if they have the needed permission(s), or you can have a PermissionManager take a User and a set of Permissions and determine if the given user has the needed Permissions. Either way will work fine, but which one you choose has an impact on dependencies and the architecture of your system.
The PermissionManager approach has the advantage that your application pieces don't need to depend on a User, so you could use a different PermissionManager that always returns False if no permissions is appropriate, or True if all permissions is appropriate.
For simple situations, this approach can be overkill, and it often seems like it is at first, but I've gone the route of using basic hierarchical or coarse-grained Roles and fond that virtually every system I've worked on quickly got too complicated for most vanilla, pre-built Roles-based permission systems.
My approach to this problem from database point of view would be to have a user table which holds the list of users, a role table for the list of roles, e.g.: employee, manager, admin; and permission table which stores all of the values of every action/feature available in the system and its permission for a specific role, e.g.: say for admin, the values for actions/features like create, edit, delete, view are all true. The relationships can be seen below whereas (N) ---- (N) is a many-to-many relationship.
Users (N) ------- (N) Roles (N) -------- (N) Permission
My impression is that you would require to make use of roles e.g. employee, Manager, and Admin. So a roles table with these would do. Then for the particular actions/permisions you would have to make use of branching logic i.e. for example for the employee you will have
if User.IsInRole("employee")
// insert logic to deal with customer support tickets
else if User.IsInRole("manager")
// insert logic to deal with manager responsibilities
and finally logic to deal with admin responsibilities
So you need both the users table and the roles table to achieve this.
Hope it helps