La conséquence la plus immédiate d'un grand nombre de revendications est la baisse des performances, car le jeton est échangé entre deux comptes. tous les systèmes impliqués à travers le réseau. Par défaut, WIF, par exemple, sérialise le jeton et les place dans des cookies. Donc, en pratique, vous êtes également limité dans la quantité de données que vous pouvez y stocker. Il y a d'autres façons de gérer cela, mais le problème sous-jacent persiste. La deuxième considération est de savoir qui et où allez-vous gérer l'association entre l'utilisateur et le compte. Si c'est une application spécifique, il est peu probable que vous poussiez ces associations à un STS central (émetteur de réclamations). Vous allez vous retrouver avec 2 STS: celui qui identifie les utilisateurs (et le fournisseur d'identité: IdP) et un STS spécifique à l'application qui transformera le jeton émis par l'IdP en quelque chose sous-tendant l'application (y compris la liste de compte pour un utilisateur particulier) Cela dit, il se peut que l'association entre un utilisateur et ses comptes soit réutilisable dans de nombreuses applications, alors il serait logique de la mettre derrière un STS spécialisé.
Il y a une troisième considération qui est la divulgation potentielle non nécessaire de l'information. L'application peut seulement avoir besoin de savoir si l'utilisateur X a accès au compte 123. En fournissant une liste de tous les comptes auxquels l'utilisateur X a accès, vous divulguez plus d'informations nécessaires.
En règle générale, les revendications sont meilleures pour les attributs à «grain grossier». Le contrôle d'accès "à grain fin" est probablement mieux géré dans l'application où vous pouvez utiliser les optimisations d'infrastructure.
Voici un exemple extrême: imaginez un système de fichiers. Voulez-vous coder en tant que revendications les noms des fichiers auxquels un utilisateur a accès? Peu probable, car vous pourriez vous retrouver avec des millions ...
Un autre exemple extrême: si vous vouliez implémenter la sécurité de niveau ligne dans une base de données. Voulez-vous coder comme revendications les row_id pour chaque utilisateur? Peu probable, car il peut y en avoir beaucoup, très spécifique à l'application et aussi parce qu'il est probablement plus facile (et beaucoup plus efficace) de résoudre le filtrage des lignes avec une requête de base de données (exemple d'optimisation d'infrastructure)
Pourquoi avez-vous décidé d'utiliser un cadre d'identité basé sur des revendications au lieu d'écrire votre propre implémentation dans laquelle vous donnerez des autorisations à chaque rôle. Par exemple. Rôle BusinessAccountMaintenance avec une autorisation pour afficher tous les comptes d'entreprise? –
Je ne l'utilise pas encore. Juste une question théorique. Essayer d'envelopper ma tête autour du cadre d'identité basé sur la revendication. – Vitalik