Ya se han formulado muchas preguntas sobre la autenticación basada en notificaciones y las diferencias con otros enfoques: Basado en roles vs Basado en reclamos Explicar la autenticación basada en reclamaciones Ahora, mi respuesta favorita es una dada en stackoverflow: Uso de autenticación basada en notificaciones .
Sin embargo, después de leerlos, mi pregunta no se resuelve. La pregunta que tengo es doble:
- ¿Hay alguna diferencia entre reclamaciones y atributos (ABAC)?
- Si podemos considerar que un "rol" es un reclamo, ¿cuál es la ventaja particular de la autorización basada en reclamos sobre la autorización basada en rol? ( nota: aquí utilizo la autorización en lugar de la autenticación, ya que creo que no se trata realmente de la autenticación ).
Para profundizar más en mi pregunta, daré tres ejemplos de cómo veo la autorización basada en notificaciones, basada en roles y en atributos. Descargo de responsabilidad: no estoy seguro de si estos ejemplos son correctos, son solo una parte de mi pregunta.
Ejemplo basado en notificaciones
He leído a través de un interesante blogpost en el que se explica cómo podríamos utilizar la autenticación basada en notificaciones en MVC / Web API. Parece que (en ese blogpost) un método está asegurado (autorizado) mirando las reclamaciones que están asociadas con el usuario que está tratando de acceder al método. Si ese usuario tiene un reclamo para 'ver' 'direcciones de calle', entonces está autorizado para ver esos datos.
[ClaimsAuthorize("Read", "SomeData")]
public string Get()
{
return “somedata”;
}
Ahora, la creación de las reclamaciones se separa en otro lugar, lo que realmente no se especifica en ese blogpost. Supongo que el método oculto verifica si ese usuario, con ese rol determinado, tiene permiso para ver las direcciones de la calle. Ahora, ¿cuál es la diferencia con la autorización basada en roles?
Ejemplo basado en roles
La diferencia no está clara para mí, comparémosla con la antigua autorización basada en roles. Una vez más puedo definir un atributo para cada método, que restringe la ejecución de ese método a ciertos roles. El método 'ver streetaddresses' está restringido, por ejemplo, a los usuarios con el rol 'admin'. Entonces, en lugar de verificar el rol en el método separado, lo comprobamos aquí. ¿O me estoy perdiendo algo aquí?
[RoleAuthorize('admin')]
public string Get()
{
return “somedata”;
}
Ejemplo basado en atributos
Veo la ventaja de un control de autorización más granular. Pero implementaría algo como esto, para definir que solo un usuario con el rol de administrador puede acceder a 'somedata' durante las horas de trabajo, y solo si ese usuario administrador tiene los ojos azules:
[AttributeAuthorize('role=admin;time=09-17;eyecolor=blue')]
public string Get()
{
return “somedata”;
}
Este último ejemplo realmente me parece ventajoso, pero no estoy seguro de si es o no el mismo que mi primer ejemplo, que es una autorización basada en reclamaciones.
Para finalizar, apareció una última pregunta:
- Esto significa que las reclamaciones SON diferentes de los atributos, ya que los atributos se usan para definir qué derechos tiene un usuario, mientras que las reclamaciones son estos derechos.