example - Control de acceso basado en roles(RBAC) vs. Control de acceso basado en reclamos(CBAC) en ASP.NET MVC
Creo que esta pregunta podría ser respondida desde la base de datos prospectiva. Si ha notado cómo las tablas involucradas en esta implantación encontrará la siguiente
- AspNetUsers: cada usuario tiene una fila con todos los atributos requeridos por todos los usuarios, como correo electrónico, dirección de teléfono, contraseña .....
- AspNetRoles; define diferentes roles según los requisitos de la aplicación, como GM, CTO, HRM, ADMIN, EMP. lo que cada rol define es según las necesidades de la aplicación.
- AspNetUserRoles: cada fila vincula AspNetUsers y AspNetRoles y establece un enlace efectivo entre un usuario y muchos roles.
- AspNetUserClaims: cada fila tiene clave para AspNetUsers y un tipo y valor. de manera efectiva agregue un atributo para cada usuario que podría agregarse / eliminarse en tiempo de ejecución.
El uso de estas tablas podría modificarse en un momento del tiempo de vida del usuario / la aplicación para que coincida con las necesidades específicas.
Considere la etapa inicial de "Purchasing Manager" (PM), podríamos tener tres enfoques
La aplicación rellena AspNetUserRoles con una fila para otorgar el derecho de ''PM'' para comprar. Para emitir una orden de compra con cualquier cantidad, el usuario solo necesita la función "PM".
La aplicación rellena AspNetUserRoles con una fila para otorgar el derecho de compra de ''PM'', y rellena AspNetUserClaims con un reclamo de TYPE ''Tipo de importe de compra'' y un valor de ''<1000'' para establecer el límite de importe. Para emitir un pedido de compra, el usuario debe tener ''PM'' y el importe del pedido debe ser menor que el valor de reclamación del tipo de reclamación ''Importe de compra''.
La solicitud rellena AspNetUserClaims con la reivindicación del tipo TYPE ''Purchasing Amount'' y el valor "<1000". Cualquier usuario puede emitir un pedido de compra, dado que el monto es menor que el valor del reclamo del tipo de reclamo ''Importe de compra'' para este usuario.
Como se pudo observar, la función basada en derechos rígidos que simplificaría la vida del usuario de la aplicación desde el punto de vista de la administración del sistema. sin embargo, limitará las capacidades del usuario desde el punto de vista de los requisitos del negocio. Por otro lado, los reclamos basados en derechos muy finos deben asignarse a cada usuario. el reclamo basado empujará también al negocio al límite, sin embargo, hará que la administración del sistema sea muy compleja.
El rol es solo un tipo de Reclamo. Así, puede haber muchos otros tipos de reclamaciones, por ejemplo, el nombre de usuario es uno de los tipos de reclamación
En términos más generales, debe considerar el control de acceso basado en atributos (ABAC). RBAC y ABAC son conceptos definidos por NIST, el Instituto Nacional de Estándares y Tecnología. CBAC, por otro lado, es un modelo impulsado por Microsoft que es muy similar a ABAC.
Leer más aquí:
- Página NIST de control de acceso basado en roles
- Página NIST de control de acceso basado en atributos
Es importante analizar primero para qué se requiere la autenticación antes de decidir qué método es el mejor. De la documentación de Microsoft a continuación, dice: "El sujeto no puede hacer un reclamo. Por ejemplo, puede tener una licencia de conducir expedida por una autoridad local de licencias de conducir. Su licencia de conducir tiene su fecha de nacimiento. En este caso el nombre de la reclamación sería DateOfBirth, el valor de la reclamación sería su fecha de nacimiento, por ejemplo, el 8 de junio de 1970. La autorización basada en reclamaciones, en su forma más simple, verifica el valor de un reclamo y permite el acceso a un recurso basado en ese valor. Por ejemplo, si desea acceder a un club nocturno, el proceso de autorización podría ser: 6 "El oficial de seguridad de la puerta evaluaría el valor de su declaración de nacimiento y si confían en el emisor ) antes de otorgarle acceso.
De este ejemplo podemos ver que acceder a un club nocturno con una Autorización basada en Reclamaciones es diferente al tipo de Autorización que requerirá el personal que trabaja en el club nocturno, en este caso el personal del club nocturno requerirá una Autorización basada en roles que no se requiere para los visitantes del club nocturno ya que los visitantes del club nocturno tienen un propósito común en el club nocturno, por lo tanto, en esta situación, una Autorización basada en reclamos es adecuada para los visitantes del club nocturno.
Autorización basada en roles https://docs.microsoft.com/en-us/aspnet/core/security/authorization/roles 14/10/2016 Cuando se crea una identidad, puede pertenecer a uno o más roles. Por ejemplo, Tracy puede pertenecer a las funciones de administrador y usuario, mientras que Scott solo puede pertenecer a la función de usuario. Cómo se crean y administran estos roles depende del almacén de respaldo del proceso de autorización. Los roles se exponen al desarrollador a través del método IsInRole en la clase ClaimsPrincipal.
Autorización basada en reclamos https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims 10/14/2016 Cuando se crea una identidad, se le pueden asignar uno o más reclamos emitidos por un tercero confiable . Un reclamo es un par de valor nominal que representa lo que es el sujeto, no lo que el sujeto puede hacer. Por ejemplo, puede tener una licencia de conducir emitida por una autoridad local de licencias de conducir. Su licencia de conducir tiene su fecha de nacimiento. En este caso, el nombre de la reclamación sería DateOfBirth, el valor de la reclamación sería su fecha de nacimiento, por ejemplo, el 8 de junio de 1970 y el emisor sería la autoridad de la licencia de conducir. La autorización basada en reclamos, en su forma más simple, verifica el valor de un reclamo y permite el acceso a un recurso en función de ese valor. Por ejemplo, si desea acceder a un club nocturno, el proceso de autorización podría ser:
El oficial de seguridad de la puerta evaluaría el valor de su reclamo de fecha de nacimiento y si confían en el emisor (la autoridad de la licencia de conducir) antes de otorgarle acceso.
Una identidad puede contener múltiples reclamos con múltiples valores y puede contener múltiples reclamos del mismo tipo.
La respuesta aceptada parece posicionar Roles como un objeto contundente y Claims como una herramienta flexible, pero por lo demás los hace parecer casi idénticos. Desafortunadamente, este posicionamiento perjudica el concepto de reclamos y puede reflejar fundamentalmente un ligero malentendido de su propósito.
Los roles existen y tienen sentido solo dentro de un alcance implícito. En general, se trata de una aplicación o un alcance organizacional (es decir, Rol = Administrador). Las reclamaciones, por otro lado, pueden ser ''hechas'' por cualquier persona. Por ejemplo, la autenticación de Google puede producir reclamos, incluido el "correo electrónico" de un usuario, adjuntando ese correo electrónico a una identidad. Google hace el reclamo, la aplicación elige si entiende y acepta ese reclamo. La aplicación en sí misma podría adjuntar posteriormente un reclamo llamado "método de autenticación" (como ASP.NET MVC Core Identity lo hace) con un valor de "Google". Cada reclamo incluye un alcance para que sea posible identificar si un reclamo tiene un significado externo, local o ambos (o más detallado según sea necesario).
Los puntos clave son que todos los reclamos están adjuntos explícitamente a una identidad e incluyen un alcance explícito. Esos reclamos pueden, por supuesto, ser utilizados para autorización, y ASP.NET MVC brinda soporte para eso a través del atributo Autorizar, pero ese no es el único o necesariamente el principal objetivo de los Reclamos. Ciertamente, no lo distingue de Roles, que se puede utilizar exactamente de la misma manera para la autorización con ámbito local.
Por lo tanto, uno puede optar por usar Roles o Reclamaciones, o ambos a los fines de la autorización, y es probable que no encuentre una ventaja o desventaja inherente a ninguno de ellos, siempre que dichos Roles y Reclamaciones tengan un alcance local. Pero si, por ejemplo, la autorización depende de reclamos de identidad externa, entonces Roles será inadecuada. Debería aceptar el reclamo externo y traducirlo a un rol de ámbito local. No hay necesariamente nada de malo en eso, pero introduce una capa de indirección y descarta el contexto.
Lo fundamental entre RBAC y CBAC es que:
RBAC : un usuario debe ser asignado a un rol para ser autorizado a realizar una acción.
CBAC : el usuario debe tener un reclamo con el valor correcto, según lo esperado por la aplicación, para ser autorizado. El control de acceso basado en notificaciones es elegante de escribir y más fácil de mantener.
Además de que los reclamos son emitidos a la aplicación por un emisor autorizar servicios (Token de servicio de seguridad STS) que es de confianza por su aplicación (Parte que confía)
No estoy totalmente de acuerdo con la respuesta de Emran
[Authorize(Roles="Sale")]
Es ingenuo
La pregunta es cómo
[Authorize(Roles="CustomerCreator")]
es diferente de
[ClaimAuthorize(Permission="CanCreateCustomer")]
Si ambos son igualmente buenos, ¿por qué necesitamos reclamo?
Creo porque
El concepto de reclamos es más genérico en comparación con el rol
En el contexto del ejemplo anterior podemos decir que "CustomerCreator" es un reclamo de tipo "role" proporcionado por "Asp.NETroleProvider"
Ejemplos adicionales de reclamos.
"AAA" es un reclamo del tipo "MYExamSite.Score" proporcionado por "MYExamSite.com"
"Oro" es un reclamo de tipo "MYGYM.Membershiptype" proporcionado por "MYGYMApp"
También es posible administrar roles de una manera de reclamos.
En lugar de crear roles de autorización que reflejen un rol empresarial, cree roles que reflejen roles de acción, por ejemplo, CreateCustomer, EditCustomer, DeleteCustomer. Anote los métodos según sea necesario.
No es una cuestión simple asignar personas a un conjunto de roles de acción, especialmente a medida que la lista de roles aumenta. Por lo tanto, deberá administrar los roles comerciales en un nivel más bajo de granularidad (por ejemplo, ventas, marketing) y asignar el rol comercial a las funciones de acción requeridas. Es decir, agregue un usuario a una función comercial y los asigna a los roles necesarios (acción) en la tabla de autorización existente.
Incluso puede anular la función comercial y agregar a una persona a un rol de acción directamente.
Debido a que construye sobre lo que ya funciona, no deshace el proceso de Autorización existente. Solo necesita unas pocas tablas más para implementar este enfoque
Trataré de mostrar cómo puede beneficiarse del Control de acceso basado en notificaciones en un contexto ASP.NET MVC.
Cuando usa la autenticación basada en roles, si tiene una acción para crear clientes y desea que las personas que están en el rol de ''Venta'' puedan hacer eso, entonces escriba un código como este:
[Authorize(Roles="Sale")]
public ActionResult CreateCustomer()
{
return View();
}
Más tarde, se dio cuenta de que, en ocasiones, las personas del rol ''Marketing'' deberían poder crear un Cliente. Luego, actualizas tu método de Acción de esa manera
[Authorize(Roles = "Sale", "Marketing")]
public ActionResult CreateCustomer()
{
return View();
}
Ahora, se dio cuenta de que algunas personas de marketing no deben poder crear clientes, pero no es posible asignar un rol diferente para las personas que están en Marketing. Por lo tanto, está obligado a permitir que todas las personas de marketing creen Clientes.
detectó otro problema, cada vez que decida que se debe permitir a las personas de Marketing crear clientes, debe actualizar todos los atributos de MVC Action methods Authorize, compilar su aplicación, probarla e implementarla. Algunos días después, decidió no comercializar, pero se le debería permitir a otra función que realice la tarea, de modo que busque en su base de código y elimine todo el atributo ''Comercializar'' del Autorizar y agregue su nuevo nombre de función en el atributo Autorizar ... No es solución saludable. En ese punto, se daría cuenta de la necesidad de un Control de acceso basado en permisos.
El control de acceso basado en permisos es una forma de asignar varios permisos a varios usuarios y verificar si un usuario tiene permiso para ejecutar una acción desde el código en tiempo de ejecución. Después de asignar varios permisos a varios usuarios, se da cuenta de que debe permitir que algunos usuarios ejecuten código si el usuario tiene alguna propiedad como "Usuario de Facebook", "Usuario de larga duración", etc. Déjeme dar un ejemplo. Supongamos que desea permitir el acceso a una página específica si el usuario ha iniciado sesión con Facebook. Ahora, ¿crearías un permiso ''Facebook'' para ese usuario? No, ''Facebook'' no suena como un permiso. Lo hace ? Más bien suena como un reclamo. ¡Al mismo tiempo, los Permisos pueden sonar como Reclamo también! Por lo tanto, es mejor verificar las reclamaciones y permitir el acceso.
Ahora, volvamos al ejemplo concreto de control de acceso basado en reclamos.
Puede definir un conjunto de declaraciones como esta:
"CanCreateCustomer", "CanDeleteCustomer", "CanEditCustomer" .. etc.
Ahora puedes decorar tu Método de Acción de esta manera:
[ClaimAuthorize(Permission="CanCreateCustomer")]
public ActionResult CreateCustomer()
{
return View();
}
(Tenga en cuenta que [ClaimAuthorize (Permission = "CanCreateCustomer")] puede que no esté integrado en la biblioteca de clase MVC, solo estoy mostrando como ejemplo, puede usar alguna biblioteca de clases que tenga dicha definición de clase Attribute)
Ahora puede ver que el método de acción CreateCustomer siempre necesitará el permiso ''CanCreateCustomer'' y nunca cambiará o apenas cambiará. Entonces, en su base de datos, usted crea una tabla de permisos (reclamos) y una relación de permiso de usuario. Desde su panel de administración, puede establecer el permiso (reclamo) para cada usuario que puede hacer qué. Puede asignar el permiso (reclamo) ''CanCreateCustomer'' a quien quiera y solo el usuario permitido podrá crear un cliente y el usuario permitido solo podrá crear clientes y nada más (a menos que asigne otros permisos al mismo usuario).
Este modelo de seguridad le ofrece la práctica del código limpio. Además, cuando escribe su Método de Acción, no tiene que pensar en quién puede usar este método, sino que siempre puede estar seguro de que quien utilice este método tendrá el permiso (reclamo) adecuado otorgado por el Administrador. Luego, el administrador puede decidir quién podrá hacer qué. No eres un desarrollador. Eso es cómo su lógica de negocio está separada de la lógica de Seguridad.
Cada vez que alguien inicia sesión, su aplicación verificará todos los permisos disponibles para ese usuario y ese conjunto de permisos (reclamo) estará disponible como propiedades adicionales del usuario actualmente conectado (generalmente el conjunto de notificaciones se almacena como cookie para el usuario conectado). por lo que no tiene que comprobar el permiso establecido todo el tiempo desde la base de datos. En resumidas cuentas, obtendrá un mayor control de su lógica de seguridad en su aplicación si aplica el acceso basado en el reclamo en lugar del acceso basado en roles. De hecho, un Rol puede considerarse también un Reclamo.
Si su aplicación es una aplicación muy pequeña en la que solo habría dos funciones: Cliente y Administrador, y no hay posibilidad de que el Cliente pueda hacer otra cosa que no sea lo que deben hacer en su aplicación, entonces, tal vez, basado en roles. El control de acceso servirá para el propósito, pero a medida que su aplicación crezca, comenzará a sentir la necesidad de control de acceso basado en reclamos en algún momento.