asp.net mvc - based - Mejores prácticas para roles vs. reclamos en identidad ASP.NET

identity roles vs claims

Question

Soy completamente nuevo en el uso de claims en ASP.NETIdentity y quiero tener una idea de las mejores prácticas en el uso de Roles and/or Claims .

Después de toda esta lectura, todavía tengo preguntas como ...

P: ¿Ya no usamos Roles?
P: Si es así, ¿por qué todavía se ofrecen Roles?
P: ¿Deberíamos usar solo Reclamaciones?
P: ¿Deberíamos usar Roles y Reclamaciones juntos?

Mi pensamiento inicial es que "deberíamos" usarlos juntos. Veo las Claims como subcategorías de los Roles que admiten.

POR EJEMPLO:
Rol: Contabilidad
Reclamaciones : CanUpdateLedger, CanOnlyReadLedger, CanDeleteFromLedger

P: ¿Están destinados a ser mutuamente excluyentes?
P: ¿O es mejor presentar SOLAMENTE las Reclamaciones y "calificar completamente"?
P: ¿Cuáles son las mejores prácticas aquí?

EJEMPLO: Uso conjunto de roles y reclamos
Por supuesto, tendría que escribir su propia lógica de atributos para esto ...

[Authorize(Roles="Accounting")]
[ClaimAuthorize(Permission="CanUpdateLedger")]
public ActionResult CreateAsset(Asset entity)
{
    // Do stuff here

    return View();
}

EJEMPLO: Calificación completa de sus reclamos

[ClaimAuthorize(Permission="Accounting.Ledger.CanUpdate")]
public ActionResult CreateAsset(Asset entity)
{
    // Do stuff here

    return View();
}

Answer 1

Como @Claies explicó perfectamente, los reclamos podrían ser más descriptivos y es un tipo de rol profundo. Pienso en ellos como sus roles de identificación. Tengo una identificación de gimnasio, así que pertenezco al rol de miembros. También estoy en las lecciones de kickboxing, así que tengo un reclamo por ellas; una identificación de kickboxing. Mi solicitud necesitaría la declaración de un nuevo rol para adaptarse a mis derechos de membresía. En cambio, tengo identificadores para cada cosa especial que puedo hacer en el gimnasio; en lugar de muchos nuevos tipos de membresía. Es por eso que las reclamaciones me quedan mejor.

Hay un gran video explicativo de Barry Dorrans, que habla sobre la ventaja de usar reclamos sobre los roles. También afirma que los roles todavía están en .NET por compatibilidad con versiones anteriores. El video es muy informativo sobre la forma en que funcionan las notificaciones, los roles, las políticas, la autorización y la autenticación.

Puede encontrarlo aquí: Autorización básica de ASP.NET con Barr Dorrans

Answer 2

Después de haber utilizado varias técnicas de autenticación y autorización durante décadas, mi aplicación MVC actual utiliza la siguiente metodología.

Las reclamaciones se utilizan para toda autorización. A los usuarios se les asigna un rol (son posibles múltiples roles pero no lo necesito), más abajo.

Como es una práctica común, se utiliza una clase de atributo ClaimsAuthorize. Dado que la mayoría de las acciones del controlador son CRUD, tengo una rutina en la generación de la base de datos de código primero que itera todas las acciones del controlador y crea tipos de reclamo para cada atributo de acción del controlador de Leer / Editar / Crear / Eliminar. Por ejemplo, de

[ClaimsAuthorize("SomeController", "Edit")]
[HttpPost]

Para usar en una vista MVC, una clase de controlador base presenta elementos de bolsa de vista

        protected override void OnActionExecuting(ActionExecutingContext filterContext)
        {
            // get user claims
            var user = filterContext.HttpContext.User as System.Security.Claims.ClaimsPrincipal;

            if (user != null)
            {
                // Get all user claims on this controller. In this controler base class, [this] still gets the descendant instance type, hence name
                List<Claim> claims = user.Claims.Where(c => c.Type == this.GetType().Name).ToList();

                // set Viewbag with default authorisations on this controller
                ViewBag.ClaimRead = claims.Any(c => c.Value == "Read");
                ViewBag.ClaimEdit = claims.Any(c => c.Value == "Edit");
                ViewBag.ClaimCreate = claims.Any(c => c.Value == "Create");
                ViewBag.ClaimDelete = claims.Any(c => c.Value == "Delete");
            }

            base.OnActionExecuting(filterContext);
        }

Para los menús del sitio web y otras acciones no relacionadas con el controlador, tengo otras reclamaciones. Por ejemplo, si un usuario puede ver un campo monetario particular.

bool UserHasSpecificClaim(string claimType, string claimValue)
{
    // get user claims
    var user = this.HttpContext.User as System.Security.Claims.ClaimsPrincipal;

    if (user != null)
    {
        // Get the specific claim if any
        return user.Claims.Any(c => c.Type == claimType && c.Value == claimValue);
    }

    return false;
}

public bool UserHasTradePricesReadClaim
{
    get
    {
        return UserHasSpecificClaim("TradePrices", "Read");
    }
}

Entonces, ¿dónde encajan los roles?

Tengo una tabla que vincula un rol a un conjunto (predeterminado) de reclamos. Al establecer la autorización del usuario, el valor predeterminado es dar al usuario las reclamaciones de su rol. Cada usuario puede tener más o menos reclamos que el predeterminado. Para simplificar la edición, el controlador y las acciones muestran la lista de reclamos (en una fila), y luego se enumeran otros reclamos. Los botones se usan con un poco de Javascript para seleccionar un conjunto de acciones para minimizar el "clic" requerido para seleccionar reclamos. En Guardar, los reclamos de los usuarios se eliminan y se agregan todos los reclamos seleccionados. La aplicación web carga los reclamos solo una vez, por lo que cualquier cambio debe provocar una recarga dentro de estos datos estáticos.

Por lo tanto, los administradores pueden seleccionar qué reclamos están en cada rol y qué reclamos tiene un usuario después de establecerlos en un rol y esos reclamos predeterminados. El sistema solo tiene una pequeña cantidad de usuarios, por lo que administrar estos datos es sencillo

Answer 3

Para comprender la diferencia entre Roles y Reclamaciones, debe enfrentar la limitación de roles y sentir cómo surgen los reclamos sobre estos problemas, así que enciéndame le doy dos escenarios para reconocer el poder de los reclamos donde el rol no puede resolver estos problemas:

1- su sitio tiene dos módulos (páginas, servicio, etc.) el primer módulo para niños (menores de 18 años) y el otro para adultos (mayores de 18 años) su identidad de usuario tiene reclamo de cumpleaños

debe crear una política sobre este reclamo para que se otorgue la autorización para cada módulo sobre este valor y si la edad del usuario supera los 18 años, puede ir al módulo para adultos y no antes de esta edad.

El rol es el tipo de datos booleanos que puede tener o no el rol que el rol no tenía valores incorrectos

2- su sitio tiene un rol de usuario y no desea impedir el acceso de los usuarios para realizar tareas de mantenimiento sin cambiar el código

en los reclamos, puede crear una política UnderConstrain que, si el usuario verdadero no puede ver la página, otorgue a la propiedad autorización para el usuario de rol.

Answer 4

Un rol es una categoría simbólica que reúne a usuarios que comparten los mismos niveles de privilegios de seguridad. La autorización basada en roles requiere primero identificar al usuario, luego determinar los roles a los que está asignado el usuario y finalmente comparar esos roles con los roles que están autorizados para acceder a un recurso.

Por el contrario, una Reclamación es un derecho del usuario para identificarse. En otras palabras, "se me permite hacer esto porque tengo este Reclamo". En general, la autorización basada en reclamos subsume la autorización basada en roles. Para ser precisos, la membresía de roles se determina en función de la identidad, y la identidad es solo un tipo de derecho sobre el valor de un reclamo. Los roles son esencialmente un tipo de reclamo muy específico, es decir, "Debido a que mi nombre de usuario es este, soy miembro de este rol. Debido a que soy miembro de este rol, tengo acceso a este recurso".

Puede usar ambos en concierto, o usar un tipo en algunas situaciones y el otro en otras situaciones. Depende principalmente de la interoperación con otros sistemas y su estrategia de gestión. Por ejemplo, podría ser más fácil para un administrador administrar una lista de usuarios asignados a un rol que administrar quién tiene un Reclamo específico asignado. Los reclamos pueden ser muy útiles en un escenario RESTful donde puede asignar un reclamo a un cliente, y el cliente puede presentar el reclamo de autorización en lugar de pasar el Nombre de usuario y la Contraseña para cada solicitud.