Les revendications personnalisées avec le cadre de Genève et comment «synchroniser» les utilisateurs dans votre application

Question

Peut-être que cette question met en évidence le peu que je sais à propos de gestion des identités de revendications, mais c'est ici.

Si vous utilisez WIF dans une application qui utilise un STS tiers d'identité et qui utilise les revendications personnalisées d'autorisation (quelque chose de pertinent et SpecificTo l'application comme CanCreateFooBar)

1) Comment puis-je gérer les utilisateurs? Par exemple, les utilisateurs de dire AD ou autre fournisseur d'appartenance peuvent être identifiés, mais en interne dans mon système j'ai besoin de savoir à leur sujet et avoir plus d'informations utilisateur qui n'a rien à voir avec Identity (il serait donc logique d'avoir cette information disponible en dehors du système), et que les informations sur l'utilisateur doivent être conservées,
La question est Comment puis-je gérer et créer mes données système (en commençant par les ID) de manière intelligente?
Le scénario exact que j'ai en tête est Un nouvel employé est ajouté à l'entreprise, l'administrateur système crée l'utilisateur pour le domaine avec un rôle particulier, comment mon système peut-il prendre conscience de ce fait? (Je voudrais probablement que le système invite un administrateur du système pour une action

2) Où sont les valeurs de revendication pour ces utilisateurs et rôles stockés et comment puis-je les modifier? Idéalement, je veux être en mesure de changer les périmètres pour un utilisateur et une action particuliers. Y a-t-il des lignes directrices à ce sujet?

Je peux voir que ce sont probablement des questions très boiteuses mais quand je pense à la façon de résoudre le problème, je propose des solutions compliquées ou avec des solutions qui nécessitent beaucoup de duplication (c.-à-d. Je ne suis pas sûr que je suis tout simplement pas penser à ce problème de la bonne manière

Merci

Answer 1

1) Vous ne gérez pas les utilisateurs, pas vraiment. Vous prenez simplement l'IClaimsIdentity et l'utilisez comme source pour votre autorisation. À mon avis, vous ne devriez pas persister les réclamations si vous pouvez partir sans le faire - les réclamations devraient être la source de vos informations d'utilisateur. Si vous voulez construire sur les revendications, puis prendre une référence unique à partir de l'identité des revendications, par exemple adresse e-mail ou ppid/clé de signature OU Hash et l'utiliser pour créer votre propre base de données, et ajouter vos propres informations. Cependant, votre système ne s'éloignera jamais des modifications apportées à une métabase d'identité tierce, et ce, jusqu'à ce qu'un nouveau jeton SAML soit émis et analysé dans votre application.

2) Les valeurs des revendications ne sont stockées nulle part, sauf si vous les stockez. La manière dont vous traduisez cela en autorisations dépend de vous - mais généralement, vous effectuez une transformation des revendications pour prendre en charge les revendications externes et les mapper aux revendications internes à votre application que vous utilisez pour les autorisations. Étant donné que les réclamations proviennent de fournisseurs externes, vous ne pouvez pas les modifier. Vous n'avez aucun lien avec ces fournisseurs.

Answer 2

Comme vous le voyez, la fédération ne réduit pas nécessairement le besoin de provisionnement. C'est un aperçu important qui n'est pas immédiatement évident.

Il y a plusieurs façons d'aborder ce dont:

1. L'utilisation d'un méta ou un produit de répertoire virtuel ou
2. En utilisant « l'approvisionnement JIT » (AKA « provisionnement dynamique » ou « sur le approvisionnement de vol ").

Permettez-moi d'expliquer ce dernier. Cette solution, which I also describe on my blog, comprend deux STS, un IP-STS et un RP-STS. Le premier authentifie uniquement l'utilisateur; le second est spécifique à votre application et sait quelles revendications sont nécessaires pour autoriser les utilisateurs de ce système. L'IP-STS ne peut pas émettre ces attributs spécifiques à l'application, ce qui obligerait votre service d'annuaire d'entreprise à être encombré de toutes sortes d'informations spécifiques à l'application. Au lieu de cela, les attributs pour les utilisateurs qui sont gérés dans ce magasin et émis par l'IP-STS sont de nature générale et applicables à l'utilisateur, quelle que soit l'application qu'ils utilisent. Après s'être authentifié auprès de l'IP-STS et avoir obtenu des revendications d'identité uniquement, le jeton est transmis au RP-STS. Ce service de jeton est étroitement lié à votre application. Il sait de quelles revendications les utilisateurs ont besoin pour accéder à différentes ressources. Il peut convertir les revendications d'identité uniquement en celles qui sont nécessaires pour prendre cette décision de contrôle d'accès. Ainsi, le RP-STS est un transformateur de revendications qui mappe les revendications liées aux identités dans des revendications spécifiques aux applications.

Comment le RP-STS met-il à disposition l'utilisateur? Supposons qu'un nouvel employé soit créé, comme dans votre exemple ci-dessus. Lorsque l'utilisateur accède à votre application, il sera renvoyé au RP-STS. Il ne sera pas connecté, il sera donc renvoyé à l'IP-STS. L'administrateur du système a créé un compte pour lui, il pourra donc se connecter, et son navigateur le ramènera au RP-STS. Le RP-STS va déchiffrer le jeton, obtenir l'identifiant de l'utilisateur (email, PPID, etc.), et voir qu'il ne sait pas qui est l'utilisateur. Ainsi, le RP-STS approvisionnera l'utilisateur. Il le fera en affichant une page Web, par exemple. Il peut collecter des informations qui l'aident à déterminer le rôle de cet utilisateur lors de l'accès au RP. Après cela, l'utilisateur sera approvisionné (c'est-à-dire, un enregistrement sera créé dans sa base de données contenant les valeurs de réclamation pour lui), et le RP-STS émettra un jeton spécifique à votre application et le redirigera là-bas. L'application ne saura pas qu'il a été provisionné; il utilisera simplement les revendications comme il le fait toujours. (Voir pourquoi je l'ai appelé le provisionnement JIT?)

Que faire si les choses changent après que l'utilisateur a été provisionné? D'ACCORD. Imaginez ceci: l'utilisateur a été créé dans le magasin d'annuaires il y a longtemps et a été approvisionné comme décrit ci-dessus dans le RP-STS et il utilise le système avec bonheur depuis longtemps. Ensuite, il y a un changement de politique qui oblige les utilisateurs de votre application à accepter de nouveaux termes et conditions (T & Cs). La prochaine fois que l'utilisateur se connectera à l'application, il sera redirigé vers le RP-STS, vers l'IP-STS, il s'authentifiera et sera renvoyé à votre RP-STS. À ce stade, il remarquera que l'utilisateur doit accepter le nouveau T & Cs, de sorte qu'il montrera à l'utilisateur une page Web et obtenir leur accord. Par la suite, le RP-STS émettra un jeton de sécurité et le redirigera vers votre application. Votre application traitera, comme toujours, les revendications et fera ce qu'elle doit faire pour autoriser l'accès. Il ne saura pas et ne se souciera pas que l'utilisateur ait été simplement "réapprovisionné". Vous pouvez également conserver les modifications de synchronisation entre le magasin d'identités (c'est-à-dire votre annuaire d'entreprise) et le magasin de revendications de votre RP-STS à l'aide d'un produit tel que ILM (ou FIM). En fonction de votre système, un produit qui effectue une synchronisation de canal arrière comme celle-ci pourrait être plus approprié.

BTW, ce ne sont pas des questions "boiteuses"! Il y a des questions très vives qui reflètent une pensée profonde et une réflexion intelligente sur un problème très compliqué. D'autres que vous aurez besoin de répondre comprennent:

• Comment les administrateurs de votre application sont mis à jour sa politique (par exemple, changer le T & Cs)? Quelle interface utilisateur/API devez-vous créer? L'interface utilisateur est-elle intégrée à celle utilisée pour gérer la politique IP-STS?
• What sort of trust relationships must exist to make such a system work?
• Que faire si le sujet n'utilise pas le profil passif? Que faire s'il utilise le profil actif et/ou s'il n'y a pas d'interface utilisateur?
• Comment et où se trouvent les clés? Quelles autorisations sont nécessaires pour utiliser ces clés?Comment sont-ils revus, distribués, et comment les administrateurs système sont-ils alertés lorsqu'ils arrivent à expiration?

Ce truc est vraiment facile à faire lors de réunions de groupes d'utilisateurs et lors de conférences, mais en réalité c'est très avancé. Si vous avez d'autres questions, n'hésitez pas à les poster ici ou get in touch w/ me directly.