SAML: Почему сертификат в Подписи?

Я должен реализовать SSO с SAML для веб-сайта моей компании (как полагающаяся сторона). Необходимой частью курса является проверка подписи. Вот часть подписи образца SAML от нашей партнерской компании (сторонняя сторона):

            bW1Os7+WykqRt5h0mdv9o3ZF0JI=    cgrAN4T/UmobhrkkTi3miiRfbo0Z7aakSZjXuTWlZlu9jDptxPNbOFw8ZbYKZYyuW544wQqgqpnG gr5GBWILSngURjf2N45/GDv7HMrv/NRMsRMrgVfFsKbcAovQdLAs24O0Q9CH5UdADai1QtDro3jx nl4x7HaWIo9F8Gp/H1c=    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    

Я просто не понимаю, почему сертификат в подписи?

Я имею в виду, как правило, я получаю сертификат от компании в безопасном виде, поэтому я знаю, что сертификат от них. И когда проверка подписи завершается успешно, я знаю, что наша партнерская компания подписала ее.

Но когда сертификат находится под подписью SAML-Response, любой может отправить его! Единственное, что я знаю, это то, что ответ не был сфальсифицирован. Но дело в том, что я не знаю, кто послал SAML.

Может ли кто-нибудь объяснить мне, как это работает?

Ответы 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.

У вас уже может быть открытый ключ, а это означает, что подпись не должна включать публичный ключ снова, но вы также можете иметь несколько возможных известных отправителей или даже цепочку известных отправителей.

Например, у вас могут быть два доверенных поставщика – в любом случае вы проверяете, что сообщение не было изменено, прежде чем проверять, доверяете ли вы любому провайдеру. Если ключ не находится в подписи, утверждения могут быть немного меньше, но теперь вы должны заранее знать, из какого поставщика удостоверений было получено утверждение.

Итак, действительно, есть две основные причины, по которым открытый ключ находится в подписи:

  1. Проверка тампера выполняется быстрее, чем проверка подлинности, и может быть изолирована, если открытый ключ известен.
  2. Несколько идентификаторов гораздо проще поддерживать, если ключ находится в утверждении.

Причина, по которой указан ключ, заключается в том, что метаданные для поставщика удостоверений могут указывать несколько ключей подписи, и вы можете указать используемый ключ, включив его в подпись. SAML 2.0 требует, чтобы, если ключ не указан с Assertion , он может быть выведен по контексту (из метаданных для утвердившей стороны).

Например, вы можете иметь это в своих метаданных для утверждающей стороны:

      BQUAMCMxITAfBgNVBAMTGGlkcDEudGFuZ29oZWFsdGhkZW1vLmNvbTAeFw0xMzA1 ...snip... ttHq2Wi5J7img1M2zo28hH5DK78S+XerfXHK2HEZYZs=     H24a88h7zlq+pnAxQm0CAwEAAaN3MHUwVAYDVR0RBE0wS4IYaWRwMS50YW5nb2hl ...snip... mg1M2zo28hH5DK78=     

Каждый подписанный XML-элемент может указать, какой ключ используется для подписи. Однако в случае SAML 2.0 этот ключ подписи должен (например) соответствовать тому, который определен в метаданных для стороны, создающей подпись. Если ключ, снабженный сигнатурой, не является доверенным (в данном случае не указан в метаданных), система SAML должна генерировать ошибку при проверке подписи.

Публичная часть сертификата подписи находится в сообщении SAML. Это используется для проверки подписи для самого токена и, конечно же, для того, чтобы позволить получателям рассказать, кто выдал токен и соответствующим образом обрабатывать его.

Тот факт, что в нем есть часть спецификаций цифровой подписи XML, на самом деле это не имеет особого значения для SAML. Без сертификата, как вы могли бы узнать, откуда появился токен, и как вы можете его проверить?

XmlDSig определяет другие методы, вы можете идентифицировать ключ подписи субъектом, серийным номером, hashем и т. Д., Но это предполагает, что принимающая сторона имеет открытый сертификат. Для SAML это может быть не так, следовательно, вложение публичной части сертификата X509.

Проводя довольно поздно, но мне пришлось работать над SAML и найти эти документы. Они дают хорошее представление о SAML – как это работает и какие параметры он ожидает. Должна быть какая-то помощь другим людям, знакомым с SAML.

http://developers.onelogin.com/v1.0/page/intro-to-onelogins-open-source-saml-toolkits

http://developers.onelogin.com/v1.0/page/saml-toolkit-for-ruby-on-rails

Давайте будем гением компьютера.