ASPネットMVCコアユーザーが

Question

ここで任意のページを閲覧したActive Directoryからのロードユーザデータは私の開発環境です：

• イントラネットサイト
• Active Directoryの認証/承認
• のAspネットコア

ユーザーが最初にアプリケーションの任意のページに入力するときに、Active Directory属性に格納されたデータを取得しようとしています。すべてのユーザーの権利とアクセス許可、employeeid、studentidなどは、AD属性とセキュリティグループに格納されます。いくつかの属性もウェブサイト上に表示する必要があります。

....など

• http://mysite/Home/Index
• http://mysite/Student/Index
• http://mysite/Student/MyJobs
• http://mysite/Staff/Applications

...さんは私のウェブサイトは次のURLを得たとしましょう210

すべてのユーザーは、他のイントラネットポータルから自由にウェブサイトのいくつかの領域/ URLにアクセスすることができ、その基準を満たすためにコードをどこに書くべきかわかりません。問題は、http://mysite/LoginやAuthenticateなどの特定のエントリポイントが存在しないことです。存在する場合は、その単一のエントリポイントでADからすべてのユーザーの詳細と権限をロードできます。

MVC5時代、カスタムグローバル認可属性を使用し、BaseControllerに配置すると、そのADデータを読み込むために他のすべてのコントローラから継承されました。最初のヒット時にADのデータをセッションに入れ、静的クラスを使用してビューに表示し、コントローラで使用します。しかし、MVCコアでいくつかの調査を行ったところ、古くなったとのこともあり、カスタム属性の代わりにAuthorize Policyを使うべきです。

Active Directoryからデータを取得することは、すでに私の古いWebサービスを使用して達成されており、ADをサポートしていない.Netコアについては心配する必要はありません。

私はポリシーに関するチュートリアルを見て、クレームとカスタムユーザーマネージャについて何かを見ました。私はActive Directoryからオブジェクト全体（おそらくScoped Object DI）にデータをロードするためにどのユーザーを使用すべきかを決めることができませんでした。

私は主張にデータをロードする必要が 例：...

var claims = new List<Claim>(); 
claims.Add(new Claim("UserName", "John.Smith", ClaimValueTypes.String, Issuer)); 
claims.Add(new Claim("RefNo", "02343001", ClaimValueTypes.String, Issuer)); 
claims.Add(new Claim("Email", "MyEmail@email.com", ClaimValueTypes.String, Issuer)); 

それとも私がカスタマイズSignInManagerとIdentityUserを書くべき属性？ 例：...

public class ApplicationUser : IdentityUser 
{ 
    public string RefNo { get; set; } 
    public string Email { get; set; } 
} 

はどこでも、私はADと負荷データを確認するために私のコードをそこに置くことができますか？ セッションデータを使用するのではなく、その請求対象オブジェクトにデータを保存する必要がありますか？

私に助言してもらえますか？私が何かを見逃して、私の考えがうまくいかないと批判することは自由に感じてください。

Answer 1

System.DirectoryServicesはまだありません（それはバックログにあります、私は約束します）ので、これを行う場所がいくつかあります。

既に統合認証を使用している場合は、IsInRole（）を呼び出すときに解決されるグループメンバシップのSIDがあるため、基本認証の問題を解決するために、ロールベースのメンバシップ（クレームベースではなく）を使用できます。

フォームベースのメカニズムをサポートしたい場合は、the cookie middleware, rawを使用して、少なくとも単純なログインを行い、Webサービスを呼び出してログインを検証してください。コントローラコードでAPIを照会し、IDクッキーを書き込むことができます。このクッキーは自動的に暗号化されて署名されているため、改ざんできません。

ロールと属性が必要なときに問題が発生します。あなたがクッキールートに向かう場合、アイデンティティにクレームとしてすべてのものを入れて、そのアイデンティティをクッキーとして書き出すことができます。これは、クッキーが最大サイズ（ブラウザに依存しますが、通常は4k未満）を超えていない限り、機能します。チャンクされたCookieを使用できますが、ここでパフォーマンスに影響があります。代わりに、実際に完全に読み込まれたアイデンティティが格納されている別のストア（セッション、redisなど）への参照を入れる参照Cookieを使用できます。

the claims transformation middlewareで、あなたは参照を引き出し、あなたの店に行き、アイデンティティを再水和することができます。

私は正直なところ、このすべてをASP.NET IDにマージしようとしません。これは、アプリケーション内のユーザー情報の唯一のソースであることを意味し、実際にはそうではありません。あなたの唯一のソースはADでなければなりません。

Novell's ldap libraryのコアもあります。これは、Webサービスのアプローチを避けたい場合は、DirectoryServicesにうまく対応する必要があります。