MSAL.js を使用して、セキュリティ アーキテクチャを ASP.NET Core Identity から Azure AD V2 に移行しようとしています。ASP.NET Core Identity の実装で多くのロールを使用し、Web アプリケーションを使用してデータベースで情報を管理しました。私が放棄しているパターンはこれに似ています。
https://www.dotnetcurry.com/aspnet-core/role-based-security
MSAL を使用した Azure AD が動作しています。トークンが作成されて渡され、ジェネリック[Authorize]属性で装飾されたローカル Web API エンドポイントが期待どおりに受け入れられています。で装飾された Web API エンドポイント[Authorize(Roles= "Fee, Foo, Fi, Fum")]が 401 無許可エラーをスローしています。
ここからどこへ行けばいいのかわからない。Web API の CustomAuthorize 属性オーバーライドを作成し、データベースに戻ってロールを取得しますか。(おそらく、電子メール アドレスに基づいて、DB で定義されたロールをユーザーに一致させます)
また
Azure AD V2 でロールをネイティブに実装する方法はありますか?
ここからの最善の行動方針はわかりません。ドキュメントとコード サンプルは限られているようです。AD ユーザーをグループに入れ、そのグループを Web API の役割として尊重することは確かに素晴らしいことです。一方で、ロールの委任が Web アプリケーションの範囲内で処理されると便利です。
アドバイス、経験、または興味があれば大歓迎です。
答え
私の質問に続きます。@Marc、あなたは正しいです。トークンを見た後、ロールは存在しません。トークンに役割を追加することは、かなり簡単に思えます。グラフ スキーマにパッチを適用してそれらを含める必要があります。ロールを構成し、必要に応じて AAD を介してユーザーに割り当てます。
というか、一見そう見える。より深く掘り下げた後、ユーザーごとに月額6ドルの追加費用しかかからないP1またはP2エンタープライズライセンスが必要です. これにより、クラウドでメールをホストするコストが文字通り 2 倍になります。
別の方法として、WebAPI 用の CustomAuthAttribute を作成し、サーバー バックエンドでユーザーとロールを結び付けました。ロールは引き続き Web アプリケーション経由で管理でき、ユーザーは引き続き Active Directory 資格情報を使用してログインできます。