Quel est le rôle du ClaimsPrincipal, pourquoi a-t-il plusieurs identités?
J'essaie de comprendre le modèle de sécurité derrière .NET basé sur les revendications de l'application (Relying Party).
Je sais qu'il y a 2 classes principales:
- ClaimsPrincipal - contexte de sécurité pour le processus en cours
- ClaimsIdentity - stocke des informations sur l'utilisateur - état d'authentification et revendications
Le fait est que ClaimsPrincipal contient juste une collection d'identités et pointe vers celle actuellement utilisée, mais pour autant que je sache, le principal ne contient généralement pas plus d'une identité et même si c'est le cas - l'utilisateur n'est jamais connecté avec 2 ou plus identités.
Pour moi, le ClaimsPrincipal, à part l'utiliser pour obtenir l'identité actuelle, excuse mon ignorance, c'est inutile.
Qu'est-ce qui me manque à part ce que j'ai déclaré et disons une compatibilité descendante en ce qui concerne la classe ClaimsPrincipal?
Le fait est que ClaimsPrincipal contient juste une collection d'identités et pointe vers celle actuellement utilisée mais pour autant que je sache, le principal ne contient généralement jamais plus d'une identité et même si c'est le cas - l'utilisateur n'est jamais connecté avec 2 identités ou plus.
C'est une fausse hypothèse. En fait, le ClaimsPrincipal dans le contexte aura toujours plus d'une identité si votre application nécessite une authentification à facteur n (n> 1).
Essayez de voir les choses de cette façon.
Principal = Utilisateur
Identité = permis de conduire, passeport, carte de crédit, compte Google, compte Facebook, RSA SecurID, empreinte digitale, reconnaissance faciale, etc.
Si vous êtes arrêté par la police, elle ne vérifie pas que vous êtes qui vous prétendez être, sur la base de votre seul permis de conduire. Ils ont également besoin de voir votre visage. Sinon, vous pourriez montrer le permis de conduire de n'importe qui.
Par conséquent, il est logique de savoir pourquoi l'authentification peut et doit parfois être basée sur plusieurs identités. C'est pourquoi 1 ClaimsPrincipal peut avoir un nombre quelconque de ClaimsIdentity.
Un principe de sécurité important est "qui dit", c.-à-d. Faisons-nous confiance à la partie qui fait valoir les réclamations contre l'identité, de sorte que pour un responsable des revendications particulier, nous pouvons avoir des identités différentes, chacune affirmant un ensemble de revendications différent, ce qui nous permet de déterminer le contrôle d'accès général dans l'application,
Prenons l'exemple d'une application d'entreprise qui est authentifiée via l'authentification Windows où nous voulons également affirmer un certain contrôle d'accès en fonction des équipes ou des services qui se trouvent dans la base de données d'application.
À l'aide de ClaimsTransformationManager, nous pouvons unifier ces deux ensembles, c'est-à-dire qu'après l'authentification de l'utilisateur, nous pouvons rechercher l'équipe/le service de l'utilisateur dans la base de données et créer un ensemble de revendications émises par l'application.
Alors maintenant, nous avons les rôles (qui sont des revendications sous le capot) affirmés par Windows et une identité d'application affirmant les revendications personnalisées des équipes ou du département.