113

会社の Web サイトに (証明書利用者として) SAML を使用して SSO を実装する必要があります。もちろん、重要な部分は署名の検証です。以下は、パートナー企業 (アサーティング パーティ) からのサンプル SAML の署名部分です。

<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
 <ds:SignedInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
  <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
  <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
  <ds:Reference URI="#_2152811999472b94a0e9644dbc932cc3" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
   <ds:Transforms xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
     <ec:InclusiveNamespaces PrefixList="ds saml samlp xs" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
    </ds:Transform>
   </ds:Transforms>
   <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"/>
   <ds:DigestValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">bW1Os7+WykqRt5h0mdv9o3ZF0JI=</ds:DigestValue>
  </ds:Reference>
 </ds:SignedInfo>
 <ds:SignatureValue xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
cgrAN4T/UmobhrkkTi3miiRfbo0Z7aakSZjXuTWlZlu9jDptxPNbOFw8ZbYKZYyuW544wQqgqpnG
gr5GBWILSngURjf2N45/GDv7HMrv/NRMsRMrgVfFsKbcAovQdLAs24O0Q9CH5UdADai1QtDro3jx
nl4x7HaWIo9F8Gp/H1c=
 </ds:SignatureValue>
 <ds:KeyInfo>
  <ds:X509Data>
   <ds:X509Certificate>MIIElzCCA3+gAwIBAgIQNT2i6HKJtCXFUFRB8qYsZjANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQG
    EwJGUjEOMAwGA1UEBxMFUGFyaXMxDDAKBgNVBAoTA3BzYTEgMB4GA1UECxMXY2VydGlmaWNhdGUg
    YXV0aG9yaXRpZXMxKDAmBgNVBAMTH0FDIFBTQSBQZXVnZW90IENpdHJvZW4gUHJvZ3JhbXMwHhcN
    MDkwODE5MDcxNTE4WhcNMTEwODE5MDcxNTE5WjCBhjELMAkGA1UEBhMCZnIxHzAdBgkqhkiG9w0B
    CQEWEHBhc3NleHRAbXBzYS5jb20xGDAWBgoJkiaJk/IsZAEBEwhtZGVtb2IwMDEMMAoGA1UEChMD
    cHNhMREwDwYDVQQLEwhwcm9ncmFtczEbMBkGA1UEAxMSVGVzdCAtIFBBU1NFWFQgREVWMIGfMA0G
    CSqGSIb3DQEBAQUAA4GNADCBiQKBgQCuY1nrepgACvDSTLWk5A1cFOJSwDbl6CWfYp3cNYR0K3YV
    e07MDZn+Rv4jo3SusHVFds+mzKX2f8AeZjkA3Me/0yiS9UpS9LQZu9mnhFlZRhmUlDDoIZxovLXN
    aOv/YHmPeTQMQmJZu5TjqraUq7La1c187AoJuNfpxt227N1vOQIDAQABo4IBkTCCAY0wDgYDVR0P
    AQH/BAQDAgWgMB8GA1UdIwQYMBaAFLceWtTfVeRuVCTDQWkmwO4U01X/MAwGA1UdEwEB/wQCMAAw
    gbYGA1UdIASBrjCBqzCBqAYKKoF6ARfOEAEBBDCBmTBBBggrBgEFBQcCARY1aHR0cDovL3JldW5p
    cy5pbmV0cHNhLmNvbS9hdXRvcml0ZS9QQy1BQy1Qcm9ncmFtcy5wZGYwVAYIKwYBBQUHAgIwSDAK
    FgNwc2EwAwIBARo6UG9saXRpcXVlIGRlIENlcnRpZmljYXRpb24gQUMgUFNBIFBldWdlb3QgQ2l0
    cm9lbiBQcm9ncmFtczBcBgNVHR8EVTBTMFGgT6BNhktodHRwOi8vaW5mb2NlcnQucHNhLXBldWdl
    b3QtY2l0cm9lbi5jb20vQUMtUFNBLVBldWdlb3QtQ2l0cm9lbi1Qcm9ncmFtcy5jcmwwHQYDVR0l
    BBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMBYGA1UdDgQPBA1BVVRPX0dFTkVSQVRFMA0GCSqGSIb3
    DQEBBQUAA4IBAQCvRtP6bFkOUEHcqc6yUX0Q1Gk2WaAcx4ziUB0tw2GR9I0276JRJR0EGuJ/N6Fn
    3FhLQrSPmS97Xvc9XmiI66fQUdg64g9YqBecdiQlUkR20VLgI6Nq8pldQlWjU2iYlkP15U7VF4Qr
    0Pb2QiIljZUCKdv3qdED2Ri33za46LfykrlwZB0uhTVUxI/AEtjkKVFaZaqanJg+vJyZI5b30z7g
    Ff8L3ht4Z7SFKdmY3IQSGzElIAAUfduzTJX0cwnGSU9D4BJu1BS8hWnYPwhk+nBJ7OFhXdwYQFWq
    fhpBLq+ciJti9OMhcdCSIi0PbrOqzqtX7hZUQOvfShhCTJnl5TJJ</ds:X509Certificate>
  </ds:X509Data>
 </ds:KeyInfo>
</ds:Signature>

私が理解できないのは、なぜ証明書が署名内にあるのですか?

つまり、通常、私は安全な方法で会社から証明書を取得するので、証明書が会社からのものであることを知っています。そして、署名の検証が成功すると、パートナー企業が署名したことがわかります。

しかし、証明書が SAML 応答の署名内にある場合、誰でも送信できた可能性があります。私が知っている唯一のことは、応答が改ざんされていないということです。しかし要点は、誰が SAML を送信したのかわからないということです。

誰が私にそれがどのように機能するか説明できますか?

4

4 に答える 4

70

SAML 応答には、署名とその署名の公開鍵が付属しています。

公開鍵を使用して、SAML 応答の内容が鍵と一致することを確認できます。つまり、その応答は、メッセージ内の公開鍵と一致する秘密鍵を持っている誰かからのものであり、応答が送信されていないことを確認できます。改ざん。

どの技術を使用しているかはわかりませんが、.Net では次のように確認できます。

// load a new XML document
var assertion = new XmlDocument { PreserveWhitespace = true };
assertion.LoadXml("The SAML XML that you were sent");

// use a namespace manager to avoid the worst of xpaths
var ns = new XmlNamespaceManager(assertion.NameTable);
ns.AddNamespace("samlp", @"urn:oasis:names:tc:SAML:2.0:protocol");
ns.AddNamespace("asrt", @"urn:oasis:names:tc:SAML:2.0:assertion");
ns.AddNamespace("dsig", @"http://www.w3.org/2000/09/xmldsig#");

// get nodes down to the signature
var responseNode = assertion.SelectSingleNode("/samlp:Response", ns);
var assertionNode = responseNode.SelectSingleNode("asrt:Assertion", ns);
var signNode = assertionNode.SelectSingleNode("dsig:Signature", ns);

// load the XML signature
var signedXml = new SignedXml(assertion.DocumentElement);
signedXml.LoadXml(signNode as XmlElement);

// get the certificate, basically:
//     signedXml.KeyInfo[0].Certificates[0]
// ...but with added casting
var certificate = GetFirstX509Certificate(signedXml);

// check the key and signature match
bool isSigned = signedXml.CheckSignature(certificate, true);

これは、メッセージが誰からのものであるかを確認するだけです。メッセージが信頼できる人からのものであることを確認する追加のチェックが必要です。このチェックは時間がかかります。失効を含める必要があり、証明書のチェーン全体を検証する必要がある場合があります。

通常、これは SAML 応答を受け入れる公開鍵のリストになります。

次に、このメッセージが改ざんされておらず、信頼できる人からのものであることを確認できるため、提供された SAML 属性で提供されたユーザーの詳細を承認できます。

すでに公開鍵を持っている可能性があります。つまり、署名に公開鍵を再度含める必要はありませんが、既知の送信者の可能性が複数ある場合や、既知の送信者のチェーンが存在する場合もあります。

たとえば、信頼できるプロバイダーが 2 つある場合、どちらのプロバイダーも信頼できるかどうかを確認する前に、メッセージが改ざんされていないことを確認します。キーが署名に含まれていない場合、アサーションは少し小さくなりますが、アサーションがどの ID プロバイダーからのものかを事前に知る必要があります。

したがって、公開鍵が署名に含まれている主な理由は 2 つあります。

  1. 改ざんチェックは身元チェックよりも高速で、公開鍵がわかっている場合は分離できます。
  2. キーがアサーションにある場合、複数の ID のサポートがはるかに簡単になります。
于 2011-05-26T13:11:49.540 に答える
54

SAML 応答で公開鍵が指定される理由は、ID プロバイダーのメタデータが複数の公開鍵を指定できるためです。これにより、ID プロバイダー (アサーティング パーティ) は、SAML 応答で署名を検証するために使用する正しい公開鍵をサービス プロバイダー (依存パーティ) に指定できます。

たとえば、アサーティング パーティのメタデータは次のようになります。

<KeyDescriptor>
    <ds:KeyInfo>
        <ds:X509Data>
            <ds:X509Certificate>BQUAMCMBgN...XerfXHHEZYZs=</ds:X509Certificate>
        </ds:X509Data>
        <ds:X509Data>
            <ds:X509Certificate>H24a88h7zl...2zo28hH5DK78=</ds:X509Certificate>
        </ds:X509Data>
    </ds:KeyInfo>
</KeyDescriptor>

SAML 2.0 では公開鍵を含めることは義務付けられていませんが、SAML 応答に公開鍵を含めていない ID プロバイダーに出会ったことはありません。公開鍵がアサーションで指定されていない場合、ID プロバイダーのメタデータを介して推測できるはずです。

応答で送信される公開鍵を信頼するという点では、公開鍵は ID プロバイダーのメタデータで定義されているものと一致する必要があります。これらのメタデータの詳細は、通常、SSO を使用してアプリケーションにアクセスしたい顧客によって提供されます。探している公開鍵を正確に把握できます (つまり、ID プロバイダーのメタデータ URL を提供するよう顧客に要求する可能性があります。メタデータを取得し、公開鍵、発行者のエンドポイントなどの関連情報を取得できます)。

署名とともに提供された公開鍵がメタデータで指定されていないものである場合、SAML システムは署名の検証時にエラーを生成する必要があります。

于 2013-06-03T21:54:39.430 に答える
9

署名証明書の公開部分は SAML メッセージにあります。これは、トークン自体の署名をチェックするために使用されます。もちろん、受信者がトークンの発行者を識別し、それに応じて処理できるようにするためにも使用されます。

そこにあるという事実は、XML デジタル署名仕様の一部であり、実際には SAML 固有のものではありません。証明書がなければ、トークンがどこから来たのか、どのように検証できるでしょうか?

XmlDSig は他の方法を指定します。サブジェクト、シリアル番号、ハッシュなどで署名キーを識別できますが、これは受信者が公開証明書を持っていることを前提としています。SAML の場合、これは当てはまらない可能性があるため、X509 証明書の公開部分を埋め込みます。

于 2009-11-09T19:55:58.280 に答える