distribute:newslettersautorizzazione e l’API evento potrebbe avere un’autorizzazionepublish:events. Queste autorizzazioni potrebbero quindi essere raccolte in un ruolo chiamato Marketing Publisher e assegnate al VP dell’assistente Marketing.
Assegnazioni di ruolo sovrapposte
RBAC è un modello additivo, quindi se si hanno assegnazioni di ruolo sovrapposte, le autorizzazioni effettive sono l’unione delle assegnazioni di ruolo.,
Ad esempio, supponiamo che tu abbia un’API che fornisce dati per un’applicazione evento. Si crea un ruolo di Organizer e si assegnano le autorizzazioni che consentono di visualizzare, creare e modificare gli eventi. È inoltre possibile creare un ruolo di Registrant e assegnargli le autorizzazioni che consentono di visualizzare e registrare gli eventi. Tutti gli utenti con entrambi i ruoliOrganizer eRegistrant saranno in grado di visualizzare, creare, modificare e registrarsi per gli eventi.,
Role-based access control in Auth0
Attualmente, abbiamo due modi di attuazione role-based access control (RBAC), che è possibile utilizzare in sostituzione o in combinazione con le API interne di controllo di accesso di sistema:
-
Autorizzazione Core
-
Estensione di Autorizzazione
stiamo espandendo la nostra Autorizzazione Core set di funzionalità per abbinare la funzionalità dell’Estensione dell’Autorizzazione., La nostra nuova implementazione core RBAC migliora le prestazioni e la scalabilità e alla fine fornirà un sistema RBAC più flessibile rispetto all’estensione di autorizzazione.
Per ora, entrambi implementano le funzionalità chiave di RBAC e consentono di limitare gli ambiti personalizzati definiti per un’API a quelli che sono stati assegnati all’utente come autorizzazioni. Per un confronto, vedere Authorization Core vs. Authorization Extension.
Il set di funzionalità principale di autorizzazione e l’estensione di autorizzazione sono funzionalità completamente separate., Per gestire gruppi, ruoli o autorizzazioni, è necessario utilizzare la funzionalità in cui sono stati originariamente creati.
Sebbene il DAE (Delegated Administration Extension) e il set di funzionalità principale di autorizzazione siano funzionalità completamente separate, è possibile utilizzare il set di funzionalità principale di autorizzazione per creare e gestire i ruoli per il DAE se si utilizza una regola. Per ulteriori informazioni, vedere Casi d’uso di esempio: regole con autorizzazione.,
Estensione di RBAC
È possibile fornire un maggiore controllo utilizzando le regole per limitare l’accesso in base a una combinazione di attributi, come reparto utente, ora del giorno, posizione di accesso o qualsiasi altro attributo utente o API (ad esempio, nome utente, autorizzazione di sicurezza o nome API).
Per ulteriori informazioni sull’utilizzo di regole con criteri di autorizzazione, vedere Regole con criteri di autorizzazione.