私のローカルADFSサーバー(企業のADサーバーに接続されている)に接続されている.netアプリケーションがあり、すべてが正常に動作しています。私の質問は、ADFSがAzure AD、AWS、Googleログイン、Facebook、Twitter、OpenIDなどのインターネット上の追加のSSOサービスへの信頼できる接続を確立して、アプリケーションが私の以外の複数の信頼できるソースからの要求を使用できるようにすることですディレクトリをアクティブにしますか?
私はこれをやった。このモデルでは、3つのユーザーセットがあります。
ローカルAD FSインスタンスに対してActive Directory(KerberosまたはNTLM)を介して認証する内部ユーザー。このセットでは、AD FSサーバーはIdPとして実行されます。
独自のAD FSインスタンスとドメインに対してActive Directory(KerberosまたはNTLM)を介して認証する外部ユーザー。このセットでは、AD FSサーバーにクレームプロバイダーがあります発行するADに構成された信頼FSサーバー。私たちのAD FSサーバーは、他の場所で発行されたクレームを変換および検証し、信頼できるトークンを再発行することにより、SP-STSとして動作します。 IdPは他のドメインのAD FSサーバーです。ここで、AD FSサーバーは依存パーティとして構成されています。
企業ログインのない外部ユーザー。これらのユーザーは、AD FSサーバー上でクレームプロバイダー信頼として構成されている小さな.Net STSに対して認証を行います。AzureActive Directory B2Cを使用することも検討しました-技術的に簡単でした。この役割は、しかし他の懸念がそれを防いだ。)
お客様にわかりやすくするために、IP範囲を使用して(nginxを介して)検出し、適切な企業ADにリダイレクトしますFS –そうでなければ、標準のAD FS HRDページ。
はい、できます。
これらの外部IDPはそれぞれADFSのクレームプロバイダーとして追加され、IDP側ではADFSが証明書利用者として追加されます。
認証すると、ADFSはすべてのIDPを一覧表示するホームレルムの検出画面を表示します。
次に、使用するものを選択します。
依存パーティをチェーンすることは確かに可能であるようです。この男はそれについて一連の投稿を書いています、ここに一つあります。アプリが認証する「ハブ」としてADFSを使用でき、ユーザーのIDが実際に存在するサービスにリクエストをチェーンします。
https://cloudidentityblog.com/2013/06/17/why-use-aad-as-idp-via-ad-fs-rp/
私はこれを自分でやったことがないので、どれだけの作業が必要か、どのような落とし穴があるかはわかりません。ユーザーが複数のIdPに住んでいる場合、問題が発生する可能性があります。
複数のSSOプロバイダーをネイティブで利用できるように.NETアプリケーションを作成することを妨げるものは何もないことを忘れないでください。