ADALおよびOWINミドルウェアコンポーネントを使用して、ADFS/Windows Azure ADインスタンスに対してOAuth2を使用してASP.NET Web API 2アプリケーションをセキュリティ保護することについて、ちょうどthis excellent articleが終了しました。複数の認証プロバイダに対してASP.NET Web API 2アプリケーションを保護することは可能ですか?
しかし、この記事で説明している認証ワークフロー全体は、HTTP要求パイプラインに非常に "ハードワイヤード"であり、他の認証プロバイダに対して認証ワークフローを実装する余地はありません。
なぜこれが必要ですか?
APIエンドポイントに対してユーザー関連データの要求を発行するために、「内部」ユーザーと「外部」ユーザーの認証が許可されているモバイルWebクライアントがあります。
「内部」ユーザーがAzure AD/ADFSから認証トークンを取得している間、「外部」ユーザーは別の種類の認証トークンを発行する別のシステムに対して認証する必要があります。
したがって、異なる認証トークンの正しい評価ワークフローを開始するために、APIエンドポイントレベルの「内部」ユーザーと「外部」ユーザーの要求を区別することができなければなりません。
これを達成する方法に関する兆候は高く評価されます。
よろしく、マティアス
私はあなたのユースケースが何であるかわからないが、これはthinktectureがidentityserver3で使用する例のいくつかのように思えます。 https://identityserver.github.io/Documentation/。例を取りに行くのに週末が必要でしたが、それはかなり簡単でした。管理画面を提供したidentityrebootも追加しました。 – Bill
こんにちは。ヒントをありがとう。これは間違いなく[認証トークンのカスタム検証を実装する]ことができます(https://identityserver.github.io/Documentation/docsv2/configuration/serviceFactory.html)。 –