ASP.NETコア2.0認証ミドルウェア

Question

は、@ blowdartのアドバイスに従って、カスタム・ミドルウェア実装：

https://stackoverflow.com/a/31465227/29821

それはこのように働いた：ミドルウェアが走った

1. を。リクエストヘッダーからトークンを取得しました。
2. ）トークンを検証し、有効な場合、それは（HttpContext.User.AddIdentityを介して加え、複数のクレームを含まアイデンティティ（ClaimsIdentity）を内蔵。
3. services.AddAuthorizationを使用してサービスを構成しています。ミドルウェアが提供するクレームを要求するポリシーを追加しました。私はその後、[承認（役割=「ミドルウェアが追加したことを、いくつかの役割」）]

これはややトークンが有効でない場合ことを除いて、2.0で動作を使用することになり、コントローラ/アクションで

（ステップ2クレームは決して追加されません。「authenticationSchemeが指定されておらず、DefaultChallengeSchemeが見つかりませんでした」と表示されます。

だから今、私はそれが2.0に変更さAUTH読んでいる：

https://docs.microsoft.com/en-us/aspnet/core/migration/1x-to-2x/identity-2x

を私はASP.NETコア2.0で同じことを行うための正しい道は何ですか？私はあなたが参照する記事が指摘するように、コア2.0コア1.xからアイデンティティにかなりの変更があります...

おかげ

Answer 1

この問題を解決しようとしていた長い一日の後、私は最終的に、コア2.0の新しいシングルミドルウェア設定用のカスタム認証ハンドラをマイクロソフトがどのように作りたいかを考え出しました。

MSDNのドキュメントを調べたところ、AuthenticationHandler<TOption>というクラスが見つかりました。これはIAuthenticationHandlerインターフェイスを実装しています。

そこから、私はこれらのいずれかの内部https://github.com/aspnet/Security

にある既存の認証スキームと全体のコードベースを発見し、それはMicrosoftがJwtBearer認証スキームを実装する方法を示しています。 （https://github.com/aspnet/Security/tree/dev/src/Microsoft.AspNetCore.Authentication.JwtBearer）

ほとんどのコードを新しいフォルダにコピーして、JwtBearerと関係のあるものをすべてクリアしました。

（AuthenticationHandler<>を拡張）JwtBearerHandlerクラスでは、私はちょうど吐き、カスタムトークンサーバを介しての請求を設定し、まだ権限でいくつかの問題に遭遇したために私たちの古いミドルウェアに追加Task<AuthenticateResult> HandleAuthenticateAsync()

のオーバーライドがありますトークンが無効であり、クレームが設定されていない場合は401 Unauthorizedの代わりにを出してください。

コントローラー内で[Authorize(Roles="")]を介してアクセス許可を設定するために何らかの理由でオーバーライドされたTask HandleChallengeAsync(AuthenticationProperties properties)を認識しました。

このオーバーライドを除去した後、コードが働いていた、との許可が一致しませんでしたときに成功401を投げていました。

このからの主なお持ち帰りは今カスタムミドルウェアを使用することができないということです、あなたはAuthenticationHandler<>を経由して、それを実装する必要があり、あなたがDefaultAuthenticateSchemeとDefaultChallengeSchemeservices.AddAuthentication(...)を使用するときに設定する必要があります。追加）（Startup.cs/ConfigureServicesで

：

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 => { }); 

をStartup.cs /設定では（）を追加します

app.UseAuthentication(); 

はここで、これはすべてどのように見えるかの例です

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

0新しいファイルを作成しますCustomAuthExtensions.cs

それは2つのスキームを言いますが、それはuが認証HTTPSに率い与えるにもかかわらず、このリンクを試してみてください新しいファイルCustomAuthHandler.csに

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

Answer 2

を真にカスタム認証を行うには例を見ません。主な変更点は、ミドルウェアのアプローチから離れ、依存性注入を使用してカスタムサービスを構成することです。これにより、より複雑な実装のためにアイデンティティをカスタマイズする際の柔軟性が大幅に向上します。したがって、上記のミドルウェアのアプローチから離れ、サービスに移行したいと考えています。この目標を達成するには、参照記事の移行手順に従ってください。 app.UseAuthenticationでapp.UseIdentityを交換することによって開始します。 UseIdentityは償却されており、将来のバージョンではサポートされません。カスタムクレーム変換を挿入し、クレームに対して承認を実行する方法の完全な例については、view this blog postを参照してください。