ASP.Net MVC - OWIN - Windows /個人認証を許可する

Question

現在、個人認証（認証/匿名アクセスのないaccount/login.cshtmlページ）とOWINを使用しているASP.Net MVC 5アプリケーションがあります。正常に動作します。

イントラネットアプリケーションであるため、Windowsアカウント、別のユーザーのWindowsアカウント、またはアプリケーションアカウント（管理者、特別なユーザーなど - これらのアカウントには関連付けられているドメインアカウントはありません）の下でログインできます。

最初のオプションでは、ログイン画面にWindowsのユーザ名を表示したかったので、「ok」ボタンをクリックするだけでログインできます。ユーザー名を取得するために、Visual Studio Projectのプロパティを変更して匿名認証を無効にし、Windows認証を有効にしました。また、web.configを変更し、認証モードをFormsに設定しました。これにより、 "HTTPエラー404.15 - 見つかりません"が発生します。これは、修正するために、以下の提案をOWINによって引き起こさ認証ループに起因すると表示されます。

• ログインコントローラメソッドは、匿名アクセスを許可することを確認し（デフォルトでは、このようのようです）。
• 、またはStartup.authを変更するには、LoginPathプロパティをコメントアウトします。
• またはweb.configを変更するには、appSetting "owin：AutomaticAppStartup"を値 "false"で追加します。その中で（web.configファイルの変更を行うように）エラーや窓のユーザー名とログインページが表示され（System.Threading.Thread.Currentprincipleを使用して取得はありません

私はLOGINPATHの修正のために選んだ、これは動作するように表示されます.Identity.Name）。

ユーザーがOwinContextにログインすると、ユーザー（HttpContext.GetOwinContext（）、GetUserManager（））が存在しないという問題が解決されました。

理想的には、アプリケーションで行われているように認証を行う必要はありませんが、Windowsユーザーを取得できるように、認証ヘッダーを含めるための最初のリクエスト（アカウント/ログインページ）が必要です。

まず、「HTTPエラー404.15」の原因を突き止めて理解したいと思います。 第2に、OWINに認証の変更を働かせるにはどうすればいいですか？コントローラ認証のためにユーザーを永続させるために必要なだけです。

Answer 1

これは単なる推測ですが、誤った設定はあなたが記述した誤った設定によって引き起こされると考えられます。認証モードを「フォーム」に設定していますが、Windows認証を使用するようにプロジェクトを設定しています。混乱する可能性がありますが、Windows認証はフォーム認証ではありません。フォーム認証を使用している場合、ユーザーは、ユーザーストアに対して送信され、検証された（すべての偽造防止を含む）証明書を提供します（私は、ASP.NET IDを使用していると信じています。 "設定）、検証に成功すると設定するクッキーがレスポンスに含まれます。このCookieは、その後の要求の認証に使用されます。

Katana documentationで確認されているように、Windows認証用のミドルウェアは組み込まれていません。マイクロソフトではIISを使用することを想定しています。これにより、Katana OWINミドルウェアプロバイダとWindows認証を組み合わせたが効果的に防止されます。さて、簡単に言葉があります：私たちはまだそれの周りに自分の道を「ハックする」ことができます。

残念ながら、それはまだハックになります。私は認証を「透過的」にする方法を見つけませんでした。（ユーザがログインフォームを開き、ADアカウントの資格情報または個々のアカウントの資格情報すべてが動作します "）。 GoogleやFacebookなどの外部のOWINミドルウェアと同様に、すべてのWindowsユーザーの個人アカウント記録を維持する必要があります。アカウントの作成と関連付けを自動化して、見た目を透明に見せることができます。 Windows認証用に「外部プロバイダ」ボタンを追加することができます。 （別の「AD認証」コントローラに）ようになり、ユーザーを認証する

：

bool userWindowsAuthentication = Request.LogonUserIdentity.IsAuthenticated; 

if (userWindowsAuthentication) { 
    var userStoreDatabaseContext = new ApplicationDbContext(); 
    var userStore = new UserStore<UserModel>(userStoreDatabaseContext); 
    var userStoreManager = new UserManager<UserModel>(userStore); 
    var userWindowsLoginCredentials = GetWindowsLoginInfo(); 

    var existingInternalUser = userStoreManager.FindAsync(userWindowsLoginCredentials.UserName) 

    if (existingInternalUser) { 
     // It means that the user already exists in the internal provider and here you simply authenticate and redirect to destination 
    } else { 
     // It means that the user does not exist. You can automatically create the internal user record here and associate the Windows user with the internal record. 
    } 
} else { 
    // It means that user is not signed in using Windows authentication, so you either want to redirect back to the login page or restrict access or do something else 
} 

あなたが見ることができるように、それは「汚い」です。別のハック：Windows認証のみを受け入れる別のレイヤー（別のアプリケーションまたは仮想アプリケーション）を持つことができます。このアプリはあなたのログインリソースになることができます。ユーザーがWindows ADで認証されている場合は、正しいログインページにリダイレクトできます。リダイレクトリクエストヘッダーにログイン情報を追加することもできますが、そうした場合はヘッダーを暗号化してWindows認証が偽装されないようにする必要があります。メインアプリケーション。再び、汚れているが、働く。