RBAC

Definizione del Ruolo

La [role_definition] viene utilizzata per definire le relazioni di ereditarietà dei ruoli RBAC. Casbin supporta più istanze di sistemi RBAC, dove gli utenti possono avere ruoli e le loro relazioni di ereditarietà, e le risorse possono avere ruoli e le loro relazioni di ereditarietà anche. Questi due sistemi RBAC non interferiranno l'uno con l'altro.

Questa sezione è opzionale. Se non utilizzi i ruoli RBAC nel modello, ometti questa sezione.

[role_definition]
g = _, _
g2 = _, _

La definizione di ruolo sopra mostra che g è un sistema RBAC e g2 è un altro sistema RBAC. _,_ significa che ci sono due parti coinvolte in una relazione di ereditarietà. Nel caso più comune, di solito utilizzi g da solo se hai bisogno solo di ruoli per gli utenti. Puoi anche utilizzare sia g che g2 quando hai bisogno di ruoli (o gruppi) sia per utenti che per risorse. Per favore, consulta rbac_model.conf e rbac_model_with_resource_roles.conf per esempi.

Casbin memorizza il mapping effettivo utente-ruolo (o mapping risorsa-ruolo se stai utilizzando ruoli su risorse) nella policy. Per esempio:

p, data2_admin, data2, read
g, alice, data2_admin

Significa che alice eredita/è membro del ruolo data2_admin. Qui, alice può essere un utente, una risorsa o un ruolo. Casbin riconosce solo una stringa.

Quindi, in un matcher, dovresti controllare il ruolo come mostrato di seguito:

[matchers]
m = g(r.sub, p.sub) && r.obj == p.obj && r.act == p.act

Significa che il sub nella richiesta deve avere il ruolo sub nella policy.

nota

Casbin memorizza solo il mapping utente-ruolo.
Casbin non verifica se un utente è un utente valido o un ruolo è un ruolo valido. Questo dovrebbe essere gestito dall'autenticazione.
Non utilizzare lo stesso nome per un utente e un ruolo all'interno di un sistema RBAC, perché Casbin riconosce utenti e ruoli come stringhe e non c'è modo per Casbin di sapere se stai specificando l'utente alice o il ruolo alice. Puoi risolverlo semplicemente usando role_alice.
Se A ha il ruolo B e B ha il ruolo C, allora A ha il ruolo C. Questa transitività è infinita per ora.

Convenzione del Nome del Token

Convenzionalmente, il nome del token del soggetto nella definizione della politica è sub e viene posizionato all'inizio. Ora, Golang Casbin supporta nomi e posizioni personalizzati per i token. Se il nome del token del soggetto è sub, il token del soggetto può essere posizionato in un luogo arbitrario senza bisogno di azioni aggiuntive. Se il nome del token del soggetto non è sub, e.SetFieldIndex() per constant.SubjectIndex dovrebbe essere chiamato dopo l'inizializzazione dell'enforcer, indipendentemente dalla sua posizione.

# `subject` here is for sub
[policy_definition]
p =  obj, act, subject

e.SetFieldIndex("p", constant.SubjectIndex, 2) // index starts from 0
ok, err := e.DeleteUser("alice") // without SetFieldIndex, it will raise an error

Gerarchia dei Ruoli

Casbin supporta la funzionalità di gerarchia dei ruoli di RBAC1, il che significa che se alice ha role1, e role1 ha role2, allora alice avrà anche role2 e erediterà i suoi permessi.

Qui, abbiamo un concetto chiamato livello di gerarchia. Quindi, in questo esempio, il livello di gerarchia è 2. Per il gestore dei ruoli integrato in Casbin, puoi specificare il livello massimo di gerarchia. Il valore predefinito è 10. Ciò significa che un utente finale come alice può ereditare solo 10 livelli di ruoli.

// NewRoleManager is the constructor for creating an instance of the
// default RoleManager implementation.
func NewRoleManager(maxHierarchyLevel int) rbac.RoleManager {
    rm := RoleManager{}
    rm.allRoles = &sync.Map{}
    rm.maxHierarchyLevel = maxHierarchyLevel
    rm.hasPattern = false

    return &rm
}

Come distinguere un ruolo da un utente?

Casbin non distingue tra ruoli e utenti nel suo RBAC. Entrambi sono trattati come stringhe. Se utilizzi solo un RBAC a livello singolo (dove un ruolo non sarà mai membro di un altro ruolo), puoi usare e.GetAllSubjects() per ottenere tutti gli utenti e e.GetAllRoles() per ottenere tutti i ruoli. Elencheranno tutti u e tutti r, rispettivamente, in tutte le regole g, u, r.

Ma se stai utilizzando un RBAC a più livelli (con gerarchia dei ruoli) e la tua applicazione non registra se un nome (stringa) è un utente o un ruolo, o hai un utente e un ruolo con lo stesso nome, puoi aggiungere un prefisso al ruolo come role::admin prima di passarlo a Casbin. In questo modo, saprai se si tratta di un ruolo controllando questo prefisso.

Come interrogare ruoli o permessi impliciti?

Quando un utente eredita un ruolo o un permesso attraverso la gerarchia RBAC invece di essere assegnato direttamente in una regola di politica, chiamiamo questo tipo di assegnazione "implicita". Per interrogare tali relazioni implicite, è necessario utilizzare queste due API: GetImplicitRolesForUser() e GetImplicitPermissionsForUser() invece di GetRolesForUser() e GetPermissionsForUser(). Per maggiori dettagli, si prega di vedere questo problema GitHub.