Control de acceso basado en roles (RBAC) versus control de acceso basado en reclamos (CBAC) en ASP.NET MVC

¿Cuáles son los principales beneficios de usar CBAC vs. RBAC ? ¿Cuándo es mejor usar CBAC y cuándo es mejor usar RBAC?

Estoy tratando de entender los conceptos generales del modelo CBAC, pero la idea general todavía no está clara para mí.

Intentaré mostrar cómo puede beneficiarse del Control de acceso basado en reclamos en un contexto ASP.NET MVC.

Cuando utiliza 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 hacerlo, entonces escriba un código como este:

[Authorize(Roles="Sale")]
public ActionResult CreateCustomer()
{
    return View();
}

Más tarde, se dio cuenta de que, a veces, las personas con el rol de 'Marketing' deberían poder crear un Cliente. Luego, actualiza su método de acción así

[Authorize(Roles = "Sale", "Marketing")]
public ActionResult CreateCustomer()
{
    return View();
}

Ahora, se dio cuenta de que algunas de las personas de marketing no deben ser capaces de crear un Cliente, pero no es posible asignar un rol diferente para aquellas 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 que los profesionales de marketing creen clientes, debe actualizar todos sus métodos de acción MVC Autorizar atributo, compilar su aplicación, probar e implementar. Algunos días después, usted decidió, no el marketing, pero debería permitirse que otra función realice la tarea, por lo que debe buscar en su base de código y eliminar todo el 'Marketing' del atributo Autorizar y agregar su nuevo nombre de rol en el atributo Autorizar ... No es un solución saludable En ese momento, 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 algún código si el usuario tiene alguna propiedad como "Usuario de Facebook", "Usuario de mucho tiempo", etc. Permítanme 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 Reclamar 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 notificaciones.

Puede definir un conjunto de afirmaciones 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 no estar integrado en la biblioteca de clases MVC, solo estoy mostrando como ejemplo, puede usar alguna biblioteca de clases que tenga dicha definición de clase de atributo)

Ahora, puede ver que el método de acción CreateCustomer siempre necesitará permiso 'CanCreateCustomer' y nunca cambiará o apenas cambiará. Entonces, en su base de datos, crea una tabla de permisos (reclamos) y una relación de permiso de usuario. Desde su panel de administración, puede establecer un permiso (reclamo) para cada usuario que puede hacer qué. Puede asignar el permiso (reclamo) 'CanCreateCustomer' a cualquier persona que desee y solo el usuario permitido podrá crear un cliente y el usuario permitido podrá crear solo un cliente y nada más (a menos que asigne otros permisos al mismo usuario).

Este modelo de seguridad le ofrece una práctica de 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 esté usando este método tendrá el permiso (reclamo) adecuado otorgado por el Administrador. Luego, el administrador puede decidir quién podrá hacer qué. No como desarrollador. Así es como se separa su lógica empresarial de la lógica de seguridad.

Cada vez que alguien inicie sesión, su aplicación verificará 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 reclamos se almacena como cookie para el usuario conectado), para que no tenga que verificar el conjunto de permisos todo el tiempo desde la base de datos. La conclusión es que obtiene más control de su lógica de seguridad en su aplicación si aplica el acceso basado en notificaciones en lugar del acceso basado en roles. De hecho, un Rol también puede considerarse un Reclamo.

Si su aplicación es una aplicación muy pequeña donde solo habría 2 roles: Cliente y Administrador y no hay posibilidad de que el Cliente pueda hacer otra cosa que no sea lo que está destinado a hacer en su aplicación, entonces quizás, 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 un control de acceso basado en reclamos en algún momento.

He implementado modelos de seguridad muchas veces y también he tenido que entender estos conceptos. Habiéndolo hecho muchas veces, aquí está mi comprensión de estos conceptos.

¿Qué son los roles?

Rol = La unión de Usuarios y Permisos.

Por un lado, un rol es una colección de permisos. Me gusta llamarlo un perfil de permiso. Al definir un rol, básicamente agrega un montón de permisos a ese rol, por lo que, en ese sentido, un rol es un perfil de permisos.

Por otro lado, un Rol también es una colección de Usuarios. Si agrego a Bob y Alice a la función "Administradores", entonces "Administradores" ahora contiene una colección de dos Usuarios como un Grupo.

La verdad es que un rol es AMBOS una colección de usuarios y una colección de permisos juntos. Visualmente, esto se puede ver como un diagrama de Venn.

¿Qué es un grupo?

Grupo = Colección de usuarios

Un "Grupo" es estrictamente una colección de Usuarios. La diferencia entre un grupo y un rol es que un rol también tiene una colección de permisos, pero un grupo solo tiene una colección de usuarios.

¿Qué es un permiso?

Permiso = Lo que puede hacer un sujeto

¿Qué es un conjunto de permisos?

Conjunto de permisos = una colección de permisos

En un sistema RBAC robusto, los permisos también se pueden agrupar como usuarios. Mientras que los grupos son solo una colección de usuarios, un conjunto de permisos es solo una colección de permisos. Esto permite a un administrador agregar colecciones completas de permisos a roles a la vez.

Cómo se unen los usuarios, grupos, roles y permisos

En un sistema RBAC robusto, los usuarios pueden agregarse a un rol individualmente para crear la colección de usuarios en el rol o los grupos pueden agregarse a un rol para agregar una colección de usuarios al rol al mismo tiempo. De cualquier manera, el Rol obtiene su colección de Usuarios al agregarse individualmente o al agregar Grupos al Rol o al agregar una mezcla de Usuarios y Grupos al Rol. Los permisos se pueden considerar de la misma manera.

Los permisos se pueden agregar a los roles individualmente para crear la colección de permisos dentro del rol o los conjuntos de permisos se pueden agregar a un rol. Finalmente, se puede agregar una combinación de permisos y conjuntos de permisos a un rol. De cualquier manera, el Rol obtiene su colección de Permisos al agregarlos individualmente o al agregar Conjuntos de Permisos a un Rol.

El objetivo de Roles es casar a los Usuarios con los Permisos. Por lo tanto, un Rol es la UNIÓN de Usuarios y Permisos.

¿Qué son las reclamaciones?

Reclamación = qué es un sujeto

Las reclamaciones NO son permisos. Como se señaló en respuestas anteriores, una Reclamación es lo que un sujeto "no es" lo que un sujeto "puede hacer".

Las reclamaciones no reemplazan roles o permisos, son piezas de información adicionales que uno puede usar para tomar una decisión de autorización.

Cuándo usar las reclamaciones

He encontrado que las reclamaciones son útiles cuando es necesario tomar una decisión de autorización cuando el usuario no puede agregarse a un rol o la decisión no se basa en la asociación del usuario con el permiso. El ejemplo de un usuario de Facebook causa esto. Un usuario de Facebook puede no ser alguien que se agrega a un "rol" ... son solo un visitante autenticado a través de Facebook. Aunque no encaja perfectamente en RBAC, es una información para tomar una decisión de autorización.

@CodingSoft usó la metáfora del club nocturno en una respuesta anterior, que me gustaría extender. En esa respuesta, la Licencia de conducir se usó como un ejemplo que contenía un conjunto de Reclamaciones donde la Fecha de nacimiento representa una de las Reclamaciones y el valor de la Reclamación de fecha de nacimiento se usa para probar contra la regla de autorización. El gobierno que emitió la Licencia de Conducir es la autoridad que otorga autenticidad al Reclamo. Por lo tanto, en un escenario de club nocturno, el portero en la puerta mira la licencia de conducir de la persona, se asegura de que haya sido emitida por una autoridad confiable al examinar si es o no una identificación falsa (es decir, debe ser una identificación válida emitida por el gobierno), luego mira la Fecha de nacimiento (uno de los muchos reclamos en una Licencia de conducir), luego usa ese valor para determinar si la persona tiene la edad suficiente para ingresar al club. Si es así,

Ahora, con esa base en mente, me gustaría extenderla más allá. Suponga que el edificio donde se encuentra el club nocturno contiene oficinas, habitaciones, una cocina, otros pisos, ascensores, un sótano, etc., donde solo pueden ingresar los empleados del club. Además, ciertos empleados pueden tener acceso a ciertos lugares que otros no pueden tener. Por ejemplo, un Gerente puede tener acceso a un piso de la oficina que otros empleados no pueden acceder. En este caso hay dos roles. Gerente y Empleado.

Si bien el acceso de los visitantes al área del club nocturno público está autorizado por un solo reclamo como se explicó anteriormente, los empleados necesitan acceso por rol a otras salas restringidas no públicas. Para ellos, una licencia de conducir no es suficiente. Lo que necesitan es una insignia de empleado que escanean para ingresar a las puertas. En algún lugar hay un sistema RBAC que otorga insignias en el acceso del rol de administrador al piso superior e insignias en el acceso del rol de empleado a otras habitaciones.

Si por alguna razón Role necesita agregar / quitar ciertas habitaciones, esto se puede hacer usando RBAC, pero no es una buena opción para un Reclamo.

Permisos en software

Codificar roles en la aplicación es una mala idea. Esto codifica el propósito del Rol en la aplicación. Lo que la aplicación debería tener son solo permisos que actúen como banderas de características. Cuando los indicadores de características se hacen accesibles mediante la configuración, los permisos se hacen accesibles por el contexto de seguridad del usuario que se deriva de la colección DISTINCT de permisos reunidos de todos los roles en los que se ha colocado el usuario. Esto es lo que yo llamo los "permisos efectivos". La aplicación solo debe presentar un menúde posibles permisos para funciones / acciones. El sistema RBAC debería hacer el trabajo de unir esos permisos a los usuarios a través de roles. De esta manera, no hay una codificación rígida de los Roles y la única vez que cambia un Permiso es cuando se elimina o se agrega uno nuevo. Una vez que se agrega un permiso al software, nunca se debe cambiar. Solo debe eliminarse cuando sea necesario (es decir, cuando una función se suspende en una nueva versión) y solo se pueden agregar nuevas.

Una nota final.

Grant vs Deny

Un sistema RBAC robusto e incluso un sistema CBAC deberían distinguir entre subvenciones y denegaciones.

Agregar un permiso a un rol debe venir con un GRANT o un DENY. Cuando se marcan los Permisos, todos los Permisos OTORGADOS deben agregarse a la lista de Usuarios de Permisos Efectivos. Luego, después de todo lo que se hace, una lista de Permisos DENEGADOS debería hacer que el sistema elimine esos Permisos de la lista de Permisos Efectivos.

Esto permite a los administradores "ajustar" los permisos finales de un tema. Es mejor si los permisos también se pueden agregar a los usuarios directamente. De esta manera, puede agregar un usuario a un rol de administrador y obtener acceso a todo, pero tal vez desee NEGAR el acceso al baño de mujeres porque el usuario es un hombre. Entonces agrega el usuario masculino al rol de administrador y agrega un permiso al objeto Usuario con DENY para que solo le quite el acceso a la habitación de esa dama.

En realidad, este sería un buen candidato para un reclamo. Si el Usuario tiene un Reclamo "género = masculino", entonces estar en el rol de Administrador da acceso a todas las habitaciones, pero el baño de la Dama también requiere el Reclamo género = femenino y el baño de los hombres requiere Reclamo género = masculino. De esta manera, uno no tendría que configurar un permiso DENY para usuarios masculinos, ya que la aplicación de la reclamación se encarga de eso para todos con una sola regla de autorización. Sin embargo, podría hacerse de cualquier manera.

El punto es que con la DENEGACIÓN de permisos, facilita la gestión de los roles porque se pueden implementar excepciones.

A continuación se muestra un diagrama que hice hace mucho tiempo que muestra el modelo RBAC. No tengo un gráfico para las Reclamaciones, pero puede imaginar que son solo atributos adjuntos a los Usuarios dondequiera que se encuentren. Además, el diagrama no muestra Grupos (necesito actualizarlo en algún momento).

Espero que esto ayude.

Este es un diagrama del RBAC descrito arriba

Actualización el 7 de abril de 2019 Basado en los comentarios de @Brent (gracias) ... eliminó referencias innecesarias a respuestas anteriores y explicó la base original de la metáfora del "club nocturno" proporcionada por @CodingSoft para que esta respuesta sea comprensible sin tener para leer otras respuestas

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 reclamar?

Pienso 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 "rol" proporcionado por "Asp.NETroleProvider"

Ejemplos adicionales de reclamos.

1. "AAA" es un reclamo de tipo "MYExamSite.Score" proporcionado por "MYExamSite.com"

2. "Gold" es un reclamo de tipo "MYGYM.Membershiptype" proporcionado por "MYGYMApp"

La respuesta aceptada parece posicionar los roles como un objeto contundente y los reclamos 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 ámbito organizativo (es decir, Rol = Administrador). Las reclamaciones, por otro lado, pueden ser "hechas" por cualquier persona. Por ejemplo, la autenticación de Google puede generar reclamos que incluyen el "correo electrónico" de un usuario, adjuntando ese correo electrónico a una identidad. Google hace el reclamo, la aplicación elige si entender y aceptar ese reclamo. La aplicación en sí misma podría adjuntar posteriormente un reclamo llamado "método de autenticación" (como lo hace ASP.NET MVC Core Identity) 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 todas las reclamaciones están vinculadas explícitamente a una identidad e incluyen un alcance explícito. Esos reclamos pueden, por supuesto, usarse 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 objetivo principal de los reclamos. Ciertamente no lo distingue de los Roles, que se pueden usar exactamente de la misma manera para la autorización local.

Por lo tanto, uno puede elegir usar Roles, o Reclamaciones, o ambos con el propósito de autorización y probablemente no encuentre ninguna ventaja o desventaja inherente a ninguno de ellos, siempre y cuando esos Roles y Reclamaciones tengan un alcance local. Pero si, por ejemplo, la autorización depende de reclamos de identidad externos, los roles serán inadecuados. 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.

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 basada en roles
• Página NIST de control de acceso basado en atributos

Lo fundamental entre RBAC y CBAC es que:

RBAC : un usuario debe ser asignado a un rol para estar 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 reclamos es elegante para escribir y más fácil de mantener.

Además de que los reclamos son emitidos a la aplicación por un servicio de autorización de emisión (Security Service Token STS) en el que confía su aplicación (Relying Party)

El rol es solo un tipo de reclamo. De esa manera, puede haber muchos otros tipos de reclamo, por ejemplo, el nombre de usuario es uno de los tipos de reclamo

Es importante analizar primero para qué se requiere la autenticación antes de decidir qué método es mejor. De la documentación de Microsoft a continuación, dice "Un reclamo no es 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 del reclamo sería DateOfBirth, el valor del reclamo sería su fecha de nacimiento, por ejemplo, el 8 de junio de 1970 y el emisor sería la autoridad del permiso 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 basado en ese valor. Por ejemplo, si desea acceder a un club nocturno, el proceso de autorización podría ser: 6 "

A partir de este ejemplo, podemos ver que el acceso a un club cercano con una Autorización basada en reclamos es diferente del 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 todos 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. La forma en que se crean y administran estos roles depende del almacén de respaldo del proceso de autorización. Los roles están expuestos 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 14/10/2016 Cuando se crea una identidad, se le puede asignar uno o más reclamos emitidos por una parte confiable. Un reclamo es un par de nombre y valor 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 del reclamo sería DateOfBirth, el valor del reclamo sería su fecha de nacimiento, por ejemplo, el 8 de junio de 1970 y el emisor sería la autoridad del permiso 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 basado en 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ía 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.

También es posible gestionar roles de manera reclamada.

En lugar de crear roles de autorización que reflejen un rol comercial, cree roles que reflejen roles de acción, por ejemplo, CreateCustomer, EditCustomer, DeleteCustomer. Anote los métodos según sea necesario.

No es un asunto simple asignar individuos a un conjunto de roles de acción, especialmente a medida que la lista de roles se hace más grande. Por lo tanto, deberá administrar los roles comerciales en un nivel de granularidad más bajo (por ejemplo, Ventas, Marketing) y asignar el Rol comercial a los roles de acción requeridos. Es decir, agregue un usuario a un rol comercial y los asigna a los roles requeridos (acción) en la tabla de autorización existente.

Incluso puede anular el rol comercial y agregar 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

Creo que esta pregunta podría responderse desde la base de datos prospectiva. si notó cómo las tablas involucradas en esta implantación encontrará lo siguiente

1. AspNetUsers: cada usuario tiene una fila con todos los atributos requeridos por todos los usuarios como correo electrónico, dirección, teléfono, contraseña .....
2. AspNetRoles; define diferentes roles según los requisitos de la aplicación como GM, CTO, HRM, ADMIN, EMP. lo que define cada rol es según las necesidades de la aplicación.
3. AspNetUserRoles: cada fila vincula AspNetUsers y AspNetRoles y efectivamente vincula entre un usuario y muchos roles.
4. AspNetUserClaims: cada fila tiene clave para AspNetUsers y un tipo y valor. agregue de manera efectiva un atributo para cada usuario que pueda agregarse / eliminarse en tiempo de ejecución.

El uso de estas tablas podría modificarse en un momento del tiempo de vida del usuario / aplicación para satisfacer necesidades específicas.

Considere la etapa inicial del "Gerente de Compras" (PM), podríamos tener tres enfoques

1. La aplicación llena AspNetUserRoles con una fila para otorgar el derecho de compra 'PM'. Para emitir una orden de compra con cualquier cantidad, el usuario solo necesita el rol "PM".

2. La aplicación llena AspNetUserRoles con una fila para otorgar el derecho de compra 'PM', y llena el AspNetUserClaims un reclamo de tipo TYPE 'Monto de compra' y el valor "<1000" para establecer el límite de cantidad. Para emitir un pedido de compra, el usuario debe tener 'PM' y el monto del pedido debe ser menor que el valor del reclamo del TIPO de reclamo 'Monto de compra'.

3. La aplicación completa AspNetUserClaims con el reclamo de tipo TYPE 'Importe de compra' y el valor "<1000". Cualquier usuario puede emitir una orden de compra, dado que el monto debe ser menor que el valor del reclamo del TIPO de reclamo 'Monto de compra' para este usuario.

Como se puede notar, la función basada en roles es un grano grueso de derechos rígidos que simplificarían 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 comerciales. Por otro lado, los derechos basados ​​en reclamos están muy bien y deben asignarse a cada usuario. basado en reclamos empujará al negocio también al límite, sin embargo hará que la administración del sistema sea muy compleja.

Control de acceso basado en roles (RBAC)

En su organización, puede tener los siguientes roles

Empleado

Gerente

HORA

Dependiendo de la función o funciones a las que pertenece el usuario conectado, puede autorizar o no el acceso a ciertos recursos en la aplicación. Dado que estamos utilizando Roles para realizar verificaciones de autorización, esto se denomina comúnmente Control de acceso basado en roles (RBAC) o Autorización basada en roles.

En ASP.NET Core para implementar la autorización basada en roles, utilizamos el atributo Authorize con el parámetro Roles.

[Authorize(Roles = "Admin")]
public class AdministrationController : Controller
{
}

Control de acceso basado en reclamos (CBAC)

¿Qué es el reclamo? Un reclamo es un par nombre-valor. Es realmente una información sobre el usuario, no lo que el usuario puede y no puede hacer. Por ejemplo, nombre de usuario, correo electrónico, edad, sexo, etc.son todas las reclamaciones. La forma en que utilice estos reclamos para verificaciones de autorización en su solicitud depende de los requisitos comerciales y de autorización de su aplicación.

Por ejemplo, si está creando un portal para empleados, puede permitir que el usuario conectado solicite una licencia de maternidad si el valor de la reclamación de género es femenino. Del mismo modo, si está creando una aplicación de comercio electrónico, puede permitir que el usuario conectado envíe un pedido si el valor del reclamo de edad es mayor o igual a 18.

Las reclamaciones se basan en políticas. Creamos una política e incluimos uno o más reclamos en esa política. La política se usa junto con el parámetro de política del atributo Autorizar para implementar la autorización basada en notificaciones.

[Authorize(Policy = "DeleteRolePolicy")]
public async Task<IActionResult> DeleteRole(string id)
{
}