En ASP.Net Core, encuentro que la Claimsautorización es un método muy poco concreto. Podemos agregar cualquier cosa como ClaimTypey ClaimValueemparejar; grupos, nombre, apellido, brithdate, canAccessThisURI, isEditor, etc. Sin embargo, este enfoque (que almacena todo lo que se puede almacenar como reclamos) creará una gran tabla de reclamos que incluye el 50% de los datos de mi aplicación.
Me pregunto, como buena práctica, ¿cuáles son los datos comunes que deberían almacenarse como reclamos?
Respuestas:
Un reclamo es simplemente un hecho sobre un usuario que potencialmente puede usarse para identificar o autorizar a alguien en su sistema. Esas dos restricciones deberían ser suficientes para limitar lo que pondría como reclamo.
Algunas ideas para reclamos incluyen:
Los metadatos del usuario deben limitarse a lo que se necesita para personalizar la aplicación para el usuario y asociarlo con sus datos. La identificación del usuario es suficiente para asociar al usuario con datos o proporcionar un seguimiento de auditoría. No te vuelvas codicioso.
Los roles y las membresías de grupo son reclamos de autorización. Por ejemplo, si tiene grupos en su aplicación, la lista de grupos a los que pertenece el usuario le permite verificar rápidamente si pueden acceder a un grupo privado o no. Los roles son un poco más precisos y hablan de los privilegios que tiene un usuario. Por lo general, estos son específicos de la aplicación, por lo que solo agregue lo que necesita hacer cumplir.
fuente
Hay muchos sistemas, especialmente sistemas STS / federación, que lo hacen de esta manera:
Es posible que los datos del "perfil" del usuario dentro de la aplicación no se traduzcan hacia / desde la fuente de autenticación que está utilizando y no puede utilizar los mismos puntos finales en todo momento o todos los usuarios.
Si estaba familiarizado con la antigua autenticación de formularios, es análoga al nombre de usuario y modelo de roles y muchas de las cosas integradas todavía se ven así si usa System.Security.Claims.ClaimTypes de nombre y rol de manera adecuada.
Ni el modelo antiguo ni el nuevo le dieron mucho de inmediato para la herencia de reclamos o roles, pero eso no es particularmente difícil de implementar y su implementación le permite reducir el volumen de reclamos o roles que debe mantener en juego desde la solicitud solicitar.
Si su aplicación necesita hacer un seguimiento de un cumpleaños, pero no necesita usarla en un mecanismo de seguridad, entonces realmente no hay ningún beneficio en mantenerla en la colección de reclamos. Póngalo en un conjunto de datos de perfil separado o algo así.
Si su aplicación necesita recibir el cumpleaños como un reclamo de otro sistema, entonces está buscando algo más como personalizar la Autenticación federada o permitir que el reclamo adicional persista.
fuente