ADFSは他のSSOサービスに接続できますか？

私のローカルADFSサーバー（企業のADサーバーに接続されている）に接続されている.netアプリケーションがあり、すべてが正常に動作しています。私の質問は、ADFSがAzure AD、AWS、Googleログイン、Facebook、Twitter、OpenIDなどのインターネット上の追加のSSOサービスへの信頼できる接続を確立して、アプリケーションが私の以外の複数の信頼できるソースからの要求を使用できるようにすることですディレクトリをアクティブにしますか？

私はこれをやった。このモデルでは、3つのユーザーセットがあります。

1. ローカルAD FSインスタンスに対してActive Directory（KerberosまたはNTLM）を介して認証する内部ユーザー。このセットでは、AD FSサーバーはIdPとして実行されます。

2. 独自のAD FSインスタンスおよびドメインに対してActive Directory（KerberosまたはNTLM）を介して認証する外部ユーザー。このセットでは、AD FSサーバーには、発行元のAD FSサーバーに対して構成されたクレームプロバイダー信頼があります。AD FSサーバーは、他の場所で発行された要求を変換および検証し、アプリケーションに信頼されたトークンを再発行することにより、SP-STSとして動作します。IdPは他のドメインのAD FSサーバーであり、AD FSサーバーは証明書利用者として構成されています。

3. 企業ログインのない外部ユーザー。これらのユーザーは、AD FSサーバーでクレームプロバイダー信頼として構成されている小さな.Net STSに対して認証します。（この役割にAzure Active Directory B2Cを使用することも検討しました-技術的に簡単でしたが、他の懸念事項がそれを防ぎました。）

トークンは次のように発行されます。

お客様に対して透過的にするために、IP範囲を使用して（nginx経由で）検出し、適切な企業AD FSにリダイレクトします。それ以外の場合は、標準のAD FS HRDページに依存します。

依存パーティをチェーンすることは確かに可能であるようです。この男はそれについての一連の投稿を書いています、ここにそれがあります。アプリを認証するための「ハブ」としてADFSを使用でき、ユーザーのIDが実際に存在するサービスにリクエストをチェーンします。

https://cloudidentityblog.com/2013/06/17/why-use-aad-as-idp-via-ad-fs-rp/

私はこれを自分でやったことがないので、これがどれだけの作業でどのような落とし穴があるかはわかりません。ユーザーが複数のIdPに住んでいる場合、問題が発生する可能性があります。

複数のSSOプロバイダーをネイティブで利用できるように.NETアプリケーションを作成することを妨げるものは何もないことを忘れないでください。

はい、できます。

これらの外部IDPはそれぞれADFSのクレームプロバイダーとして追加され、IDP側ではADFSが証明書利用者として追加されます。

認証すると、ADFSはすべてのIDPをリストするホームレルムの検出画面を表示します。

次に、使用するものを選択します。