5

IIS 7.5 パブリック サーバー上でフォーム認証を使用して Saas ASP.NET 3.5 Web アプリケーションを実行しており、数千のユーザーのコンテンツが保護されています。ASP.NET MVC 2 を実行するサブアプリケーションもいくつかあります。

ユーザー名とパスワードはデータベースに保存され、すべてのユーザーにはロールとグループが関連付けられており、権限とアクセス権が定義されています。

現在、ユーザーがログインするためにユーザー名とパスワードを 2 回入力する必要がないように、Active Directory を介したシンプルな SSO ログインも容易にするよう求められています。これらのユーザーは、異なるネットワークとドメインから発信されます。

サーバーから LDAP サーバーへのユーザーの「同期」は行われません。すべてのユーザーがシステムで作成され、そこで維持されるため、LDAP との通信が必要かどうかはわかりません。フォーム認証は、ほとんどのユーザーに使用されます。

ここから先は、どちらを選択するのが最善かはわかりません。私たちのシナリオでは、どのような「ベスト プラクティス」を進める方法でしょうか?

4

2 に答える 2

5

簡単な答えは SAML です。これは「ベスト プラクティス」と見なされており、多くの大規模な SAAS プロバイダーがサポートしています。

SAML プロトコルは、複数のシステム間のシングル サインオン フローを定義します。証明書を使用してシステム間の信頼を確立します。アプリケーションは、他のシステムからの属性 (ユーザー ID、名前、電子メール アドレスなど) を含むアサーションを受け入れます。アプリは、ユーザーをユーザー ストアにマップします。

.NET の世界では、いくつかのオプションがあります。SAML を実装するライブラリ (ComponentSpace に 1 つある) を見つけて、それを ASP.NET 認証にフックすることができます。Windows Identify Framework (WIF) を使用して独自のものを作成できます。これは、WIF ビデオのボートロードです。IdentityServer http://thinktecture.github.io/を試すことができます

アプリの安全性に応じて、簡単な方法を使用して信頼できるネットワークからユーザー ID を渡す簡単なオプションを選択できます。ユーザー ID を URL パラメーターまたはフォーム フィールド経由で送信できるアプリを見てきました。もちろん、これは恐ろしく安全ではなく、より多くのリスクを負うことになります.2 つのネットワーク間の信頼は暗号化されていないためです. リファラー文字列または IP アドレスを確認することで、ある程度軽減できます (たとえば、企業ネットワークの IP 範囲を分離できる場合)。ただし、HTTP 要求内のユーザー ID を置き換えるだけで、ユーザーが他のユーザーになりすますことができるため、なりすましの可能性は依然としてあります。

おそらくあなたの質問に完全に答えるわけではありませんが、うまくいけば正しい方向に向けることができます。

于 2013-04-15T19:02:23.890 に答える
1

ADFS 2.0 を検討することをお勧めします。ADFS 2.0 はクレーム マッピングに関して非常に強力であり、AD と連携します: http://msdn.microsoft.com/en-us/magazine/ee335705.aspx

作成するのは、認証ループの後に Web サーバーに返される最終的なクレームを受信して​​解析するアプリのトークン消費部分です。

于 2013-04-15T19:05:26.887 に答える