Est-il possible d'écrire un test capable de tester un objet AuthorizationPolicy?

Question

J'ai une politique que je veux tester en C#

public class WorkflowCreatePolicy 
{ 
    public AuthorizationPolicy AuthorizationPolicy => 
     new AuthorizationPolicyBuilder() 
      .RequireClaim("scope", "WorkflowAdmin") 
      .Build(); 
} 

Quelqu'un connaît un moyen de tester la AuthorizationPolicy pour confirmer que la portée « WorkflowAdmin » est un succès et tous les autres ne sont pas?

C'est ce que je vois quand je visite l'objet:

J'ai réussi à trouver ce site: Authorization Handler Unit Tests mais son parler de tester les gestionnaires et a le code qui marque la tentative auth le succès .

Je ne suis pas sûr si cela se rapproche ou non. Actuellement, il ne passe pas

[Test] 
public void GivenPolicyName_WhenICallPolicyChecks_ThenItPasses() 
{ 
    ClaimsPrincipal user = new ClaimsPrincipal(new ClaimsIdentity(new List<Claim> { new Claim(CustomClaims.Scope, "WorkflowAdmin") })); 

    WorkflowCreatePolicy workflowCreatePolicy = new WorkflowCreatePolicy(); 

    AuthorizationHandlerContext authorizationHandlerContext = new AuthorizationHandlerContext(workflowCreatePolicy.AuthorizationPolicy.Requirements, user, null); 

    Assert.That(authorizationHandlerContext.HasSucceeded, Is.EqualTo(true)); 
} 

Answer 1

Sous le capot un AuthorizationPolicy est juste une collection de gestionnaires d'autorisation. Des méthodes comme RequireClaim ajoutent des gestionnaires construits par Microsoft à la collection. Dans ce cas, le ClaimsAuthorizationRequirement qui hérite de AuthorizationHandler.

Pour valider si un utilisateur passe un AuthorizationPolicy vous avez besoin d'un AuthorizationService qui appellera toutes les politiques. Le DefaultAuthorizationService s'arrêtera après que le premier gestionnaire n'a pas réussi à authentifier l'utilisateur. Si vous n'enregistrez pas un autre AuthorizationService celui-ci sera utilisé.

Vous pouvez donc créer le AuthorizationService par vous-même et appeler la méthode AuthorizeAsync. Sachez simplement que vous devez aussi enregistrer votre AuthorizationHandler personnalisé si vous voulez tester contre eux.

private static async Task<bool> CanAuthorizeUserWithPolicyAsync(ClaimsPrincipal user, AuthorizationPolicy policy) 
{ 
    var handlers = policy.Requirements.Select(x => x as IAuthorizationHandler).ToArray(); 
    // add your custom authorization handlers here to the `handlers` collection 

    var authorizationOptions = Options.Create(new AuthorizationOptions()); 

    authorizationOptions.Value.AddPolicy(nameof(policy), policy); 

    var policyProvider = new DefaultAuthorizationPolicyProvider(authorizationOptions); 
    var handlerProvider = new DefaultAuthorizationHandlerProvider(handlers); 
    var contextFactory = new DefaultAuthorizationHandlerContextFactory(); 

    var authorizationService = new DefaultAuthorizationService(
     policyProvider, 
     handlerProvider, 
     new NullLogger<DefaultAuthorizationService>(), 
     contextFactory, 
     new DefaultAuthorizationEvaluator(), 
     authorizationOptions); 

    var result = await authorizationService.AuthorizeAsync(user, policy); 
    return result.Succeeded; 
} 

Vous pouvez utiliser cette méthode comme suit.

var user = new ClaimsPrincipal(new ClaimsIdentity(new List<Claim> { new Claim("scope", "WorkflowAdmin") })); 

var policy = new AuthorizationPolicyBuilder() 
    .RequireClaim("scope", "WorkflowAdmin") 
    .Build(); 

Assert.That(await CanAuthorizeUserWithPolicyAsync(user, policy), Is.EqualTo(true)); 

Answer 2

à mon humble avis, c'est quelque chose que vous voulez tester avec integration tests.

Unit testing it is covered by the ASP.NET Core et à la fin de la journée, vous voulez vous assurer que l'accès à vos points d'extrémité est protégé comme prévu.

Que vous pouvez faire avec TestServer.

Il est la composition de l'application qui doit être testé à ce moment: Faire en sorte que l'appel de vos points d'extrémité sans la demande souhaitée entraînera une 403.