Beispiel 3: Mehrmandantenfähige Zugriffskontrolle für RBAC und ABAC mit OPA und Rego

Um das RBAC-Beispiel aus dem vorherigen Abschnitt zu erweitern, können Sie Benutzern Attribute hinzufügen. 

Dieses Beispiel enthält dieselben Rollen wie im vorherigen Beispiel, fügt jedoch das Benutzerattribut hinzu. account_lockout_flag Dies ist ein benutzerspezifisches Attribut, das keiner bestimmten Rolle zugeordnet ist. Sie können dieselben externen RBAC-Daten verwenden, die Sie zuvor für dieses Beispiel verwendet haben: 

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

Das account_lockout_flag Benutzerattribut kann als Teil der Eingabe für eine OPA-Abfrage /viewData/tenant_a für den Benutzer Bob an den Datendienst übergeben werden:

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

Die Regel, die für die Zugriffsentscheidung abgefragt wird, ähnelt den vorherigen Beispielen, enthält jedoch eine zusätzliche Zeile, um nach dem Attribut zu suchen: account_lockout_flag

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"
}

Diese Abfrage gibt eine Autorisierungsentscheidung von zurück. false Das liegt daran, dass die account_lockout_flag attribute true für Bob gilt und die Rego-Regel den Zugriff allowViewData verweigert, obwohl Bob die richtige Rolle und den richtigen Mandanten hat.