複数のSSOとの統合
現在、Open-Idプロトコルを介してSSOと統合されたWebアプリがありました。次に、独自のSSOを備えた別のクライアントを取得し、SAMLプロトコルを介してSSOと統合して、従業員が当社のサイトを認証して使用できるようにする必要があります。別のSSO（SAMLプロトコル）が付属しています。
高速ソリューションでは、サイトを3つの異なるサイトに分割し、それぞれを異なるSSOと統合します。高速ですが、1つだけでなく3つのサイトを維持する必要があるため、非常に悪いです。
それらのサイトを1つに再度マージし、複数のSSOと統合するために私が探しているもの。私はすでにそのようなものを検索しましたが、見つかったすべての解決策は、SSOごとに異なるログインボタンを作成し、それを介してリダイレクトおよび認証することです。
しかし、私たちのクライアントは、彼がそれらのクライアントと統合されていることを誰も知る必要がなく、ログインのためのボタンも1つだけ必要なので、その解決策を拒否しました。
そのための解決策はありますか？
異なるプロトコルを持つ他のSSOに依存する独自のSSOを構築できますか？はい、推奨事項があれば教えてください？
認証プロセスは、どのプロバイダーを使用するかを伝える何らかの方法を必要とします。ただし、3つのサイトは必要ありません。 3つだけのURL。
複数のドメイン名バインディングを使用してサイトをデプロイし、クライアントが接続しているURLを読み取ります。次に、それを必要な認証プロバイダーにマップします。
2つのオプションがあります。
- 一部のSSOプロバイダーでは、それらを介して他のSSOプロバイダーと統合することができます。アプリケーションは、1つのプロバイダーと1つのデータ形式のみを扱います。構成により、情報を交換したり、他の形式に変換したりできます。ルールに基づいて、SSOプロバイダーは、ユーザーが内部で認証されているのか、別のプロバイダーで認証されているのかを判断するために必要な認証情報を使用します。
- 別のプロバイダーにリンクされた複数の認証エンドポイントを提供できます。どちらを使用するかを決定するには、検出を行う必要があります。おそらく、システムにあるユーザー名またはその他の識別子の入力を求め、それに基づいて、残りの認証プロセスのために適切なSSOプロバイダーにリダイレクトできます。
- ユーザーが何らかの方法で使用するプロバイダーを指定できるようにします。ただし、これはクライアントには受け入れられないようです。それが適切であることを彼らに納得させる必要があるでしょう。また、ユーザーが認証する必要があるプロバイダーを知る必要がありますが、これは最高のエクスペリエンスとは限りません。