Esempio 3: controllo degli accessi multi-tenant per RBAC e ABAC con OPA e Rego

Per migliorare l'esempio RBAC nella sezione precedente, è possibile aggiungere attributi agli utenti. 

Questo esempio include gli stessi ruoli dell'esempio precedente, ma aggiunge l'attributo user. account_lockout_flag Si tratta di un attributo specifico dell'utente che non è associato a nessun ruolo particolare. È possibile utilizzare gli stessi dati esterni RBAC utilizzati in precedenza per questo esempio: 

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

L'attributo account_lockout_flag user può essere passato al servizio Data come parte dell'input di una query OPA /viewData/tenant_a per l'utente Bob:

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

La regola richiesta per la decisione di accesso è simile agli esempi precedenti, ma include una riga aggiuntiva per verificare l'attributo: 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"
}

Questa query restituisce una decisione di autorizzazione di. false Questo perché account_lockout_flag attribute è true per Bob e la regola Rego allowViewData nega l'accesso sebbene Bob abbia il ruolo e l'inquilino corretti.