wcf - ¿Cuál es el propósito de la autorización basada en reclamos?
authorization (4)
El control de acceso basado en notificaciones también ayuda a crear control de acceso basado en atributos y control de acceso basado en políticas. Si estandariza en un conjunto de reclamos acordados previamente que se pueden asignar a los usuarios en función de sus otros atributos (por ejemplo, un gerente de EE. UU. Puede tener un reclamo U_M; un gerente europeo puede tener el reclamo E_M). En un entorno basado en atributos y basado en políticas, es posible lograr una autorización detallada (también conocida como derechos detallados) usando XACML. En este caso, puede tener una autorización que depende de quién es el usuario (reclamos), pero también de qué quiere hacer (información de recursos) y bajo qué circunstancias (contexto).
CBAC con XACML te permitirá expresar reglas como:
los gerentes pueden editar notas creadas por ellos mismos o notas que sus informes directos crearon.
He estado leyendo sobre el servicio de control de acceso de Azure y la autorización basada en reclamos en general desde hace un tiempo y, por la razón que sea, todavía no veo la razón fundamental para pasar de la autorización basada en roles / permisos a un modelo basado en reclamos . Los modelos parecen similares a mí (y probablemente lo son), excepto que la lista de lo que el cliente puede y no puede hacer proviene de un tercero y está envuelto en algún tipo de token, en lugar de en una especie de base de datos que el servidor tiene que consultar. ¿Cuál es la ventaja de involucrar a un tercero (el emisor del token)?
Entiendo completamente las ventajas de la autenticación de outsourcing a un tercero. Permite que las aplicaciones no tengan que crear usuarios nuevos todo el tiempo, preocuparse por almacenar contraseñas, etc., cuando pueden enviarlas a otro servicio que ya tiene la infraestructura configurada. Es esencialmente el principio SECO para la autenticación.
Sin embargo, en mi opinión, esa misma lógica no funciona para la autorización. Cada aplicación tiene sus propios recursos que debe proteger y, por lo tanto, sus propias reglas para autorizar a los usuarios a realizar determinadas acciones. La infraestructura parece lo suficientemente simple como para que cada aplicación pueda crearla por sí misma (una tabla asignando a los usuarios roles, y posiblemente otra asignación de roles a permisos), e incluso si quisiera externalizarla, parece que el modelo basado en reclamos está haciendo algo más complicado que eso.
La única explicación parcial que he visto proviene de Crear un modelo de seguridad basado en notificaciones en WCF , y ofrece dos ventajas principales para la autenticación basada en notificaciones: más flexibilidad y alguien que "confirme" que la información contenida en un reclamo es correcta. ¿Cuándo necesitarías alguno de esos?
La autorización basada en reclamaciones parece estar ganando popularidad, así que supongo que debe haber una buena razón para ello; Aún no he descubierto qué es eso. ¿Puede alguien proporcionar un ejemplo concreto de una situación en la que la autenticación basada en notificaciones funciona mejor que la basada en roles, y por qué funciona mejor en ese caso?
(EDITAR: Me perdí un tercer beneficio enumerado en el artículo: apoyo al inicio de sesión único / federación. ¿Pero la autenticación no se ocupa de eso por sí misma sin involucrar la autorización?)
El objetivo de la autorización basada en notificaciones es permitir el control de acceso detallado basado en expresiones booleanas que evalúan las características de la entidad que accede y el recurso. Esto reduce o elimina la necesidad de proporcionar grupos. Al igual que con la identidad federada, los reclamos también brindan un vehículo para que un proveedor de Identidad administre a sus usuarios mientras permiten que un proveedor de recursos asegure a los usuarios el acceso a los activos.
Nota: Las reclamaciones se pueden utilizar en una sola empresa y brindan los siguientes beneficios:
1) Las concesiones y revocaciones de acceso no requieren aprovisionamiento o desaprovisionamiento
2) Por lo tanto, los cambios son instantáneos
3) Los propietarios de recursos pueden definir el alcance y los requisitos para el acceso en lugar de que los administradores creen grupos administren membresías grupales: esto transfiere las decisiones de control de acceso a las personas más adecuadas para tomar dichas decisiones (el propietario de los datos)
4) Esto da como resultado que se requieran menos grupos y menos miembros en los grupos
5) Puede haber problemas al crear un solo grupo para dar cabida a una gran comunidad que tiene acceso (por ejemplo, todos los empleados a tiempo completo pueden leer una política de recursos humanos) - Las reclamaciones evitan este problema
6) La auditoría es más informativa: la razón por la cual se realizó una concesión o denegación es claramente visible
7) Las notificaciones admiten atributos dinámicos, como autenticación de dos factores, hora del día o restricciones de red
Hay muchas más razones, pero esas vienen a la mente. Próximamente habrá un video en www.cionsystems.com que muestra esto (descargo de responsabilidad: trabajo allí y grabé el video; aún así necesito publicarlo). También, como referencia, las plataformas y aplicaciones que admiten notificaciones incluyen SharePoint 2010 en, Windows 2012 (archivos compartidos), Azure, muchos servicios SaaS (Facebook y Salesforce)
Además, con los reclamos, puede combinar información de múltiples fuentes (por ejemplo, Facebook y su AD local), etc., que es cada vez más importante
No estoy seguro de si las reglas lo permiten, pero siéntase libre de enviarnos un mensaje con sus preguntas o comentarios. Voy a editar felizmente la publicación para hacer correcciones o agregar información pertinente.
Las reclamaciones pueden provenir de AD, tablas de bases de datos, SAML, OAuth, algoritmos, XACML o cualquier otro proveedor de confianza. Aprovechar las reclamaciones requiere un poco de kit: las aplicaciones y las plataformas evolucionan rápidamente en este espacio.
Todo lo mejor,
Pablo
La seguridad basada en roles es un modelo de seguridad limitado. La autorización es:
Based on role membership only
La seguridad basada en reclamos es mucho más flexible y expresiva. La autorización puede ser:
Basado en membresía de rol
Basado en la edad
Basado en la ubicación geográfica
Basado en un saldo de cuenta
Basado en un tamaño
Basado en niveles de seguridad predefinidos
Basado en cualquier combinación de lo anterior
Supongo que la principal promesa de un beneficio del sistema federado de seguridad / basado en reclamos sería un área menor en la que tenga que lidiar con diferentes sistemas.
Imagine un sitio donde tenga usuarios locales autenticados con credenciales de Windows, un grupo de usuarios de Internet que usen nombre de usuario / contraseña, otros que usen certificados y tal vez otro grupo de usuarios con autenticación biométrica.
En el sistema actual, tiene que configurar y tratar con todos los diferentes tipos de esquemas de autenticación y sus diferentes formas de hacer las cosas. Eso puede ser bastante complicado.
La promesa de una solución de seguridad federada sería manejar todos los quehaceres para usted: el STS (servidor de token de seguridad) manejaría todos los diferentes tipos de sistemas de autenticación para usted y le presentaría un conjunto uniforme y confiable de reclamos sobre un llamante: no importa desde dónde y en qué camino esté llegando a su sitio.
Por supuesto, el solo hecho de examinar y reaccionar frente a un único conjunto de afirmaciones en lugar de tener que entender cuatro, cinco, diez sistemas de autenticación diferentes y dispares parece una promesa realmente convincente para mí.