SAML: Warum befindet sich das Zertifikat in der Signatur?

Ich muss SSO mit SAML für die Website meines Unternehmens (als vertrauende Partei) implementieren. Ein wesentlicher Bestandteil des Kurses ist die Überprüfung der Unterschrift. Hier ist der Signaturteil einer SAML-Probe unserer Partnerfirma (behauptende Partei):

<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>

Was ich einfach nicht verstehe ist, warum ist das Zertifikat in der Signatur?

Ich meine, normalerweise bekomme ich auf sichere Weise ein Zertifikat von der Firma, also weiß ich, dass das Zertifikat von ihnen stammt. Und wenn die Überprüfung der Unterschrift erfolgreich ist, weiß ich, dass unsere Partnerfirma sie unterschrieben hat.

Aber wenn das Zertifikat innerhalb der Signatur der SAML-Antwort liegt, hätte es jeder senden können! Ich weiß nur, dass die Antwort nicht gefälscht wurde. Aber der Punkt ist, ich habe keine Ahnung, wer die SAML gesendet hat.

Kann mir jemand erklären, wie das funktioniert?

SAML-Antworten werden mit einer Signatur und einem öffentlichen Schlüssel für diese Signatur geliefert.

Mit dem öffentlichen Schlüssel können Sie überprüfen, ob der Inhalt der SAML-Antwort mit dem Schlüssel übereinstimmt. Mit anderen Worten, diese Antwort stammt definitiv von jemandem, der den passenden privaten Schlüssel zum öffentlichen Schlüssel in der Nachricht hat, und die Antwort war nicht manipuliert.

Ich weiß nicht, mit welcher Technologie Sie arbeiten, aber in .Net können Sie dies folgendermaßen überprüfen:

// 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);

Das überprüft nur, ob die Nachricht von dem stammt, von dem sie sagt, dass sie es ist. Sie benötigen eine zusätzliche Überprüfung, ob die Nachricht von jemandem stammt, dem Sie vertrauen, und diese Überprüfung ist langsamer. Sie muss den Widerruf enthalten und möglicherweise eine ganze Kette von Zertifikaten überprüfen.

Normalerweise ist dies eine Liste öffentlicher Schlüssel, von denen Sie SAML-Antworten akzeptieren würden.

Anschließend können Sie überprüfen, ob diese Nachricht nicht manipuliert wurde und von einer vertrauenswürdigen Person stammt, sodass Sie die in den angegebenen SAML-Attributen angegebenen Benutzerdetails autorisieren können.

Sie könnten bereits den öffentlichen Schlüssel haben, was bedeutet, dass die Signatur den öffentlichen Schlüssel nicht erneut enthalten muss, aber Sie könnten auch mehrere mögliche bekannte Absender oder sogar eine Kette bekannter Absender haben.

Beispielsweise haben Sie möglicherweise zwei vertrauenswürdige Anbieter. In beiden Fällen überprüfen Sie, ob die Nachricht nicht manipuliert wurde, bevor Sie überprüfen, ob Sie einem der beiden Anbieter vertrauen. Wenn der Schlüssel nicht in der Signatur enthalten ist, können die Zusicherungen etwas kleiner sein. Jetzt müssen Sie jedoch im Voraus wissen, von welchem ​​Identitätsanbieter die Zusicherung stammt.

Es gibt also zwei Hauptgründe, warum der öffentliche Schlüssel in der Signatur enthalten ist:

1. Die Manipulationsprüfung ist schneller als die Identitätsprüfung und kann isoliert werden, wenn der öffentliche Schlüssel bekannt ist.
2. Mehrere Identitäten sind viel einfacher zu unterstützen, wenn sich der Schlüssel in der Zusicherung befindet.

Der Grund, warum der Schlüssel angegeben wird, besteht darin, dass die Metadaten für den Identitätsanbieter mehrere Signaturschlüssel angeben können. Sie können den zu verwendenden Schlüssel angeben, indem Sie ihn der Signatur hinzufügen. SAML 2.0 erfordert, dass, wenn der Schlüssel nicht mit dem angegeben Assertionist, er durch den Kontext abgeleitet werden kann (aus den Metadaten für die behauptende Partei).

Zum Beispiel können Sie dies in Ihren Metadaten für die behauptende Partei haben:

        <KeyDescriptor>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
BQUAMCMxITAfBgNVBAMTGGlkcDEudGFuZ29oZWFsdGhkZW1vLmNvbTAeFw0xMzA1
...snip...
ttHq2Wi5J7img1M2zo28hH5DK78S+XerfXHK2HEZYZs=
                </ds:X509Certificate>
            </ds:X509Data>
            <ds:X509Data>
                <ds:X509Certificate>
H24a88h7zlq+pnAxQm0CAwEAAaN3MHUwVAYDVR0RBE0wS4IYaWRwMS50YW5nb2hl
...snip...
mg1M2zo28hH5DK78=
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </KeyDescriptor>

Jedes signierte XML-Element kann angeben, welcher Schlüssel für die Signatur verwendet wird. Im Fall von SAML 2.0 muss dieser Signaturschlüssel jedoch (zum Beispiel) mit einem übereinstimmen, der in den Metadaten für die Partei definiert ist, die die Signatur generiert. Wenn der mit der Signatur gelieferte Schlüssel nicht vertrauenswürdig ist (in diesem Fall nicht in den Metadaten angegeben), muss das SAML-System beim Überprüfen der Signatur einen Fehler generieren.

Der öffentliche Teil des Signaturzertifikats befindet sich in der SAML-Nachricht. Dies wird verwendet, um die Signatur für das Token selbst zu überprüfen und den Empfängern natürlich zu ermöglichen, zu erkennen, wer das Token ausgestellt hat, und es entsprechend zu behandeln.

Die Tatsache, dass es dort enthalten ist, ist Teil der Spezifikationen für digitale XML-Signaturen. Es ist eigentlich nichts SAML-spezifisches. Wie können Sie ohne das Zertifikat feststellen, woher das Token stammt, und wie können Sie es validieren?

XmlDSig gibt andere Methoden an. Sie können den Signaturschlüssel anhand eines Betreffs, einer Seriennummer, eines Hashs usw. identifizieren. Dies setzt jedoch voraus, dass die empfangende Partei über das öffentliche Zertifikat verfügt. Für SAML ist dies möglicherweise nicht der Fall, daher die Einbettung des öffentlichen Teils des X509-Zertifikats.