このテーマに関する多くの情報を見つけました。ただし、私の特定のシナリオを実装する方法はあまりありません。残念ながら、うちの会社のADはいわば妊娠中。ユーザーはそこにいますが、それだけです。
私はイントラネットを作成していますが、Windows 認証を使用してユーザーを認証する必要があることは明らかです。ただし、AD にはイントラネットで通常使用される追加情報 (ユーザーの階層、各従業員に関連付けられた管理者と部門など) が含まれていないため、そのニーズを満たすために Identity を使用したいと考えました。また、AD グループを利用していますが、そのセットアップを取得するのは非常に難しく、AD の代わりに ID をロール ベースの承認に使用したいと考えています。
Identity はかなり新しいものですが、理解するのは簡単で、Windows 認証は簡単に実装できます。
私が欠けているのは、この 2 つを結び付けるノウハウです。
だから私のシナリオは - Windows 認証でユーザーを認証します。認証されたら、役割ベースの承認 (要求?) およびその他のメタデータ (ユーザー情報やアプリケーション固有のデータなど) のために Identity に切り替えます。
この質問が尋ねられたのを見たことがありますが、それが本当に単純なのか、それとももっとあるのかはわかりません。そして、それが本当に私のシナリオに合っているかどうかはわかりません。そして、この質問はまさに私が求めているもののようですが、回答はありません。最後に、メンバーシップ プロバイダーを使用しているにもかかわらず、この質問は私が求めているものにさらに近いようです。これはIdentityでも同様ではないでしょうか？
そのため、私の例では、Windows 認証を使用しているため、ログイン フォームやアクションはありません (ユーザーにユーザー名/パスワードを入力させないという厳格な要件 - それは一見無意味なはずです)。従業員が初めてイントラネットにアクセスする場合、AD で認証しますが、そのユーザーを ID ストアに保存するにはどうすればよいでしょうか? 新しいユーザー (以前にイントラネットにアクセスしたことのない従業員) を、ID に関連付けられたレコードがあることを確認するために、AD を介して認証された後に登録ページに送信することは理にかなっていますか? 次に、登録プロセスの一環として、部門とマネージャーを選択させることができます。登録後、ユーザーが正しい部門とマネージャーを選択したことを確認するために、人による検証プロセスが必要になりますが、今のところ、それは私の心配のほとんどではありません.
推奨事項、リンク、または簡単なガイダンスをいただければ幸いです。ありがとう！