これは多かれ少なかれ この質問 で尋ねられたものの逆です。
私は最近、SAMLを使用したSSOをSaaS Webアプリケーションをサービスプロバイダー(SP)にするWebアプリケーションに追加しました。これは、顧客(企業)が既存のIDプロバイダー(IdP)を使用して、ユーザー(会社の従業員)は、Webアプリケーションで資格情報を維持する必要はなく、単に既存のローカルアカウントを使い続けることができます。
SAMLでは、SPは、認証リクエストをIdPに送信します。このリクエストは、ログインするユーザーに関する認証情報を提供するアサーションで応答します。両方の当事者(SPとIdP)がリクエストとレスポンスがワイヤータッパーによって作成されていないことを確認してください。それらは秘密鍵で署名されています。リクエストとレスポンスの署名を確認するために使用される証明書は、SAMLメタデータ交換の一部として事前に交換されています。関係者の管理者。
問題は次のとおりです:すべての顧客に同じ公開/秘密キーのペアを使用する場合、または別のキーを作成することを推奨する場合、このシステムのセキュリティに重大な欠点がありますか?個々の顧客ごとにペアですか?
この問題のセキュリティについて明確に尋ねています。セキュリティ問題のためにキーを交換しなければならない場合、すべてのお客様がIdPを更新して新しい証明書を組み込む必要があることを知っています。私はまだ決心していませんが、これは許容可能なリスクであると考える傾向があります。これらのキーは隣同士に保存されます。いずれの説明にも違反すると、いずれにしてもすべての顧客に新しいキーが必要になります。
すべてのIDPとすべてのSPは独自のキーペアを持っています。それらの1つに対して新しい証明書を発行する必要があり、それらの1つが別のようにポーズすることを防ぐ場合に、より簡単です。
しかし、これはIDPとWebアプリケーションのキーペアです。あなたは顧客が異なるキーを必要とするかどうか尋ねています。それが本当に問題である場合、エンドユーザーが別のキーを持つ必要があるかどうかは、答えは間違いなくあります。同じように、彼らは異なるパスワードを持っている必要があります。
いくつかのSPが一意のキーを使用してAuthnRequestsに署名するのを見てきましたが、スケーリングが始まるまでこれは続きません。彼らは通常、それらのすべての秘密鍵を管理することは、それらが大きくなるにつれて深刻な苦痛であると判断し、それらに署名するために単一の秘密鍵を使用するように切り替えます。これには何も問題はありません。AuthnRequestに署名すると、秘密鍵の所有者からのものであることが証明され、公開鍵を持つ人なら誰でも検証できます。例として、Salesforceがリクエストに署名するために使用する証明書を here から直接取得できます。
多くの場合、大規模なSP(Salesforceなど)も、IdPがIdPへの応答に署名するために使用する証明書を保持する責任を負っています。 IdPとして、SPの管理者インターフェースにログインし、公開鍵をアップロードします。それを期限切れにした場合、それは彼らの問題ではなくあなたの問題であり、プロセスはスケーリングします。