Exemple 3 : Contrôle d'accès multi-locataires pour RBAC et ABAC avec OPA et Rego

Pour améliorer l'exemple RBAC présenté dans la section précédente, vous pouvez ajouter des attributs aux utilisateurs. 

Cet exemple inclut les mêmes rôles que dans l'exemple précédent, mais ajoute l'attribut useraccount_lockout_flag. Il s'agit d'un attribut spécifique à l'utilisateur qui n'est associé à aucun rôle en particulier. Vous pouvez utiliser les mêmes données externes RBAC que celles que vous avez utilisées précédemment pour cet exemple : 

 {
    "roles": {
        "tenant_a": {
            "all_access_role": ["viewData", "updateData"]
        },
        "tenant_b": {
            "update_data_role": ["updateData"],
            "view_data_role": ["viewData"]
        }
    }
}

L'attribut account_lockout_flag utilisateur peut être transmis au service de données dans le cadre de la saisie d'une requête OPA /viewData/tenant_a pour l'utilisateur Bob :

 {
    "tenant_id": "tenant_a",
    "role": "all_access_role",
    "path": ["viewData", "tenant_a"],
    "method": "GET",
    "account_lockout_flag": "true"
}

La règle demandée pour la décision d'accès est similaire aux exemples précédents, mais inclut une ligne supplémentaire pour vérifier l'account_lockout_flagattribut :

default allowViewData = false
allowViewData = true {
    input.method == "GET"
    input.path = ["viewData", tenant_id]
    input.tenant_id == tenant_id
    role_permissions := data.roles[input.tenant_id][input.role][_]
    contains(role_permissions, "viewData")
    input.account_lockout_flag == "false"
}

Cette requête renvoie une décision d'autorisation defalse. Cela est dû au fait que account_lockout_flag attribute c'est true pour Bob et que la règle Rego allowViewData refuse l'accès bien que Bob ait le bon rôle et le bon locataire.