SAML: Sertifika neden İmzanın içindedir?


104

Şirketimin web sitesi için (güvenen taraf olarak) SAML ile SSO uygulamam gerekiyor. Kurs dışında önemli bir kısım, imzanın doğrulanmasıdır. İş ortağı şirketimizden (hak iddia eden taraf) örnek bir SAML'nin imza kısmı:

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

Anlamadığım şey, sertifika neden imzanın içinde?

Demek istediğim, genellikle şirketten güvenli bir şekilde sertifika alırım, bu yüzden sertifikanın onlardan olduğunu biliyorum. İmzanın doğrulanması başarılı olduğunda, ortak şirketimizin imzaladığını biliyorum.

Ancak sertifika SAML-Response'un imzası içindeyse, herkes gönderebilir! Bildiğim tek şey, yanıtın tahrif edilmediği. Ama önemli olan şu ki, SAML'yi kimin gönderdiği hakkında hiçbir fikrim yok.

Biri bana bunun nasıl çalıştığını açıklayabilir mi?

Yanıtlar:


66

SAML yanıtları, bu imza için bir imza ve bir genel anahtar ile birlikte gelir.

Genel anahtarı, SAML yanıtının içeriğinin anahtarla eşleştiğini doğrulamak için kullanabilirsiniz - başka bir deyişle, yanıt kesinlikle iletideki genel anahtara uygun özel anahtara sahip birinden geldi ve yanıt alınmadı ile oynanmış.

Hangi teknolojiyle çalıştığınızı bilmiyorum ama .Net'te şu şekilde kontrol edebilirsiniz:

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

Bu sadece mesajın söylediği kişiden geldiğini kontrol eder. Mesajın güvendiğiniz birinden geldiğine dair ek bir kontrole ihtiyacınız vardır ve bu kontrol daha yavaştır - iptali içermesi gerekir ve bütün bir sertifika zincirini doğrulaması gerekebilir.

Normalde bu, SAML yanıtlarını kabul edeceğiniz genel anahtarların bir listesi olacaktır.

Ardından, bu iletinin değiştirilmediğini ve güvendiğiniz birinden geldiğini kontrol edebilir, böylece sağlanan SAML özelliklerinde sağlanan kullanıcı ayrıntılarını yetkilendirebilirsiniz.

Sen olabilir zaten imza tekrar genel anahtarı içermesi gerekmez, yani kamu anahtara sahip, ama aynı zamanda birden fazla olası bilinen gönderenler, hatta bilinen gönderenler zinciri olabilir.

Örneğin, iki güvenilir sağlayıcınız olabilir - her iki durumda da sağlayıcılardan birine güvenip güvenmediğinizi kontrol etmeden önce mesajın değiştirilmediğini kontrol edersiniz. Anahtar imzada değilse, iddialar biraz daha küçük olabilir, ancak şimdi iddianın hangi kimlik sağlayıcıdan geldiğini önceden bilmeniz gerekir.

Yani, gerçekten, açık anahtarın imzada olmasının iki ana nedeni vardır:

  1. Kurcalama kontrolü, kimlik kontrolünden daha hızlıdır ve genel anahtar biliniyorsa izole edilebilir.
  2. Anahtar iddia içerisindeyse, birden çok kimliği desteklemek çok daha kolaydır.

3
@svlada, metnin kendisi SSL üzerinden gönderilebildiğinden, SAML onayının kendi şifrelemesine ihtiyacı yoktur - tüm kullanıcı oturumu HTTPS olmalıdır. Bilinen, güvenilir göndericinin beyanı imzaladığına ve tahrif edilmediğine dair doğrulama yeterlidir.
Keith

5
@svlada hiçbir HTTP tabanlı kimlik doğrulama (herhangi bir türden) SSL olmadan yapılmamalıdır. Sertifikayı şifrelemek ortadaki bir kişinin (MitM) onu okumasını engelleyecektir, ancak çerez tabanlı bir MitM saldırısına benzer şekilde sertifikayı yeniden kullanmasını engellemez.
Keith

8
SAML yanıtları yok değil o imza için genel anahtar dahil gerektirir. SAML2 spesifikasyonunun 5.4.5 bölümünde "XML İmzası, <ds: KeyInfo> öğesinin kullanımını tanımlar. SAML <ds: KeyInfo> kullanımını gerektirmez ve kullanımına herhangi bir kısıtlama getirmez. Bu nedenle, <ds : KeyInfo> OLMAYABİLİR. " Ortak anahtar size başka yollarla sağlandıysa, örneğin SAML tüketicisini uygulamadan önce yerel sertifika deponuzda saklanıyorsa imzayı doğrulayabilirsiniz.
Sam Rueby

2
@ Sam.Rueby ah, düzelteceğim. Gördüğüm her uygulama anahtarı içeriyor.
Keith

5
@Jez, tüm bu protokol cehennem kadar kafa karıştırıcı. Temel olarak iddia kendi kendine yetiyor - özel anahtar imzaladığından beri üzerinde oynanıp oynanmadığını kontrol edebilirsiniz. Bunu, o açık anahtara sahip olmadan da yapabilirsiniz (bu nedenle, bu iddianın Dave'den geldiğini ve Dave imzaladığından beri kimsenin onu kurcalamadığını biliyorum, ancak Dave'in kim olduğu veya ona güvenip güvenemeyeceğim konusunda hiçbir fikrim olmayabilir). Ardından, bunu doğruladıktan sonra, güvendiğim ortak anahtar olup olmadığını kontrol edebilirim. Sanırım bunun nedeni son kontrolde bir gecikme olabileceğidir (ben gidip ofise Dave'i tanıyan olup olmadığını sorarken)
Keith

42

SAML yanıtında bir genel anahtarın belirtilmesinin nedeni, bir kimlik sağlayıcısının meta verilerinin birden çok genel anahtar belirtebilmesidir. Bu, kimlik sağlayıcının (onaylayan taraf) SAML yanıtındaki imzayı doğrulamak için kullanılacak doğru ortak anahtarı hizmet sağlayıcıya (bağlı taraf) belirtmesine olanak tanır.

Örneğin, iddia eden tarafın Meta Verileri aşağıdaki gibi görünebilir:

<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, ortak anahtarın dahil edilmesini zorunlu kılmasa da, SAML yanıtlarına genel anahtarı dahil etmeyen herhangi bir kimlik sağlayıcıyla karşılaşmadım. Açık anahtar iddia ile belirtilmezse, kimlik sağlayıcının meta verileri aracılığıyla çıkarılabilir olmalıdır.

Yanıtta gönderilen genel anahtara güvenme açısından, genel anahtar kimlik sağlayıcısının meta verilerinde tanımlananla eşleşmelidir. Bu meta veri ayrıntıları genellikle uygulamanıza erişmek için SSO'yu kullanmak isteyen müşterileriniz tarafından sağlanır - tam olarak hangi ortak anahtarları arayacağınızı bileceksiniz (yani, muhtemelen onlardan size kimlik sağlayıcılarının meta veri url'sini sağlamalarını isteyeceksiniz. meta verilerini alabilir ve genel anahtarlar, yayıncı uç noktası vb. gibi ilgili bilgileri aşağı çekebilirsiniz.

İmzayla birlikte sağlanan ortak anahtar, meta verilerde belirtilmemişse, SAML sisteminin imzayı doğrularken bir hata oluşturması gerekir.


10
Bence bu önemli bir nokta, yanıttaki sertifikanın meta verilerdeki sertifikayla eşleşmesi gerekiyor. Aksi takdirde, yanıtı istediğim sertifika ile imzalayabilir ve doğrulama için genel anahtarını gönderebilirim.
dana

6
Bence bu en iyi cevap, bana öyle geliyor ki diğerleri mesajda belirtilen anahtara karşı mesajı kontrol etmenin size herhangi bir güvenlik sağlamadığı noktayı kaçırıyor ... Yine de mesajdaki anahtarı kontrol etmelisiniz doğrudur! (bu durumda, güvenilir meta verilerde olduğundan emin olmalısınız).
rchampourlier

4
Yukarıdaki yorumlara tamamen katılıyorum - mesajda geçen sertifika kendi başına değersizdir çünkü imzalamanın tüm amacı mesajın güvenilir olduğunu doğrulamaktır. Mesaj güvenilir değilse, paketlenmiş sertifikalar da değildir.
Jez

@jbindel - teşekkür ederim! Mümkünse yeni bir sorum var: Bu SAML sertifikasının mevcut fiziksel sertifikayla eşleşmesi gerekiyor mu, yoksa yalnızca meta veri eşleşmesi elde etmek için mi kullanılıyor? Bunu, bir IdP'nin sertifikalarını yeniden anahtarlamasının operasyonel etkisi hakkında endişelendiğim için soruyorum - bu noktada muhtemelen meta veri anahtarı ile senkronizasyon dışı kalıyor. Eğer 2 berabere kalırsa, yeniden endişeleniyorum. operasyonel etki yani. hem SP hem de IdP, SAML2 anahtarını manuel olarak güncelleyene kadar, tüm SSO'lar başarısız olur ve kusurlu teknik iletişimler varsa TOA kullanıcıları üzerindeki sonuç olarak etkilenir. (aptalca soru olursa özür dilerim)
Pancho

SP meta verileri sertifikayı içermelidir, ancak SP meta verileri hem eski hem de yeni IdP sertifikalarını belirtebilir. IdP sertifikasını güncelliyorsa, bu SP meta verilerine eklenebilir. IdP'nin eski sertifika kullanılarak yapılması gerektiğinde, onu SP meta verilerinden kaldırabilirsiniz. Bu sorduğun şeyi ele alıyor mu? Bunun Shibboleth SP'de mükemmel şekilde çalıştığını biliyorum. SP meta veri dosyasının yalnızca <KeyDescriptor use="signing">, SP tarafından kabul edilecek IdP sertifikaları için öğelere sahip olması gerekir .
jbindel

8

İmza sertifikasının genel bölümü SAML mesajındadır. Bu, jetonun kendisinin imzasını kontrol etmek ve elbette alıcıların jetonu kimin verdiğini söylemesine ve buna göre işlem yapmasına izin vermek için kullanılır.

İçinde olması gerçeği, XML dijital imza özelliklerinin bir parçası, gerçekten SAML'ye özgü bir şey değil. Sertifika olmadan jetonun nereden geldiğini nasıl anlarsınız ve onu nasıl doğrulayabilirsiniz?

XmlDSig başka yöntemler belirtmez, imza anahtarını bir konu, seri numarası, karma vb. İle tanımlayabilirsiniz, ancak bu, alıcı tarafın genel sertifikaya sahip olduğunu varsayar. SAML için durum böyle olmayabilir, dolayısıyla X509 sertifikasının genel bölümünün yerleştirilmesi söz konusu olabilir.


1
"Sertifika olmadan jetonun nereden geldiğini nasıl anlarsınız ve onu nasıl doğrulayabilirsiniz?" - Neden bahsediyorsun? Bir SAML mesajındaki imzaya güvenmek için, zaten bir güvenilen genel sertifikalar listesine sahip olmanız gerekir . IssuerÖğeyi kullanabilir ve verenin sertifikasını buna göre depolayabilir ve bu mesaj için imzayı kontrol etmek için bu sertifikayı seçebilirsiniz.
Jez

2
Jez hiç de doğru değil. Bir CA gibi bir sertifika verene, verdiği bağımsız sertifikalara güvenmek zorunda kalmadan ve her sertifikanın yerel kopyalarını saklamak zorunda kalmadan güvenebilirsiniz.
blowdart

4
blowdart bu, CA tarafından verilen başka herhangi bir geçerli sertifika tarafından imzalanmış saml belirtecine güvendiğiniz anlamına gelir. Bir tane satın almak imkansız değil! @Jez'in belirttiği gibi jetonunuzun doğru kaynaktan geldiğinden emin olmak için, zaten güvenilir genel sertifikalar listesine sahip olmalısınız.
Paz

2
@ Güneş yanlış. Bu aynı CA'ya sahiplerse Wells Fargo'nun Bank of America'nın kimliğine bürünebileceğini söylemek gibi bir şey. Bir X509 sertifikasının, doğru kimlik için doğrulanabilen bir Konu DN'si vardır.
Paul Draper

+1, özellikle bunun XML dijital imza spesifikasyonunun bir parçası olduğunu belirlemek için, acemi için aşikar olmaktan çok daha az ve mesajların gerçekte nasıl işlendiğini anlamak için çok önemlidir, çünkü hemen hemen her SAML uygulaması, bunu yapmak için bir XML kitaplığına dayanır. ağırlık kaldırma.
BryKKan
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.