Middleware d’authentification ASP.NET Core 2.0

Donc, après une longue journée d’essayer de résoudre ce problème, j’ai finalement compris comment Microsoft voulait que nous fabriquions des gestionnaires d’authentification personnalisés pour leur nouvelle configuration de middleware unique dans Core 2.0.

Après avoir parcouru une partie de la documentation sur MSDN, j’ai trouvé une classe appelée AuthenticationHandler qui implémente l’interface IAuthenticationHandler .

À partir de là, j’ai trouvé une base de code complète avec les schémas d’authentification existants situés à l’ adresse https://github.com/aspnet/Security.

À l’intérieur de l’un d’eux, il montre comment Microsoft implémente le schéma d’authentification JwtBearer. ( https://github.com/aspnet/Security/tree/dev/src/Microsoft.AspNetCore.Authentication.JwtBearer )

J’ai copié la plupart de ce code dans un nouveau dossier, et j’ai éliminé tout ce qui concernait JwtBearer .

Dans la classe JwtBearerHandler (qui étend AuthenticationHandler<> ), il existe un remplacement pour la Task HandleAuthenticateAsync()

J’ai ajouté à notre ancien middleware pour configurer des revendications via un serveur de jetons personnalisé, et rencontrais toujours des problèmes avec les permissions, en ne faisant que cracher un 200 OK au lieu d’un 401 Unauthorized lorsqu’un jeton était invalide et qu’aucune réclamation n’était établie.

J’ai réalisé que j’avais remplacé Task HandleChallengeAsync(AuthenticationProperties properties) qui, pour quelque raison que ce soit, est utilisé pour définir des permissions via [Authorize(Roles="")] dans un contrôleur.

Après avoir supprimé cette substitution, le code avait fonctionné et avait réussi à lancer un 401 lorsque les permissions ne correspondaient pas.

La principale chose à retenir de ceci est que maintenant vous ne pouvez pas utiliser un middleware personnalisé, vous devez l’implémenter via AuthenticationHandler<> et vous devez définir DefaultAuthenticateScheme et DefaultChallengeScheme lors de l’utilisation de services.AddAuthentication(...) .

Voici un exemple de ce à quoi cela devrait ressembler:

Dans Startup.cs / ConfigureServices (), ajoutez:

 services.AddAuthentication(options => { // the scheme name has to match the value we're going to use in AuthenticationBuilder.AddScheme(...) options.DefaultAuthenticateScheme = "Custom Scheme"; options.DefaultChallengeScheme = "Custom Scheme"; }) .AddCustomAuth(o => { }); 

Dans Startup.cs / Configure (), ajoutez:

 app.UseAuthentication(); 

Créez un nouveau fichier CustomAuthExtensions.cs

 public static class CustomAuthExtensions { public static AuthenticationBuilder AddCustomAuth(this AuthenticationBuilder builder, Action configureOptions) { return builder.AddScheme("Custom Scheme", "Custom Auth", configureOptions); } } 

Créez un nouveau fichier CustomAuthOptions.cs

 public class CustomAuthOptions: AuthenticationSchemeOptions { public CustomAuthOptions() { } } 

Créez un nouveau fichier CustomAuthHandler.cs

 internal class CustomAuthHandler : AuthenticationHandler { public CustomAuthHandler(IOptionsMonitor options, ILoggerFactory logger, UrlEncoder encoder, ISystemClock clock) : base(options, logger, encoder, clock) { // store custom services here... } protected override async Task HandleAuthenticateAsync() { // build the claims and put them in "Context"; you need to import the Microsoft.AspNetCore.Authentication package return AuthenticateResult.NoResult(); } } 

Il y a des changements considérables dans l’identité de Core 1.x à Core 2.0, comme l’indique l’article que vous avez mentionné. Le principal changement est de s’éloigner de l’approche du middleware et d’utiliser l’dependency injections pour configurer des services personnalisés. Cela offre beaucoup plus de flexibilité dans la personnalisation d’Identity pour des implémentations plus complexes. Vous voulez donc sortir de l’approche de middleware que vous avez mentionnée ci-dessus et évoluer vers les services. Suivez les étapes de migration dans l’article référencé pour atteindre cet objective. Commencez par remplacer app.UseIdentity par app.UseAuthentication . UseIdentity est déprécié et ne sera plus pris en charge dans les futures versions. Pour un exemple complet de la manière d’insérer une transformation de revendications personnalisée et d’effectuer une autorisation sur la revendication, consultez cet article de blog .