web-dev-qa-db-ja.com

IdPで開始されたSAML SSOの自己署名証明書

私たちは、お客様とのSAML SSO統合におけるサービスプロバイダーとして機能します。開発とステージのテスト中、通常はメタデータファイルとSSOエンドポイントを交換します。

メタデータを作成するときは、opensslコマンドラインツールを使用して自己署名証明書を生成し、X509Certificateノードの値を次のように設定します。

openssl genrsa -out server.pem 1024
openssl req -new -key server.pem -out server.csr
openssl x509 -req -days 365 -in server.csr -signkey server.pem -out server.crt

さて、質問はですが、productionに行くときに、3番目から正当な証明書を取得する必要があります-パーティー、または単に新しい自己署名証明書を再生成できますか？自己署名のセキュリティを使用する場合、どのような潜在的なセキュリティまたはその他の影響がありますか？

注：サービスプロバイダーとして、この種のIdPによって開始されるセットアップではSAMLメッセージを送信しません。

Pythonを使用して、Djangoおよび djangosaml2パッケージ （これが関連する場合）。

certificatesopensslssosaml
7
alecxe

TL; DR：自己署名証明書は問題なく、少なくとも一部のコンテキストでは推奨されています。 長い有効期間を使用してキーのロールオーバーの問題を回避し、RSAの場合は少なくとも2048ビットのキーを使用してください。

SAML 2.0には、署名の検証と暗号化の受信者として使用する必要がある証明書が含まれていますSAMLメタデータの一部として（技術的にはEntityDescriptor内） 。

メタデータを使用するエンティティは、「既知の適切な」方法でメタデータを検証することになっています。これは、たとえば、信頼できるチャネルを介してのみダウンロードする（たとえば、通常の証明書検証を使用するHTTPSを介して）か、他の信頼できる方法でローカルで取得および検証したメタデータのコピーをローカルに保存します。

実際には、メタデータもXML署名される傾向があり、これにより、たとえばHTTPSによって提供される保護を超えて、整合性検証の追加レイヤーが提供されます。 （これは、偶発的または悪意のある方法でメタデータを簡単に変更できる場所に実際に手動でメタデータをダウンロードして保存する必要があると思われる実装の数を考えると、特に良いことです。少なくともXML署名が検証されず、メタデータが却下されます使用される可能性のある不正なメタデータより。）

上記のメタデータの整合性を確保しながらSAMLメタデータを交換できない場合は、重大なブートストラップの問題があり、それがpossibleであるかどうかさえわかりません。安全な方法でSAMLを使用する。メタデータの一部である証明書を信頼できない場合は、メタデータのelseを信頼できないことを意味します、たとえばエンドポイントURIを含みます。

整合性を確保しながらSAMLメタデータを交換できる場合は、定義により、intended（メタデータに記載されている制限に従う）である信頼できる証明書blobが含まれますに使用され：

  • 認証要求と認証応答を含むすべての受信SAMLデータの署名を検証しますfromメタデータが生成されるエンティティ
  • 暗号化されたSAMLデータの受信者キーとして機能するtoメタデータが生成されるエンティティ（暗号化されたSAML XMLはすべての実装でサポートされているわけではないことに注意）

（信頼されたメタデータからの）その証明書は、定義により信頼されているので、CA署名付き証明書を使用しても、自己署名付き証明書を使用するよりも大きなメリットはありません。したがって、CA署名付き証明書を使用する理由はなく、何らかの理由で使用できません（たとえば、インターネット2では、少なくとも10年の有効期間を持つ証明書を使用することをお勧めします。その長い有効期間の証明書を提供する商用CAを認識してください）。

確かにやや逸話的な例ですが、MicrosoftのActive Directoryフェデレーションサービス（ADFS）は、SAMLメタデータの自己署名証明書に完全に満足しているようですI SP側では、ADFSがIdPとして機能することで、テストとほぼ同じです。

9
a CVn