Comment utiliser System.IdentityModel dans sa propre application client-serveur

StackOverflow https://stackoverflow.com/questions/646395

  •  22-07-2019
  •  | 
  •  

Question

J'ai une application client-serveur simple basée sur TcpClient / TcpListener et SslStream. Les clients peuvent s’authentifier auprès du serveur à l’aide d’un certificat X509 ou en envoyant un nom d’utilisateur et un mot de passe après l’établissement de SslStream.

WCF utilise l'espace de noms System.IdentityModel à des fins d'authentification, mais apparemment pouvant être utilisé dans des applications arbitraires - ce qui semble intéressant. Les informations sur la procédure à suivre sont toutefois rares (ou mon foo Google est faible aujourd'hui).

Ma question est donc la suivante: Que dois-je faire pour intégrer System.IdentityModel à mon application? Je ne suis pas sûr d'avoir besoin de tous ces éléments de ClaimSet, mais ce serait bien si les utilisateurs peuvent se connecter simplement en utilisant leur compte Windows ou tout autre mécanisme d'authentification fourni. (Malheureusement, je ne peux pas simplement passer à WCF mais utiliser le protocole personnalisé, bien que je puisse y apporter des modifications si nécessaire.)

Était-ce utile?

La solution

Mon foo Google était vraiment faible. La réponse est juste derrière le lien dans ma question. Voici donc quelques liens vers ce blog au cas où quelqu'un aurait éventuellement la même question.

Tout d’abord, vous devez essayer de comprendre "ce que sont les revendications":

Ensuite, vous devez savoir d’où proviennent les ensembles de revendications:

Armé de cette connaissance, cela devient en réalité assez simple.

Si je le comprends bien, le flux de travail de base ressemblerait à ceci:

  1. Le client crée un SecurityToken à l'aide d'un SecurityTokenProvider
  2. Le client sérialise le SecurityToken à l'aide d'un SecurityTokenSerializer
  3. Le serveur désérialise SecurityToken à l'aide d'un SecurityTokenSerializer
  4. Le serveur crée des IAuthorizationPolicy à l'aide d'un SecurityTokenAuthenticator
  5. Le serveur crée un AuthorizationContext à partir de IAuthorizationPolicy s
  6. terminé

Exemple: 

// Create the SecurityTokenProvider
var p = new UserNameSecurityTokenProvider("username", "password");

// Get the SecurityToken from the SecurityTokenProvider
var t = p.GetToken(TimeSpan.FromSeconds(1.0)) as UserNameSecurityToken;

// ... transmit SecurityToken to server ...

// Create the SecurityTokenAuthenticator
var a = new CustomUserNameSecurityTokenAuthenticator(
    UserNamePasswordValidator.None);

// Create IAuthorizationPolicies from SecurityToken
var i = a.ValidateToken(t);

// Create AuthorizationContext from IAuthorizationPolicies
var c = AuthorizationContext.CreateDefaultAuthorizationContext(i);
ShowClaims(c.ClaimSets);

Pour les X509SecurityToken , utilisez un X509SecurityTokenProvider / Authenticator . Pour WindowsSecurityToken , il existe un WindowsSecurityTokenAuthenticator mais pas un fournisseur; utilisez plutôt le constructeur WindowsSecurityToken : 

var t = new WindowsSecurityToken(WindowsIdentity.GetCurrent());

Cela fonctionne assez bien. La seule chose que j'ai omise jusqu'ici est la sérialisation des jetons. Il existe une classe SecurityTokenSerializer qui a une implémentation dans le framework .NET: la classe WSSecurityTokenSerializer fournie avec WCF.

Les

Sérialisation des UserNameSecurityToken et des X509SecurityToken fonctionnent comme un charme (je n'ai pas essayé la désérialisation), mais les WindowsSecurityToken ne sont apparemment pas pris en charge par le sérialiseur. Cela me laisse avec les deux méthodes d'authentification que j'ai déjà (certificats et nom d'utilisateur / mot de passe) et, comme je ne voulais pas que AuthorizationContext , je m'en tiendrai à ce que j'ai:)

Autres conseils

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top