C'est quoi une commu ? Groupes et rôles

Une fois connecté à un service, vous n’êtes pas nécessairement le seul utilisateur du moment. Comment faire pour gérer correctement ce que vous pouvez faire sur le service avec ce que d’autres utilisateurs peuvent (ou pas) faire sur ce service ?

Le service implémente un contrôle d’accès. Le plus fréquemment, il implémente un contrôle d’accès de groupe ou de rôle. Pour un réseau social, il y a en plus le contrôle d’accès par relations.

Le contrôle d’accès de groupe (group based access control)

C’est la tribu.

Ce contrôle d’accès est un regroupement d’utilisateurs qui ont accès à un certain nombre de ressources.

Ce regroupement défini des permissions (des droits) sur l’usage des ressources. Les utilisateurs de ce groupe héritent chacun de ces permissions.

Le contrôle d’accès de rôle (role based access control)

C’est le chef de tribu, le shaman…

Ce contrôle d’accès définit des permissions (des droits) qui rassemblées toutes ensemble sont données à un utilisateur spécifique.

Généralement, il y a un rôle d’Administrateur qui a tous les droits. Tous les autres rôles sont consentis aux utilisateurs par cet Administrateur. Un utilisateur ne peut pas se donner lui-même un rôle.

Les rôles peuvent être organisés en hiérarchie. Le rôle au dessus englobe toutes les permissions du rôle au dessous et en possède d’autres.

La différence et la relation entre les deux

Quand on compare ces deux types de contrôle d’accès, il peut y avoir des difficultés à les distinguer. Suivant les systèmes, la distinction n’est pas forcément faite.

Mais pour clarifier les choses, je vais tenter d’opérer cette distinction.

Les groupes sont généralement utilisés pour classer les ressources et les utilisateurs. Ils gèrent l’identité. Tel utilisateur appartient à tel ou/et tel groupe.

Les rôles sont généralement utilisés pour gérer les permissions, les droits. Ils gèrent l’activité. Tel utilisateur peut faire ça car il a tel rôle.

Les groupes et les rôles sont liés car complémentaires. Le groupe sert à définir le domaine de compétences du rôle, c’est à dire les utilisateurs et les ressources sur lesquelles le rôle peut agir. Mais un rôle peut être présent sur plusieurs groupes.

Par exemple :

Facebook

Vous pouvez être membre du « groupe des admirateurs de la framboise » et aimer la « page des admirateurs de la mûre ». Du point de vue du contrôle d’accès vous êtes membre de deux groupes.

Au sein du « groupe des admirateurs de la framboise » vous êtes un membre et au sein de la « page des admirateurs de la mûre » vous êtes modérateur. Ce sont vos rôles.

Comme vous le voyez, vos rôles sont délimités par les groupes. Vous êtes modérateur de la « page des admirateurs de la mûre », pas d’autre chose. Mais, il peut y avoir un modérateur du « groupe des admirateurs de la framboise » qui a les mêmes permissions sur ce groupe que vous sur la page. Donc, le rôle peut être présent sur plusieurs groupes.

De même, l’appartenance au groupe vous donne des permissions par défaut. En tant que simple membre du « groupe des admirateurs de la framboise » vous avez accès aux publications de ce groupe. Vous n’y avez pas accès si vous n’êtes pas membre.

Un ordinateur

La séparation entre groupe et rôle est ténue (particulièrement sur UNIX). Mais, on peut définir l’ordinateur comme étant lui-même le groupe et les comptes utilisateurs sur cet ordinateur ont des rôles (généralement un est l’administrateur, rôle présent sur tous les ordinateurs).

MyCrypNet

Un groupe peut être défini :

• Le regroupement de tous les accès MyCrypNet d’un utilisateur ;
• Cet utilisateur ;
• Les autres utilisateurs à qui il a délégué des accès.

Deux rôles peuvent être définis :

• L’utilisateur qui est le propriétaire des accès MyCrypNet tient le rôle d’administrateur ;
• Les utilisateurs délégués forment un deuxième rôle (même si celui-ci peut être redéfini en terme de contrôle d’accès par aptitude).

Contrôle d’accès par relation (relation based access control)

Ce sont vos amis ou contacts sur les réseaux sociaux.

L’existence de la relation entre vous et un de vos « amis » donne des permissions à vous et cet « ami » sur la gestion des ressources de l’un et de l’autre.

La relation gère les permissions. Ces permissions peuvent être symétriques (l’« ami » a autant de droits que vous) ou asymétrique (l’« ami » a moins de permissions que vous, c’est dans ce cas plus une relation de « fan » ou hiérarchique).

Contrôle d’accès par aptitude (capability based access control)

Ce type de contrôle d’accès permet une gestion plus fine des permissions.

Les permissions sont attachées à une ressource (un objet) et non un groupe de ressources (comme dans les contrôles d’accès par groupe ou rôle). L’ensemble objet-permissions forme une aptitude.

Si un utilisateur possède l’aptitude correspondante, il peut accéder à l’objet avec les permissions définies.

Cela permet une gestion des permissions beaucoup plus fine car elle est faite ressource par ressource (objet par objet).

Ce contrôle d’accès est utilisé par Oauth2 (le mécanisme utilisé pour le social login) pour la gestion des permissions. Par exemple, quand vous utilisez le social login Facebook sur un site, Facebook vous prévient que le site voudrait accéder à votre email, votre liste d’amis ou autres.

C’est l’aptitude que vous déléguez ou non (ou en partie) au site sur la ressource Facebook (qui est dans ce cas votre profil).

Chez MyCrypNet, chaque accès MyCrypNet a un certain nombre de permissions associées créées par l’administrateur de l’accès MyCrypNet. L’administrateur délègue alors l’aptitude à un utilisateur. L’utilisateur peut donc gérer l’accès avec les permissions que l’administrateur a défini.

Il y a encore d’autres types de contrôle d’accès que j’évoquerai dans un futur article.