少し混乱しました。Web サービスのユーザーが LDAP 経由で認証できるようにする WS-Federation がある場合、サービス コードで WS-Federation または System.DirectoryServices 名前空間を使用すると、どのような違いがありますか?
ありがとうございました
少し混乱しました。Web サービスのユーザーが LDAP 経由で認証できるようにする WS-Federation がある場合、サービス コードで WS-Federation または System.DirectoryServices 名前空間を使用すると、どのような違いがありますか?
ありがとうございました
それらの間に比較はありません。
WS-Federation は、シングル サインオン シナリオをサポートするためのプロトコルです。基本的に 2 つのプロファイルをサポートします。1 つはアクティブ プロファイルと呼ばれる Web サービスを使用するクライアントを認証するためのもので、もう 1 つは Web アプリケーションでクライアントを認証するためのパッシブと呼ばれるプロファイルです (http を使用します)。
フェデレーション サービス用の Active Directory は、WS-Federation でユーザーを認証するために Active Directory の上に構築された拡張機能です。
DirectoryServices は、.NET アプリケーションから直接 Active Directory と通信するために使用する API です。認証とは関係ありません。
よろしく、パブロ。
重要なことは、WS-Federation が認証をトークン発行者に委任することです。これにより、ディレクトリ サービス認証コードをトークン発行者に配置し、認証の実装を「気にしない」サービスを設計できます。実装が異なるトークン発行者で複数のエンドポイントを介してクライアントを認証させることもできます。したがって、たとえば、Windows 認証、 username/pass 、またはその他のメカニズムを介して認証するエンドポイントを公開できますが、フェデレーションを介してトークン発行者を信頼するように構成された他のサービスは、トークン発行認証メカニズムをどのように拡張するかを気にする必要はありません。
フェデレーションを「チェーン」して、トークン発行者が特定のエンドポイントでフェデレーション自体を使用するように構成し、トークン発行を完全に異なるトークン発行者に委任することもできます。したがって、この方法では、「facebook を使用してサインイン」、yahoo などのサードパーティの信頼できるトークン発行者を使用して認証を実装できます。これが機能する方法は、フェデレーションがトークン発行者を信頼するようにサービスにセットアップされ、トークン発行者がフェデレーションを使用して Facebook トークンを信頼するように設定します。これにより、DMZ に 1 つのトークン発行者があり、ドメインに別のトークン発行者があり、バックエンドのドメインにサービスがあり、ネットワーク情報やその他のセキュリティ関連情報なしで Web サーバーをバックエンド サービスで認証できるアーキテクチャも可能になります。 DMZ 外の潜在的なハッカーがドメインを利用できるようにします。