信頼のSSOレベルの外部IDプロバイダー
クライアントとそのSSO実装をどれだけ信頼する必要があるのかと思います。 @our-domain.com用に設定されたIDプロバイダーがあり、そのドメインのほとんどのユーザーはソフトウェアで多くの権限を持ち、クライアントのプライベートデータにアクセスできます。複数のクライアントがあり、ドメインによるホームレルムの検出を使用して、ユーザーをクライアントのIDプロバイダーにリダイレクトします。ユーザーがサインインした後、そのIDプロバイダーに許可されたドメインのリストに対してドメインを検証します。
@gmail.comアカウントを使用するユーザーもいる新しいクライアント（ClientX）があり、ログインするにはIDプロバイダーにリダイレクトする必要があります。もちろん、すべてのGmailユーザーがClientXのIDプロバイダーを使用して認証されることを望んでいないので、そのクライアントがIDプロバイダーに自動的にリダイレクトされるページhttps://login.our-domain.com/ClientXを作成します。しかし、私たちは彼らがいくつのドメインを持つことができるかわかりません、私たちは彼らのアイデンティティプロバイダーが言うすべてを盲目的に信頼すべきですか？私たちがすべてのドメインを信頼するとき、それはまた、誰かが他の誰かになりすましたことを意味します。たとえば、IDプロバイダーは@our-domain.comのふりをすることができます。それは尊敬されているクライアントですが、彼らのセキュリティが失敗した場合、私たちは責任があると思います。
権利は、既知のユーザーに一時的に与えられます。そのため、不明なユーザーには権限がありませんが、セキュリティリスクはClientXにあり、ユーザーは私たちのシステムで別の既知のユーザーであると言っています。また、権限は電子メールアドレスに基づいているため、特定のIDプロバイダーでユーザーを一意に識別することはできません。
私たちが考えたいくつかのオプション：
- ClientXが認証できる固定ユーザーリストを用意します。
- ClientXが認証できるドメインの固定リストを用意します。
- 電子メールアドレスの代わりに識別子を使用するように権利システムを変更して、IDプロバイダーで個人を識別できるようにします。
- クライアントとそのセキュリティシステムを信頼してください。
- 他の提案？
だから私はこれについてのアドバイスを探しています。よくある質問のようですが、これについては何も見つかりませんでした。他のIDプロバイダーをどれくらい信頼しますか？アドバイスは大歓迎です！
IdP提供の識別子だけを使用しないでください。 IdP自体の名前と一緒に使用します。 （たとえば、SAML2では各IdPに独自のエンティティIDがあり、どういうわけかそれをユーザー名と組み合わせるのが一般的であると私は信じています。）したがって、これらを2つの異なるユーザーとして認識します。
ClientX,[email protected]
ClientY,[email protected]
正確に使用する識別子の種類（電子メール、ユーザー名、SIDまたはGUID）はそれほど重要ではありません。IdPが100％提供するテキスト文字列である限り、それだけでは十分ではありません。