¿Autenticación basada en rol y en identidad? ¿Cuál es la diferencia?

Los roles tienden a asociarse a identidades, ya que no autenticas un rol, pero sí autenticas una identidad. Puede autorizar una identidad y puede autorizar un rol. Creo que podría haber alguna confusión aquí.

Un rol es una extensión de la identidad, y generalmente funciona de tal manera que (por ejemplo) el usuario 'Admin' tiene el rol de 'Administrador'. Un usuario con el rol 'Administrador' tiene diferentes derechos que un usuario con el rol 'Usuario estándar'. Las identidades generalmente tienen la capacidad de tener múltiples roles, por lo que un usuario administrativo puede tener el rol 'Administrador' y el rol 'Usuario estándar' y, por lo tanto, tiene los derechos vinculados a ambos roles.

Las contraseñas generalmente están vinculadas a identidades, por lo que está autentificando la contraseña con una identidad. Si no hay un campo de nombre de usuario, el sistema backend que realiza la validación de la contraseña probablemente tenga una búsqueda que compare todas las contraseñas (o probablemente busque el texto sin formato de la contraseña) con sus usuarios asociados.

Esto supone que se están usando roles aún. Si no se utilizan roles, la autorización es simplemente contra la propia identidad; p.ej. si el usuario == 'administrador' permite cosas de administrador.

"Autenticación basada en roles" no es un término de la industria. Tal vez lo confundió con control de acceso basado en roles , que es un método para controlar el acceso a funciones basadas en usuarios. "rol", en lugar de su identidad.

Por ejemplo, un sistema de blog puede definir un rol de "Autor" y un rol de "Editor". Un "Autor" podría tener permiso para crear nuevas historias, pero no para publicarlas. Un Editor tendría permiso para revisar, modificar y publicar las historias existentes.

Cualquier usuario dado podría "pertenecer" a uno o más roles de forma permanente, o se le podría otorgar temporalmente una autorización de rol durante una sesión determinada.

Pero de manera crítica, los permisos y las capacidades nunca se asignan directamente a usuarios , sino que siempre se asignan a roles . Los usuarios obtienen ese permiso indirectamente al asumir un rol determinado. Del mismo modo, las credenciales de una persona están asociadas con la cuenta de usuario y no la función . Así:

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

El sistema que está describiendo, con la identidad y el acceso determinados solo por contraseña, no es un sistema basado en roles, sino un sistema basado en usuarios sin nombres de usuario. Suena como una idea particularmente mala.

Yo diría que hay una confusión de términos aquí.

En su mayor parte, esto no es tanto la autenticación como la autorización. Específicamente, tiene un escenario en el que los permisos se basan en roles (un conjunto de permisos de administrador frente a un conjunto de permisos de usuario) que está protegido por un mecanismo de autenticación de desafío / respuesta. Debido a que la verificación es de una contraseña compartida, no está autentificando a las personas, por lo que no existe un concepto de identidad o rol de membresía, por lo menos no un concepto implementado en este sistema en particular.

La autenticación basada en identidad es absolutamente un "término".

El contexto aquí es con HSM (módulos de seguridad HW) para operaciones PKI. En la autenticación basada en rol tiene una "contraseña" o tarjeta inteligente, etc. que autentica el rol (como crypto officer, usuario, etc.). La autenticación basada en identidad lo lleva un paso más allá y asigna roles a usuarios individuales. P.ej. puede tener varios usuarios individuales que obtienen el rol de "usuario". La mayoría de las operaciones de HSM basadas en identidad también implican la autenticación M de N. p.ej. hay 5 usuarios en total, y 3 tienen que estar presentes para realizar una operación. p.ej. M (3) de N (5).