ブラウザ証明書は署名された文書であり、CA の公開キーを使用してユーザー エージェントがそれを検証できます。
SAML のメタデータ ファイルにも証明書がありますが、それは別のもののようです。それは何であり、正確には何のために使用されるのでしょうか?
答え1
それは、生産する署名されたドキュメント。IdP のメタデータにある証明書は、アイデンティティ プロバイダー (IdP) によって発行され、サービス プロバイダー (SP) に転送される SAML トークン (「アサーション」) に署名するために使用されます。
アサーションはユーザーの Web ブラウザーを介して転送されるため、ユーザーによる改ざん (たとえば、ユーザーがグループやその他の属性を追加できないようにする) から保護する必要があります。そのため、アサーションは IdP の秘密キーを使用してデジタル署名され、SP はログインを許可する前にその署名を検証します。
つまり、SAML アサーションが OIDC の署名された JWT トークンとほぼ同等である場合、証明書は JWT 署名キーのように使用されます。
(実際、SAML アサーションを「証明書」、発行元の IdP を「認証局」と呼ぶこともできるでしょう...)
さらに、SPは独自の証明書を持つことができ、IdPはそれを使用して暗号化するアサーション (例: シャドウバン ステータスなど、ユーザーに漏洩してはならない内部データが含まれている場合、または SSN のように露出を最小限に抑える必要がある場合)。これはオプションです。
SPが独自の証明書を持つもう一つの理由は、署名できるようにするためです。ログアウト要求これらは IdP に送り返されます。SAML2 プロトコルは「シングル ログアウト」をサポートします。つまり、1 つの SP からログアウトすると、IdP 自体だけでなく他のすべての SP からもログアウトされますが、このプロトコルには、必ずしも相互に信頼していない可能性のある場所を経由する長いリダイレクト チェーンが含まれます。
補足: SAML の証明書は TLS の証明書と同じ種類の「署名済み文書」ですが、大きな違いは、ほとんどの場合、SAML 証明書は自己署名されており、SP は正確な公開鍵のみを気にし、他のすべてのフィールドを無視することです。(実際、X.509 証明書が使用される最大の理由は、SAML が既存の XML-DSig 標準を使用し、すべてのツール/ライブラリが証明書の処理を期待しているためです。) ただし、できなかったCA 発行であること。これはサポートされていますが、ほとんど必要ありません。