問題タブ [msal.js]

Angular アプリケーションでの認証に msal.js を使用しています。これは、を使用した開発ビルドでは問題なく機能しng serveます。残念ながら、ノードを使用してサーバー ビルドを実行しようとすると、このライブラリでエラーが発生します。このビルドは を使用して生成され、 を使用npm run build:prodして提供されnpm run serverます。ノードを使用してこれを提供しようとすると、次のエラーが発生します。

エラーが発生する理由は理解できますが、このサードパーティ ライブラリが必要であるため、プロジェクトからこのパッケージをまとめて削除することはできません。コードのこの部分だけを読み込もうとapp.browser.module.tsしましたが、サーバー側のバージョンをブラウザで実行しようとすると、インジェクション エラーが発生します。

このサードパーティ ライブラリを使用しながら、このプロジェクトの実行可能なサーバー側ビルドを作成する方法を誰かが説明してくれることを願っています。

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 資格情報を使用してログインできます。