Comment appeler un service WCF à partir d'un test unitaire en tant qu'identité anonyme?

Question

J'ai un SecurityService qui a une méthode AutoLogin, qui utilise le ServiceSecurityContext pour trouver quelle identité Windows appelle, puis essaie de trouver le compte d'utilisateur associé dans la base de données. Cela fonctionne correctement lorsqu'il est appelé à partir d'un site Web qui utilise l'emprunt d'identité et nécessite une sécurité intégrée dans IIS. L'appel utilise le stock NetPipeBinding.

Je voudrais tester le service comme suit:

[TestMethod] 
public void AutoLoginAsAnonymousFails() 
{ 
    using (var anonymousContext = WindowsIdentity.Impersonate(WindowsIdentity.GetAnonymous().Token)) 
    { 
     ISecurityService securityService = ClientChannelManager.CreateSecurityServiceChannel(); 
     var loginResponse = securityService.AutoLogin(); 
     ((ICommunicationObject)securityService).Close(); 
     Assert.IsFalse(loginResponse.IsSuccessful);    
    } 
} 

Du côté du service de l'utilisateur dans le SecurityContext est toujours moi - comment faire un utilisateur anonyme? J'ai déjà essayé d'usurper l'identité de IntPtr.Zero mais sans succès.

Pour référence, la partie pertinente de la méthode de service:

public ResponseMessage AutoLogin() 
{ 
    if (ServiceSecurityContext.Current.WindowsIdentity != null 
     && !ServiceSecurityContext.Current.WindowsIdentity.IsAnonymous 
     && !ServiceSecurityContext.Current.WindowsIdentity.IsGuest 
     && ServiceSecurityContext.Current.WindowsIdentity.IsAuthenticated) 
    { 
     // find the user based on his windows identity and return success = true message 
    } 

    // return success = false message 
} 

Answer 1

Ceci est un exemple classique de la façon dont la séparation des préoccupations pourrait vous aider. Au lieu de s'appuyer directement sur ServiceSecurityContext (quelque chose que vous devriez, IMO, ne faites jamais), assurez-vous de configurer votre service afin que les informations de sécurité soient à la place encapsulées dans Thread.CurrentPrincipal. IIRC, lorsque vous utilisez l'authentification et l'emprunt d'identité Windows, il peut même configurer automatiquement pour vous, mais sinon, vous pouvez toujours écrire un ServiceAuthorizationManager personnalisé, qui le fait pour vous.

Cela vous permettra de faire varier vos problèmes de sécurité indépendamment de la logique de votre domaine. Si vous vous en tenez à l'interface IPrincipal et résistez à la tentation de downcasting vers WindowsPrincipal, votre code sera même prêt pour l'avenir de l'identité: Identité basée sur les revendications, telle qu'implémentée par Windows Identity Foundation (WIF). Ceci aide aussi considérablement avec les tests unitaires, parce que vous pouvez simplement assigner GenericPrincipal à Thread.CurrentPrincipal avant d'appeler votre System Under Test (SUT).