Reclamaciones personalizadas con el marco de Ginebra y cómo "sincronizar" usuarios dentro de su aplicación

Question

Quizás esta pregunta resalte lo poco que sé sobre la gestión de identidad de reclamos, pero aquí va.

Si usa WIF dentro de una aplicación que usa un STS de terceros para identidad y que usa reclamos personalizados para autorización (algo pertinente y específico para la aplicación como CanCreateFooBar)

1) ¿Cómo administro los usuarios?Es decir, se pueden identificar los usuarios de, por ejemplo, AD u otro proveedor de membresía, pero internamente en mi sistema necesito saber sobre ellos y tener más información de usuario que no tenga nada que ver con la identidad (por lo que realmente no tendría sentido tener esta información disponible). fuera del sistema), y que la información sobre el usuario debe conservarse,
La pregunta es ¿Cómo puedo administrar y crear los datos de mi sistema (Empezando por los Ids) de manera inteligente?
El escenario exacto que tengo en mente es que se agrega un nuevo empleado a la empresa, el administrador del sistema crea el usuario para el dominio con una función particular, ¿cómo puede mi sistema darse cuenta de este hecho?(Probablemente me gustaría que el sistema solicite una acción al administrador del sistema).

2) ¿Dónde se almacenan los valores de reclamo para esos usuarios y roles y cómo puedo modificarlos?Lo ideal sería poder cambiar los permisos para un usuario y una acción en particular.¿Existen pautas al respecto?

Puedo ver que probablemente estas sean preguntas muy tontas, pero cuando pienso en cómo resolver el problema, se me ocurren soluciones demasiado complicadas o que requieren mucha duplicación (es decir, crear lo usado en dos lugares), así que estoy seguro de que Simplemente no estoy pensando en este problema de la manera correcta.

Gracias

Answer 1

1) No administras a los usuarios, en realidad no. Simplemente tome la IclaimsIdentidad y use eso como fuente de su autorización. En mi opinión, no debe persistir las afirmaciones si puede escapar sin hacerlo: las afirmaciones deben ser la fuente de la información de su usuario.

Si desea aprovechar los reclamos, tome una referencia única de la identidad de las reclamaciones, diga la dirección de correo electrónico o la clave de firma/clave PPID/firme y úsela para construir su propia base de datos, y agregue su propia información.

Sin embargo, su sistema nunca se alejará de los cambios en una metabase de identidad de terceros, no hasta que se emita y analice un nuevo token SAML en su solicitud.

2) Los valores de reclamos no se almacenan en ninguna parte, a menos que los almacene. La forma en que traduce eso en permisos depende de usted, pero generalmente realiza la transformación de reclamos para tomar los reclamos externos y asignarlos a reclamos internos a su aplicación que utiliza para los permisos. Debido a que las afirmaciones provienen de proveedores externos, no puede cambiarlos, no tiene conexión con esos proveedores.

Answer 2

Como está viendo, la Federación no necesariamente alivia la necesidad de aprovisionamiento. Esta es una visión importante que no es inmediatamente obvia.

Hay múltiples formas de abordar esto, incluyendo:

1. El uso de un producto de directorio meta o virtual o
2. Mediante el uso de "aprovisionamiento JIT" (también conocido como "aprovisionamiento dinámico" o "aprovisionamiento sobre la marcha").

Déjame explicarte este último. Esta solución, que también describo en mi blog, incluye dos STSS, un IP-STS y un RP-STS. El primero autentica únicamente al usuario; El segundo es específico de su aplicación y sabe qué reclamos son necesarios para autorizar a los usuarios de ese sistema. El IP-ST no puede emitir estos atributos específicos de la aplicación, lo que requeriría que su servicio de directorio corporativo esté abarrotado de todo tipo de información específica de la aplicación. En cambio, los atributos para los usuarios que se mantienen en esa tienda y emitidos por el IP-STS son de naturaleza general y son aplicables al usuario, independientemente de la aplicación que esté utilizando. Después de autenticarse al IP-STS y obtener reclamos de identidad solo de él, el token se transmite al RP-STS. Este servicio de token está estrechamente acoplado a su aplicación. Sabe qué afirman que los usuarios necesitan para acceder a diferentes recursos. Puede convertir las afirmaciones de identidad solo a las necesarias para tomar esta decisión de control de acceso. Por lo tanto, el RP-STS es un transformador de reclamos que mapea las afirmaciones relacionadas con la identidad en las específicas de la aplicación.

¿Cómo provoca el usuario RP-STS? Supongamos que se crea un nuevo empleado, como en su ejemplo anterior. Cuando el usuario accede a su aplicación, será rebotado en el RP-STS. No se registrará allí, por lo que será rebotado en el IP-STS. El administrador del SYS creó una cuenta para él, por lo que podrá iniciar sesión, y su navegador lo recuperará con el RP-STS. El RP-STS descifrará el token, obtendrá la ID de usuario (correo electrónico, PPID, etc.), y verá que no sabe quién es el usuario. Entonces, el RP-STS provocará al usuario. Hará esto mostrando una página web, por ejemplo. Podría recopilar información que le ayuda a determinar el papel de ese usuario al acceder al RP. Después de esto, se aprovisionará al usuario (es decir, se creará un registro en su base de datos que contenga valores de reclamo para él), y el RP-STS emitirá un token específico para su aplicación y lo redirigirá allí. La solicitud no sabrá que solo fue aprovisionado; Solo usará las afirmaciones como siempre lo hace. (¿Ves por qué lo llamé JIT Provisioning?)

¿Qué pasa si las cosas cambian después de que se aprovisionó al usuario? ESTÁ BIEN. Imagine esto: el usuario fue creado en la tienda de directorio hace años y se aprovisionó como se describió anteriormente en el RP-STS y ha estado utilizando el sistema felizmente durante mucho tiempo. Luego hay un cambio de política que requiere que los usuarios de su aplicación acepten nuevos términos y condiciones (T&C). La próxima vez que el usuario inicie sesión en la aplicación, será redirigido a los RP-STS, al IP-STS, se autenticará y será recuperado a sus RP-STS. En ese momento, notará que el usuario debe aceptar el nuevo T&C, por lo que le mostrará al usuario una página web y obtendrá su acuerdo. Posteriormente, el RP-STS emitirá un token de seguridad y lo redirigirá a su aplicación. Su aplicación, como siempre, manejará las afirmaciones y hará lo que debe hacer para autorizar el acceso. No lo sabrá y no le importará que el usuario haya sido "reaprovisado". Alternativamente, puede mantener los cambios en sincronización entre la tienda de identidad (es decir, su directorio corporativo) y la tienda de reclamos de su RP-STS utilizando un producto como ILM (o FIM como ahora se llama). Dependiendo de su sistema, un producto que retrocede la sincronización del canal como esta podría ser más apropiado.

¡Por cierto, estas no son preguntas "tontas"! Hay preguntas muy agudas que reflejan un pensamiento profundo y una reflexión inteligente sobre un problema muy complicado. Otros que deberá responder incluyen:

• ¿Cómo actualizan los administradores de su aplicación su política (por ejemplo, cambian los T&C)? ¿Qué UI/API debes crear? ¿La interfaz de usuario está integrada con la utilizada para administrar la política de IP-SSS?
• ¿Qué tipo de relaciones de confianza deben existir para que ese sistema funcione?
• ¿Qué pasa si el sujeto no está usando el perfil pasivo? ¿Qué pasa si usa el perfil activo y/o no hay UI?
• ¿Cómo y dónde se encuentran las llaves? ¿Qué permisos se necesitan para usar esas claves? ¿Cómo se revitan, distribuyen y cómo se alertan a los administradores del SYS cuando están a punto de expirar?

Esto es realmente fácil de demostrar en las reuniones del grupo de usuarios y en las conferencias, pero en realidad es muy avanzado. Si tiene otras preguntas, no dude en publicarlas aquí o Póngase en contacto conmigo directamente.