現在、異なるドメインにいくつかの.Netアプリケーションがあり、それぞれに個別のメンバーシップがあります。シングルサインオン（できればシングルサインオフ）とAzureでホストされる一元化されたメンバーシップを使用したフェデレーションログインに移行します。
私たちにとって当然の選択は、すべてのサイトがWIFで認証するAzureのアクセス制御用の独自のIDプロバイダーを作成することであるように見えましたが、将来、非.Netサイトがこれで認証する必要がある可能性があります。
これはまだ許容できるルートですか？
「非 NET ベース」とは、Java アプリケーションのようなものを意味する場合、Java (たとえば、OpenSSO または PingFederate を使用) と ADFS を連携させることができます。
ADFS は ACS と連携できます。
相互運用性に関する ADFS 2.0 ステップ バイ ステップ ガイドが多数あります。
ADFS を削除して、代わりにこれらの他の製品と ACS を単純にフェデレートできるかどうかわかりません。コメントはありますか？
ああ、私は夢中になって、答えを書いた後に証明書利用者の部分に気づきました! ただし、最後の部分は保持されます。ACS は REST を使用し、SAML または SWT トークンを発行するため、それらを理解するアプリケーションはすべて ACS を使用できます。
WIF と ACS では、顧客のサイトに .NET は必要ありません。実際、これを使用する最も簡単な方法は、AD ドメインに対してユーザーを認証し、SAML トークンを ACS に渡すAD フェデレーション サービスを使用することです。
実際、ACS SDK には、Google、Facebook、およびYahooを ID プロバイダーとして使用するように ACS を構成する方法に関する記事が含まれています。
別のシステム (内部 SSO システム、データベースなど) に対して認証する必要がある場合は、ユーザーを認証して適切なトークンを ACS に送信する独自の ID プロバイダーを作成できます。ACS は REST API を使用するため、任意のプラットフォームまたは言語を使用してプロバイダーを作成できます。