How It Works

In Casbin, un modello di controllo degli accessi è astratto in un file CONF basato sul metamodello PERM (Policy, Effect, Request, Matchers). Cambiare o aggiornare il meccanismo di autorizzazione per un progetto è semplice come modificare una configurazione. Puoi personalizzare il tuo modello di controllo degli accessi combinando i modelli disponibili. Ad esempio, puoi combinare ruoli RBAC e attributi ABAC all'interno di un singolo modello e condividere un insieme di regole di policy.

Il modello PERM è composto da quattro fondamenti: Policy, Effect, Request e Matchers. Questi fondamenti descrivono la relazione tra risorse e utenti.

Request

Definisce i parametri della richiesta. Una richiesta di base è un oggetto tupla, che richiede almeno un soggetto (entità a cui si accede), un oggetto (risorsa a cui si accede) e un'azione (metodo di accesso).

Ad esempio, una definizione di richiesta potrebbe essere simile a questa:

Questa definizione specifica i nomi dei parametri e l'ordine richiesto dalla funzione di corrispondenza del controllo di accesso.

Policy

Definisce il modello per la strategia di accesso. Specifica il nome e l'ordine dei campi nel documento della regola della Politica.

Ad esempio:

Nota: Se eft (risultato della politica) non è definito, il campo del risultato nel file della politica non verrà letto e il risultato della politica corrispondente sarà consentito di default.

Matcher

Definisce le regole di corrispondenza per la Richiesta e la Policy.

Ad esempio: m = r.sub == p.sub && r.act == p.act && r.obj == p.obj Il risultato della strategia verrà salvato in p.eft.

Effect

Esegue una combinazione logica di giudizio sui risultati di corrispondenza dei Matcher.

Ad esempio: e = some(where(p.eft == allow))

Questa affermazione significa che se il risultato della strategia di corrispondenza p.eft ha il risultato di (alcuni) allow, allora il risultato finale è vero.

Diamo un'occhiata a un altro esempio:

e = some(where (p.eft == allow)) && !some(where (p.eft == deny))

Il significato logico di questa combinazione di esempio è: se esiste una strategia che corrisponde al risultato di allow e nessuna strategia che corrisponde al risultato di deny, il risultato è true. In altre parole, è true quando tutte le strategie corrispondenti sono allow. Se c'è qualche deny, entrambe sono false (più semplicemente, quando allow e deny esistono contemporaneamente, deny ha la precedenza).

Il modello più basilare e semplice in Casbin è ACL. Il modello CONF per ACL è il seguente:

# Request definition
[request_definition]
r = sub, obj, act

# Policy definition
[policy_definition]
p = sub, obj, act

# Policy effect
[policy_effect]
e = some(where (p.eft == allow))

# Matchers
[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act

Un esempio di policy per il modello ACL è:

p, alice, data1, read
p, bob, data2, write

Ciò significa:

• alice può leggere data1
• bob può scrivere data2

Supportiamo anche la modalità multi-linea aggiungendo '' alla fine:

# Matchers
[matchers]
m = r.sub == p.sub && r.obj == p.obj \
  && r.act == p.act

Inoltre, se stai utilizzando ABAC, puoi provare l'operatore 'in' come mostrato nell'esempio seguente per l'edizione golang di Casbin (jCasbin e Node-Casbin non sono ancora supportati):

# Matchers
[matchers]
m = r.obj == p.obj && r.act == p.act || r.obj in ('data2', 'data3')

Ma DEVI assicurarti che la lunghezza dell'array sia MAGGIORE di 1, altrimenti causerà un panico.

Per ulteriori operatori, potresti dare un'occhiata a govaluate.