La consecuencia más inmediata de un gran reclamo es un menor rendimiento ya que el token se intercambia de un lado a otro entre todos los sistemas involucrados a través de la red. Por defecto, WIF, por ejemplo, serializa el token y los coloca en las cookies. En la práctica, también está limitado en la cantidad de datos que puede almacenar allí. Hay otras maneras de lidiar con esto, pero el problema subyacente persiste.
La segunda consideración es quién y dónde se administrará la asociación entre el usuario y la cuenta. Si eso es algo específico de la aplicación, es poco probable que impulse esas asociaciones a un STS central (emisor de reclamaciones). Usted terminará entonces con 2 STS: el que identifica a los usuarios (y el proveedor de identidad: IdP) y un STS específico de la aplicación que transformará el token emitido por el IdP en algo que la aplicación utiliza (incluida la lista de cuentas para un usuario en particular)
Habiendo dicho eso, es posible que la asociación entre un usuario y sus cuentas sea reutilizable entre muchas aplicaciones, entonces podría tener sentido ponerlo detrás de un STS especializado.
Hay una tercera consideración que es la posible divulgación innecesaria de información. La aplicación solo necesita saber si el usuario X tiene acceso a la cuenta 123. Al proporcionar una lista de todas las cuentas a las que el usuario X tiene acceso, está divulgando más información que es necesaria.
Como afirmación general, las afirmaciones son mejores para los atributos de "grano grueso". El control de acceso "granular" probablemente se maneje mejor dentro de la aplicación, donde puede usar optimizaciones de infraestructura.
Aquí hay un ejemplo extremo: imagine un sistema de archivos. ¿Codificaría como reclamos los nombres de los archivos a los que tiene acceso un usuario? Improbable, porque puede terminar con millones ...
Otro ejemplo extremo: si desea implementar seguridad de nivel de fila en una base de datos. ¿Codificaría como reclamos el row_id's para cada usuario? Improbable de nuevo, porque podría haber mucho, es muy específico de la aplicación y también porque probablemente sea más fácil (y mucho más eficiente) resolver el filtrado de fila con una consulta de base de datos (este es un ejemplo de optimización de infraestructura)
¿Por qué decidiste utilizar el marco de identidad basado en notificaciones en lugar de escribir tu propia implementación en la que otorgarás permisos a cada función? P.ej. Función BusinessAccountMaintenance con un permiso para ver todas las cuentas comerciales? –
No lo estoy usando todavía. Solo una pregunta teórica. Estoy tratando de entender el marco de identidad basado en reclamos. – Vitalik