authorization - ¿La autorización basada en reclamaciones es apropiada para recursos individuales?

access claims-based-identity

Question

Entiendo el uso de reclamaciones para cosas a las que comúnmente me referiré como "roles" o "permisos". Sé que los reclamos son más generales, pero por lo que he visto en la práctica, generalmente se reduce a esto: si el usuario tiene este conjunto de reclamos, puede acceder a ciertas áreas o realizar ciertas funciones.

Imagina una aplicación wiki. Puede tener una reclamación content_contributor que permitiría a un usuario agregar contenido, una reclamación content_admin que le permitiría a un usuario eliminar contenido y una reclamación modify_user que permitiría otorgar derechos de contribuyente a otro usuario.

Tomando este ejemplo un paso más allá, es posible que desee restringir a los usuarios para que solo puedan ver el contenido creado por ellos mismos o su equipo.

Si un usuario solo puede ver el contenido creado por ellos mismos, ¿tendríamos un reclamo por cada parte del contenido que crearon o delegaríamos esa autorización a la aplicación?

Answer 1

Cuando se habla de roles y permisos , se habla de autorización .

Las reclamaciones normalmente no son para autorización . Las reclamaciones (de identidad) existen para modelar la identidad del usuario: ¿ quién es el usuario? Los reclamos en sí mismos no dicen nada acerca de la autorización. Un usuario puede tener un reclamo de rol, pero esto no le dice a la aplicación lo que el usuario tiene permitido hacer.

La autorización es realizada por la aplicación, en función de quién es el usuario. Piense en la autorización como un conjunto de reglas , como:

• 18+ : permitir cuando el usuario es mayor de 18 años ( DateOfBirth ).

• Usar coche : permitir cuando el usuario tiene una licencia de conducir.

O algo así.

Los roles son un poco confusos, ya que a menudo se utilizan mal para su autorización. Por favor, lea este artículo para obtener información de fondo.

El problema con los roles de la OMI es que estos no son universales. Puedo ser médico en un hospital, mientras que soy paciente en otro. Y puedo ser administrador para un inquilino, pero un usuario para otro inquilino. Así que solo tienen significado dentro de un cierto contexto.

La única razón para incluir roles como reclamación es que no necesitará buscar esta información ya que ya está presente. Pero dado el comentario anterior, en realidad no puede incluir esta información. Y solo te dará dolores de cabeza cuando lo hagas. Debido a que no puede hacer cosas simples como actualizar o cambiar permisos o configuraciones de perfil, hasta que el usuario vuelva a iniciar sesión.

Como regla general: mantenga la autorización cerca del recurso (api / sitio web). Porque ese es el lugar donde se implementan las reglas de negocio. Y ese es el lugar donde puedes almacenar y actualizar permisos, etc.

Mantenga una separación de preocupaciones cuando se trata de autenticación y autorización. La autenticación le dice quién es el usuario y la autorización le dice qué se le permite hacer al usuario. No mezcles estos dos.

Traduciendo esto a tu aplicación wiki:

Cree un contexto separado donde almacene información de autorización como roles y permisos. Puede administrar esto en un recurso central (para múltiples aplicaciones) o usar el contexto en su aplicación. No mezclaría este contexto con el contexto empresarial .

Agregue un usuario en el contexto de autorización y agregue un rol content_contributor . Dentro de la aplicación, lea los permisos (de la API central, el contexto de autorización local, un archivo de configuración o cualquier cosa que se adapte mejor) para ese usuario (basado en la subreivindicación ). Almacénelo en caché para acelerar el rendimiento y aplique las reglas para determinar si el usuario tiene permiso para acceder al recurso.

Puede ampliar esto con autorización basada en recursos . Guarde el valor del reclamo secundario en el registro de contenido para identificar al propietario. Cuando el usuario actual coincide con el valor de sub reclamo, el usuario actual es el propietario.

Puedes usar el mismo enfoque para los equipos. Agregue una tabla de equipos al contexto empresarial y vincule al usuario con uno o más equipos. Utilizando directamente el valor de sub reclamo o indirectamente, utilizando una tabla de Usuarios, también en el contexto de negocios, donde el usuario está vinculado al valor de reclamo secundario . Puede agregar un nombre, etc. en caso de que quiera mostrar esta información (como en un informe).

Puede guardar la identificación del equipo y / o la identificación del usuario o el valor secundario de la reclamación (el propietario es miembro del mismo equipo que el usuario actual) en el registro de contenido para determinar el acceso permitido para el usuario.

Mi configuración sería así:

Contexto de identidad : usuarios + reclamaciones de usuarios. Sólo para autenticación. Aplicación independiente.

Contexto de autorización : usuarios (id = sub reclamo) + por aplicación: roles, permisos, etc. En bases de datos ''locales'' separadas o en una base de datos central. Sólo para autorización.

Contexto empresarial : usuarios (Id, Nombre, subreivindicación ''clave externa'', sin la relación real de la base de datos, ya que la tabla está fuera del contexto) + equipos, perfil, configuración, etc. Vinculado al valor de subreivindicación cuando se omite la tabla de usuarios.

Para mantener actualizada la tabla de usuarios en el contexto empresarial, actualice periódicamente los valores. Por ejemplo, puede actualizar los valores cuando el usuario inicia sesión después de x tiempo. O de vez en cuando, consulte el Contexto de identidad (mediante la API) para solicitar información del usuario (mediante el punto final de información de usuario de identidades).

En todos los contextos puede haber una tabla de usuarios , pero todos tienen un significado diferente y contienen otra información. Así que no hay información redundante.

La autorización tiene lugar dentro de la aplicación y se basa en las reglas comerciales (políticas) y la información de autorización del contexto de autorización.

Como observación final, cuando el sistema actual requiere reclamaciones de roles (como para User.IsInRole() o [Authorize("role")] ), entonces puede leer (desde el caché) el rol / permisos en cada llamada y agregarlos a la Recogida de reclamaciones del usuario actual (transformación de reclamaciones).