2009-11-09 5 views
74

Я должен реализовать SSO с SAML для веб-сайта моей компании (как полагающаяся сторона). Необходимой частью курса является проверка подписи. Вот подпись часть образца SAML от нашего партнера компании (утверждающая сторона):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-Response, любой мог отправить его! Единственное, что я знаю, это то, что ответ не был сфальсифицирован. Но дело в том, что я не знаю, кто послал SAML.

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

ответ

6

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

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

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

+1

«Без сертификата, как вы могли бы сказать, где маркер пришел, и как вы могли бы подтвердить это?» - О чем ты говоришь? Чтобы доверять сигнатуре в сообщении SAML, вы должны * уже * иметь список доверенных общедоступных сертификатов. Вы можете использовать элемент 'Эмитент' и сохранить сертификат этого эмитента, и выбрать этот сертификат, с помощью которого можно проверить подпись для этого сообщения. – Jez

+0

Неверно даже Джез. Вы можете доверять эмитенту сертификатов, например ЦС, без необходимости доверять отдельным сертификатам, которые он выпускает, и без необходимости хранить локальные копии каждого сертификата. – blowdart

+2

blowdart означает, что вы доверяете токену saml, подписанному любым другим действительным сертификатом, выпущенным CA. Купить его невозможно! Чтобы ваш токен исходил из правильного источника, поскольку @Jez упоминал, что у вас уже должен быть список доверенных публичных сертификатов. – Sun

48

Ответы 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. Несколько идентификаторов намного проще поддерживать, если ключ находится в утверждении.
+0

Как насчет шифрования части истории? Должен ли IDP шифровать ответ с открытым ключом SP? Таким образом, SP может расшифровать входящий ответ. – svlada

+2

@svlada утверждение SAML не нуждается в собственном шифровании, так как сам текст может быть отправлен через SSL - весь сеанс пользователя должен быть HTTPS. Учитывая, что проверка, что известный, доверенный отправитель подписал это утверждение и что он не был подделан, достаточно. – Keith

+0

Но если SSL отсутствует, сообщения должны быть зашифрованы? – svlada

27

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

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

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

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

+6

Я думаю, что это важный момент, когда сертификат в ответе должен соответствовать сертификату в метаданных. В противном случае я мог бы подписать ответ с любым сертификатом, который мне нужен, и отправить его открытый ключ для проверки. – dana

+4

Я думаю, что это лучший ответ, мне кажется, что другие не понимают, что проверка сообщения против ключа, объявленного в самом сообщении, не дает вам никакой безопасности ... Вы все равно должны проверить ключ в сообщение правильно! (в этом случае вы должны убедиться, что оно находится в надежных метаданных). – rchampourlier

+2

Полностью согласен с приведенными выше комментариями - сертификат, переданный в сообщении, является «бесполезным» сам по себе, потому что весь смысл подписания - убедиться, что сообщение заслуживает доверия. Если сообщение не заслуживает доверия, то и сертификаты в комплекте. – Jez

1

Публикация довольно поздно, но мне пришлось работать над 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

+0

У меня есть вопрос относительно этого, наш новый поставщик НЕ включает сертификат в ответ, поэтому у меня нет тега , хотя я загрузил их сертификат в медатаду, которую они мне предоставляют (IDP Initiated, я SP). Так что это не работает, и мне интересно, потому что они не могут добавить его в ответ, как я полагаю, это так? Должен ли я просто добавить его в местный магазин или что-то еще? Можно ли отключить часть подписи утверждения? – julien

+0

комментарии, которые в основном связаны с ссылками, не поощряются, поскольку ссылки могут умереть. Вместо этого опубликуйте ключевые выводы из ссылки здесь, на SO. –

 Смежные вопросы

  • Нет связанных вопросов^_^