Il ruolo rispetto all'autenticazione basata sull'identità? Qual è la differenza?

I ruoli tendono ad essere associati alle identità, poiché non si autentica un ruolo, ma si autentica un'identità. Puoi autorizzare un'identità e puoi autorizzare un ruolo. Credo che potrebbe esserci qualche confusione qui.

Un ruolo è un'estensione dell'identità e di solito funziona in modo tale che (ad esempio) l'utente "Amministratore" abbia il ruolo di "Amministratore". Un utente con il ruolo "Amministratore" ha diversi diritti rispetto a un utente con il ruolo "Utente standard". Le identità generalmente hanno la capacità di avere più ruoli, quindi un utente amministrativo potrebbe avere il ruolo "Amministratore" e il ruolo "Utente standard" e quindi ha i diritti legati a entrambi i ruoli.

Le password sono generalmente legate alle identità, quindi stai autenticando la password con un'identità. Se non esiste un campo nome utente, il sistema di back-end che esegue la convalida della password probabilmente ha una ricerca che confronta tutte le password (o più probabilmente cerca il testo in chiaro della password) agli utenti associati.

Ciò presuppone che i ruoli vengano persino utilizzati. Se non vengono utilizzati ruoli, l'autorizzazione è semplicemente contro l'identità stessa; per esempio. se l'utente == 'amministratore' permette cose amministrative.

"Autenticazione basata sul ruolo" non è un termine del settore. Forse lo hai confuso con Controllo degli accessi basato sui ruoli , che è un metodo per controllare l'accesso alle funzioni in base agli utenti "ruolo", piuttosto che la sua identità.

Ad esempio, un sistema di blog potrebbe definire un ruolo "Autore" e un ruolo "Editor". Un "Autore" potrebbe avere il permesso di creare nuove storie, ma non di pubblicarle. Un redattore avrebbe il permesso di rivedere e modificare e pubblicare storie esistenti.

Ogni dato utente potrebbe "appartenere" a uno o più ruoli su base permanente, o potrebbe essere temporaneamente concesso l'autorizzazione del ruolo durante una determinata sessione.

Ma in modo critico, le autorizzazioni e le funzionalità non vengono mai assegnate direttamente a utenti , ma invece sono sempre assegnate a ruoli . Gli utenti ottengono questa autorizzazione indirettamente assumendo un determinato ruolo. Allo stesso modo, le credenziali di una persona sono associate con account utente e non il ruolo . In questo modo:

+-------+    +------+    +------+    +------------+
| human |===>| User |===>| Role |===>| permission |
+-------+    +------+    +------+    +------------+

Il sistema che stai descrivendo, con identità e accesso determinati solo da password, non è un sistema basato sui ruoli, ma semplicemente un sistema basato sugli utenti senza nomi utente. Sembra un'idea particolarmente negativa.

Direi che c'è una confusione di termini qui.

Per la maggior parte questo non è tanto l'autenticazione quanto l'autorizzazione. Nello specifico, si dispone di uno scenario in cui le autorizzazioni sono basate sui ruoli (un set di autorizzazioni di admin rispetto a un set di autorizzazioni utente) protetto da un meccanismo di autenticazione challenge / response. Poiché la verifica è di una password condivisa, non stai autenticando le persone, quindi non esiste un concetto di identità o di appartenenza ai ruoli, almeno non un concetto implementato in questo particolare sistema.

L'autenticazione basata sull'identità è assolutamente un "termine".

Il contesto qui è con HSM (HW Security Modules) per le operazioni PKI. Nell'autenticazione basata sul ruolo si ha una "password" o una smartcard, ecc. Che autentica il ruolo (come crypto officer, utente, ecc.). L'autenticazione basata sull'identità fa un ulteriore passo avanti e assegna ruoli ai singoli utenti. Per esempio. puoi avere più utenti singoli che ottengono il ruolo di "utente". La maggior parte delle operazioni HSM basate sull'identità coinvolgono anche l'autenticazione M of N. per esempio. ci sono 5 utenti totali e 3 devono essere presenti per eseguire un'operazione. per esempio. M (3) di N (5).