Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Exemple 1 : ABAC de base avec OPA et Rego

Cette section décrit un scénario dans lequel l'OPA est utilisée pour prendre des décisions d'accès concernant les utilisateurs autorisés à accéder aux informations dans un microservice de paie fictif. Des extraits de code Rego sont fournis pour montrer comment vous pouvez utiliser Rego pour prendre des décisions de contrôle d'accès. Ces exemples ne sont ni exhaustifs ni une exploration complète des capacités de Rego et d'OPA. Pour un aperçu plus complet de Rego, nous vous recommandons de consulter la documentation Rego sur le site Web de l'OPA.

Exemple de règles OPA de base

Dans le schéma précédent, l'une des règles de contrôle d'accès appliquées par l'OPA pour le microservice Payroll est la suivante :

Les employés peuvent lire leur propre salaire.

Si Bob essaie d'accéder au microservice de paie pour voir son propre salaire, le microservice de paie peut rediriger l'appel d'API vers l' RESTful API OPA pour prendre une décision d'accès. Le service de paie demande à OPA une décision avec l'entrée JSON suivante :

{
    "user": "bob",
    "method": "GET",
    "path": ["getSalary", "bob"]
}

L'OPA sélectionne une ou plusieurs politiques en fonction de la requête. Dans ce cas, la politique suivante, écrite en Rego, évalue l'entrée JSON.

default allow = false
allow = true {
    input.method == "GET"
    input.path = ["getSalary", user]
    input.user == user
}

Cette politique refuse l'accès par défaut. Il évalue ensuite l'entrée de la requête en la liant à la variable input globale. L'opérateur point est utilisé avec cette variable pour accéder aux valeurs de la variable. La règle Rego allow renvoie la valeur true si les expressions de la règle sont également vraies. La règle Rego vérifie que l'methodentrée est égale à GET. Il vérifie ensuite que le premier élément de la liste path est bien présent getSalary avant d'affecter le deuxième élément de la liste à la variable. user Enfin, il vérifie que le chemin auquel on accède est /getSalary/bob en vérifiant que l'userenvoi de la demande correspond à la user variable. input.user La règle allow applique la logique if-then pour renvoyer une valeur booléenne, comme indiqué dans le résultat :

{
    "allow": true
}

Règle partielle utilisant des données externes

Pour démontrer des fonctionnalités OPA supplémentaires, vous pouvez ajouter des exigences à la règle d'accès que vous appliquez. Supposons que vous souhaitiez appliquer cette exigence de contrôle d'accès dans le contexte de l'illustration précédente : 

Les employés peuvent lire le salaire de toute personne relevant d'eux.

Dans cet exemple, l'OPA a accès à des données externes qui peuvent être importées pour aider à prendre une décision d'accès :

"managers": {
        "bob": ["dave", "john"],
        "carol": ["alice"]
}

Vous pouvez générer une réponse JSON arbitraire en créant une règle partielle dans OPA, qui renvoie un ensemble de valeurs au lieu d'une réponse fixe. Voici un exemple de règle partielle :

direct_report[user_ids] {
    user_ids = data.managers[input.user][_]
}

Cette règle renvoie un ensemble de tous les utilisateurs qui répondent à la valeur deinput.user, qui, dans ce cas, estbob. La [_] construction de la règle est utilisée pour itérer les valeurs de l'ensemble. Voici le résultat de la règle :

{
    "direct_report": [
      "dave",
      "john"
    ]
}

La récupération de ces informations peut aider à déterminer si un utilisateur est un subordonné direct d'un responsable. Pour certaines applications, il est préférable de renvoyer un JSON dynamique plutôt qu'une simple réponse booléenne.

Tout assembler

La dernière exigence d'accès est plus complexe que les deux premières car elle combine les conditions spécifiées dans les deux exigences :

Les employés peuvent lire leur propre salaire et celui de toute personne relevant d'eux.

Pour répondre à cette exigence, vous pouvez utiliser cette politique Rego :

default allow = false
 
allow = true {
    input.method == "GET"
    input.path = ["getSalary", user]
    input.user == user
}
 
allow = true {
    input.method == "GET"
    input.path = ["getSalary", user]
    managers := data.managers[input.user][_]
    contains(managers, user)
}

La première règle de la politique permet l'accès à tout utilisateur qui essaie de consulter ses propres informations salariales, comme indiqué précédemment. Le fait d'avoir deux règles portant le même nom fonctionne comme un opérateur logique dans Rego. allow La deuxième règle extrait la liste de tous les subordonnés directs associés à input.user (à partir des données du schéma précédent) et affecte cette liste à la managers variable. Enfin, la règle vérifie si l'utilisateur qui essaie de voir son salaire est un subordonné direct input.user en vérifiant que son nom est contenu dans la managers variable.

Les exemples de cette section sont très basiques et ne fournissent pas une exploration complète ou approfondie des capacités de Rego et OPA. Pour plus d'informations, consultez la documentation OPA, consultez le fichier GitHub README OPA et expérimentez dans le terrain de jeu Rego.