What is a commu ? Groups and roles

Once connected to a service, you’re not necessarily the only user at that moment. How can you properly manage what you can do on the service versus what other users can (or cannot) do?

Note: This post was translated from french with the help of AI. The original post was written with the knowledge of a younger me.

The service implements access control. Most commonly, it uses group-based or role-based access control. For a social network, there is also relationship-based access control.

Group-Based Access Control

This is the tribe.

This type of access control is a grouping of users who have access to a certain set of resources.

This grouping defines permissions (rights) for using these resources. Each user in this group inherits those permissions.

Role-Based Access Control

This is the tribal chief or shaman…

This type of access control defines a set of permissions (rights) that are collectively assigned to a specific user.

Typically, there’s an Administrator role that has all permissions. Other roles are granted to users by this Administrator. A user cannot assign a role to themselves.

Roles can also be hierarchical. A higher-level role includes all permissions of a lower-level role plus additional ones.

Difference and Relationship Between the Two

When comparing these two types of access control, it can be tricky to distinguish them. Depending on the system, the distinction may not even be explicitly made.

To clarify, here is the distinction:

• Groups are generally used to classify resources and users. They manage identity. For example: a user belongs to one or more groups.
• Roles are generally used to manage permissions and rights. They manage activity. For example: a user can perform a certain action because they have a specific role.

Groups and roles are linked because they complement each other: A group defines the scope of a role. That is, the users and resources on which the role can act. But a role can exist across multiple groups.

Example: Facebook

You might be a member of the “Raspberry Fans Group” and like the “Blackberry Fans Page.” From an access control perspective, you belong to two groups.

Within the “Raspberry Fans Group” you’re a member, and within the “Blackberry Fans Page” you’re a moderator. These are your roles.

As you can see, your roles are bounded by groups. You are a moderator of the “Blackberry Fans Page” only, not elsewhere. But there might be a moderator of the “Raspberry Fans Group” who has the same permissions there as you have on the page. Thus, a role can be present in multiple groups.

Also, group membership provides default permissions. As a regular member of the “Raspberry Fans Group”, you have access to that group’s posts. You wouldn’t have this access if you weren’t a member.

Example: A Computer

The distinction between group and role is subtle (especially on UNIX). But you can think of the computer itself as the group, and the user accounts on that computer have roles (usually one is the administrator—a role that exists on all computers).

Relationship-Based Access Control

This refers to your friends or contacts on social networks.

The existence of a relationship between you and a friend grants permissions to both of you over each other’s resources.

The relationship manages permissions. These can be symmetric (the friend has the same rights as you) or asymmetric (the friend has fewer permissions—this is closer to a “fan” or hierarchical relationship).

Capability-Based Access Control

This type of access control allows for fine-grained permission management.

Permissions are attached to a specific resource (object) rather than a group of resources (as in group- or role-based control). The object-permission pair forms a capability.

If a user possesses the corresponding capability, they can access that object with the defined permissions.

This allows for much more precise permission management since it’s handled resource by resource.

This control type is used by OAuth2 (the mechanism used for social login) to manage permissions. For example, when you use Facebook social login on a website, Facebook tells you that the site wants to access your email, your friends list, or other data.

This is the capability you delegate (fully or partially) to the site over the Facebook resource (which in this case is your profile).