Découvrez quel partenaire fédéré a émis le jeton au format WIF

Question

J'ai une application qui utilise Windows Identity Foundation pour activer la connexion unique fédérée à partir de plusieurs partenaires (appelons-les Org1, Org2, Org3, etc.). Ma configuration WIF contient donc empreintes de tous les certificats partenaires - la configuration ressemble à ceci (les parties non pertinentes omis par souci de concision):

<system.identityModel> 
<identityConfiguration>  
    <issuerNameRegistry type="System.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry"> 
    <trustedIssuers> 
     <add name="Org1" thumbprint="...certificate1..." /> 
     <add name="Org2" thumbprint="...certificate2..." /> 
     <add name="Org3" thumbprint="...certificate3..." /> 
    </trustedIssuers> 
    </issuerNameRegistry> 
</identityConfiguration> 

Cependant, Je ne comprends pas comment déterminer lequel des certificats a effectivement été utilisé lorsqu'un jeton entrant a été validé. C'est-à-dire, comment puis-je savoir si c'est Org1, Org2 ou Org3 qui m'a envoyé le jeton? À-dire, dans le code suivant:

 var authModule = FederatedAuthentication.WSFederationAuthenticationModule; 
     var request = new HttpRequestWrapper(Request); 

     if (authModule.CanReadSignInResponse(request, true)) 
     { 
      var principal = Thread.CurrentPrincipal; 
      var message = authModule.GetSignInResponseMessage(request); 
      var token = authModule.GetSecurityToken(request) as SamlSecurityToken; 
      //??? 
     } 

... Comment puis-je utiliser les variables principal/message/token (ou peut-être une autre méthode tout à fait) pour déterminer si elle était Org1, Org2 ou Org3 qui m'a envoyé le jeton? Je sais environ token.Assertion.Issuer, mais cela semble venir directement du jeton, donc il semble que par exemple. Org1 peut émettre une liste de jetons Org2 en tant qu'émetteur, ce qui entraîne une attaque d'usurpation d'identité. Existe-t-il un moyen d'identifier l'organisation émettrice en toute sécurité, en fonction du certificat utilisé pour la validation du jeton?

Answer 1

j'ai réussi à trouver 2 solutions:

Méthode 1:

Créer une coutume IssuerNameRegistry qui dérive de System.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, et le définir comme votre base de registre de noms (par exemple <issuerNameRegistry type="MyNamespace.MyConfigurationBasedIssuerNameRegistry, My.Assembly.Name">).

Dans votre registre personnalisé, substituez la surcharge GetIssuerName qui prend à la fois un jeton et une chaîne (qui est selon le jeton lui-même l'émetteur du jeton ).

Dans ce remplacement, appelez la base méthode GetIssuerName, et vous récupérerez la propriété name de la déclaration <add thumbprint="..." name="..."> pour le certificat qui a été effectivement utilisé pour vérifier la signature symbolique.

À ce stade, vous avez toutes les informations dont vous avez besoin (à qui le jeton prétend être et de qui il provient). Comparez les deux et renvoyez null si le jeton est usurpé (cela provoquera le rejet du jeton par WIF) ou renvoyez ce que vous avez obtenu de la méthode de base autrement.

Si votre name propriété <add> déclarations est toujours l'URL de l'émetteur jeton prévu, alors tout cela devient très facile:

class ValidatingConfigurationBasedIssuerNameRegistry : ConfigurationBasedIssuerNameRegistry 
{ 
    public override string GetIssuerName(SecurityToken securityToken, string requestedIssuerName) 
    { 
     var configuredName = base.GetIssuerName(securityToken, requestedIssuerName); 
     return (configuredName == requestedIssuerName) ? configuredName : null; 
    } 
} 

MÉTHODE 2:

Comme il est indiqué dans les réponses here, vous pouvez obtenir au Claims sur Thread.CurrentPrincipal as ClaimsPrincipal, et chaque Claim a une propriété Issuer. Il s'avère que cette propriété sera toujours définie sur la propriété name dans l'instruction <add thumbprint="..." name="..."> pour le certificat qui était effectivement utilisé pour vérifier la signature de jeton.

C'est un peu gênant - si vous traitez un signe en réponse Fédération WS, il n'y a aucun moyen de savoir où ce jeton de réponse particulière provenait - vous êtes à la recherche à l'identité actuelle où les demandes pourrait potentiellement provenir de plusieurs sources. Mais je pense que dans des scénarios plus réalistes, cela devrait suffire.