Autorisation via le contrôle d'accès

L'autorisation est le processus qui consiste à accorder l'accès aux différentes parties et ressources de l'application web aux utilisateurs. Une façon courante d'autoriser les utilisateurs est le contrôle d'accès, dans lequel l'administrateur du site définit quelles permissions doivent être accordées aux utilisateurs et aux autres entités afin d'accéder à quelles ressources.

L'autorisation ne doit pas être confondue avec l'authentification, qui est le processus de validation que l'utilisateur est bien celui qu'il prétend être, généralement accompli en fournissant des identifiants de compte. Une fois l'utilisateur authentifié, le processus d'autorisation doit encore être effectué à chaque requête, pour s'assurer que l'utilisateur a accès à la ressource demandée.

Lors de l'accès à l'application via GraphQL, nous devons valider si l'utilisateur a accès aux éléments demandés du schéma. La logique d'autorisation doit-elle être codée dans la couche GraphQL ?

La réponse est non. Comme la documentation sur graphql.org le précise, la logique d'autorisation appartient à la couche de logique métier, et c'est à partir de là qu'elle est accédée par GraphQL. Ainsi, l'application peut disposer d'une source unique de vérité pour l'autorisation (c'est-à-dire celle offerte par WordPress) :

Gato GraphQL respecte ce principe, en reflétant (et, sous le moteur, en déléguant à) le mécanisme d'autorisation fourni par WordPress.

​

Politiques de contrôle d'accès

Parmi les différentes politiques de contrôle d'accès que nous pouvons mettre en œuvre pour notre application, les deux plus populaires sont le contrôle d'accès basé sur les rôles (RBAC) et le contrôle d'accès basé sur les attributs (ABAC).

WordPress, et Gato GraphQL, prennent en charge ces deux approches.

Avec le contrôle d'accès basé sur les rôles, nous accordons des permissions en fonction des rôles, puis nous assignons les rôles aux utilisateurs. Par exemple, WordPress dispose d'un rôle administrator avec accès à toutes les ressources, et des rôles editor, author, contributor et subscriber avec des permissions restreintes à des degrés variés, comme la possibilité de créer et publier un article de blog, simplement le créer, ou simplement le lire.

Avec le contrôle d'accès basé sur les attributs, les permissions sont accordées en fonction de métadonnées pouvant être assignées à différentes entités, y compris les utilisateurs, les ressources et les conditions d'environnement (telles que l'heure de la journée ou l'adresse IP du visiteur). Par exemple dans WordPress, la capacité edit_others_posts est utilisée pour valider si l'utilisateur peut modifier les articles d'autres utilisateurs.

En termes généraux, l'ABAC est préférable au RBAC parce qu'il nous permet de configurer les permissions avec un contrôle fin, et la permission est sans équivoque dans son objectif.

Par exemple dans WordPress, le rôle editor possède la capacité edit_others_posts, mais nous pouvons souhaiter permettre à une personne avec le rôle author de modifier l'article d'un autre auteur, sans lui accorder l'ensemble des permissions accordées à un éditeur (comme supprimer également les articles d'autres auteurs). Ainsi, accorder la capacité edit_others_posts et vérifier cette condition est plus approprié que de vérifier le rôle editor.

​

Définir la visibilité

Lorsque l'utilisateur ne possède pas la permission d'accéder au champ demandé du schéma GraphQL, quelle doit être l'erreur retournée ?

Il y a deux possibilités, en conformité avec la visibilité souhaitée pour le schéma : publique ou privée.

Pour le schéma public, le schéma GraphQL exposé est le même pour tous les utilisateurs, et chaque champ décrit quelles permissions sont requises pour y accéder. Lors de la demande d'un champ inaccessible, le message d'erreur expliquera pourquoi l'accès n'est pas accordé à l'utilisateur.

Pour le schéma privé, le schéma GraphQL est personnalisé pour chaque utilisateur, et seuls les champs auxquels il peut accéder seront exposés. Lors de la demande d'un champ inaccessible, le message d'erreur indiquera que le champ n'existe pas.

​

Contrôle d'accès via l'interface utilisateur

Dans Gato GraphQL, les règles de contrôle d'accès sont injectées dans le schéma au moment de l'exécution, sous forme de configuration définie par l'utilisateur via des access control lists. Ainsi, la couche GraphQL reflètera immédiatement les changements de politique de contrôle d'accès, sans avoir besoin de mettre à jour du code ou de recompiler le schéma :

L'administrateur du site configure l'ACL en sélectionnant :

• Les champs à valider
• Une règle à valider, parmi :
  • l'utilisateur doit-il être connecté ?
  • l'utilisateur doit-il être déconnecté ?
  • l'utilisateur doit-il avoir un certain rôle ?
  • l'utilisateur doit-il avoir une certaine capacité ?
• La configuration spécifique à la règle :
  • quels rôles ?
  • quelles capacités ?
• La visibilité :
  • par défaut (c'est-à-dire la même assignée au schéma) ?
  • publique ?
  • privée ?