htARTE (HackTricks AWS Red Team Expert) ile sıfırdan kahraman olmak için AWS hackleme öğrenin!

HackTricks'ı desteklemenin diğer yolları: * Şirketinizi HackTricks'te **reklamınızı görmek** veya **HackTricks'i PDF olarak indirmek** için [**ABONELİK PLANLARI**](https://github.com/sponsors/carlospolop)'na göz atın! * [**Resmi PEASS & HackTricks ürünlerini**](https://peass.creator-spring.com) edinin * [**The PEASS Family**](https://opensea.io/collection/the-peass-family) keşfedin, özel [**NFT'lerimiz**](https://opensea.io/collection/the-peass-family) koleksiyonumuz * 💬 [**Discord grubuna**](https://discord.gg/hRep4RUj7f) veya [**telegram grubuna**](https://t.me/peass) **katılın** veya **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)'u **takip edin**. * **Hacking hilelerinizi** [**HackTricks**](https://github.com/carlospolop/hacktricks) ve [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github depolarına **PR göndererek paylaşın**.

# SAML Genel Bakış **Security Assertion Markup Language (SAML)**, kimlik sağlayıcıların (IdP) yetkilendirme kimlik bilgilerini hizmet sağlayıcılara (SP) göndermek için kullanılmasını sağlayarak tek oturum açma (SSO) işlemini kolaylaştırır. Bu yaklaşım, tek bir kimlik bilgisi kümesinin birden çok web sitesinde kullanılmasına izin vererek çoklu oturum açma yönetimini basitleştirir. Kimlik sağlayıcılar ve hizmet sağlayıcılar arasında standartlaştırılmış iletişim için XML'yi kullanır ve kullanıcı kimliğinin kimlik doğrulamasını hizmet yetkilendirmesiyle bağlar. ## SAML ve OAuth Karşılaştırması - **SAML**, SSO oturum açma güvenliği üzerinde daha fazla kontrol sağlamak için kurumlara yöneliktir. - **OAuth**, daha mobil dostu olacak şekilde tasarlanmıştır, JSON kullanır ve Google ve Twitter gibi şirketlerin işbirliğiyle geliştirilmiştir. # SAML Kimlik Doğrulama Akışı **Daha fazla ayrıntı için [https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/)** adresindeki tam yazıya bakın. İşte bir özet: SAML kimlik doğrulama süreci, şemada gösterildiği gibi birkaç adımdan oluşur:  1. **Kaynak Erişim Denemesi**: Kullanıcı, korumalı bir kaynağa erişmeye çalışır. 2. **SAML İstemi Oluşturma**: SP, kullanıcıyı tanımaz ve bir SAML İsteği oluşturur. 3. **IdP'ye Yönlendirme**: Kullanıcı, SAML İsteği tarayıcısı aracılığıyla geçerek IdP'ye yönlendirilir. 4. **IdP İstemi Alır**: IdP, SAML İsteğini alır. 5. **IdP'de Kimlik Doğrulama**: IdP, kullanıcının kimliğini doğrular. 6. **Kullanıcı Doğrulaması**: IdP, kullanıcının istenen kaynağa erişim yetkisini doğrular. 7. **SAML Yanıtı Oluşturma**: IdP, gerekli bildirimleri içeren bir SAML Yanıtı oluşturur. 8. **SP'nin ACS URL'sine Yönlendirme**: Kullanıcı, SP'nin Assertion Consumer Service (ACS) URL'sine yönlendirilir. 9. **SAML Yanıtı Doğrulama**: ACS, SAML Yanıtını doğrular. 10. **Kaynak Erişimi Onaylandı**: İlk olarak istenen kaynağa erişim sağlanır. # SAML İstemi Örneği Bir kullanıcının [https://shibdemo-sp1.test.edu/secure/](https://shibdemo-sp1.test.edu/secure/) adresindeki güvenli bir kaynağa erişim isteğini düşünelim. SP, kimlik doğrulamasının eksik olduğunu tespit eder ve bir SAML İsteği oluşturur: ``` GET /secure/ HTTP/1.1 Host: shibdemo-sp1.test.edu ... ``` SAML İsteği şu şekilde görünür: ```xml ``` Bu isteğin temel unsurları şunlardır: - **AssertionConsumerServiceURL**: IdP'nin SAML Yanıtını kimlik doğrulamasından sonra göndermesi gereken yerin belirlendiği yerdir. - **Destination**: İsteğin gönderildiği IdP'nin adresidir. - **ProtocolBinding**: SAML protokolü mesajlarının iletim yöntemini tanımlar. - **saml:Issuer**: İsteği başlatan varlığı tanımlar. SAML İsteği oluşturulduktan sonra, SP, tarayıcıyı SAML İsteğini HTTP yanıtının **Location** başlığında kodlanmış olarak içeren IdP'ye yönlendiren bir **302 yönlendirmesi** ile yanıt verir. **RelayState** parametresi, işlem boyunca durum bilgisini korur ve SP, SAML Yanıtını aldığında başlangıç kaynağı isteğini tanır. **SAMLRequest** parametresi, ham XML parçacığının sıkıştırılmış ve kodlanmış bir sürümüdür ve Deflate sıkıştırma ve base64 kodlama kullanır. # SAML Yanıtı Örneği [İşte tam bir SAML yanıtı](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/) bulabilirsiniz. Yanıtın temel bileşenleri şunları içerir: - **ds:Signature**: Bu bölüm, bir XML İmzasıdır ve beyanın yayıncısının bütünlüğünü ve otantikliğini sağlar. Örnekteki SAML yanıtı, mesaj için bir `ds:Signature` öğesi ve beyan için başka bir `ds:Signature` öğesi içerir. - **saml:Assertion**: Bu bölüm, kullanıcının kimlik bilgilerini ve olası diğer öznitelikleri içerir. - **saml:Subject**: Beyanda yer alan tüm ifadelerin temel konusunu belirtir. - **saml:StatusCode**: İlgili isteğe yanıt olarak işlemin durumunu temsil eder. - **saml:Conditions**: Beyanın geçerlilik zamanlaması ve belirtilen Hizmet Sağlayıcı gibi koşulları ayrıntılandırır. - **saml:AuthnStatement**: Beyanın konusunun IdP tarafından kimlik doğrulandığını onaylar. - **saml:AttributeStatement**: Beyanın konusunu tanımlayan öznitelikleri içerir. SAML Yanıtını takiben, süreç IdP'den bir 302 yönlendirmesi içerir. Bu, Hizmet Sağlayıcının Assertion Consumer Service (ACS) URL'sine bir POST isteği yapılmasına yol açar. POST isteği, `RelayState` ve `SAMLResponse` parametrelerini içerir. ACS, SAML Yanıtını işlemek ve doğrulamakla sorumludur. POST isteği alındıktan ve SAML Yanıtı doğrulandıktan sonra, kullanıcının başlangıçta istediği korumalı kaynağa erişim sağlanır. Bu, `/secure/` uç noktasına bir `GET` isteği ve başarılı erişimi gösteren bir `200 OK` yanıtı ile gösterilir. # XML İmzaları XML İmzaları çok yönlüdür ve bir XML ağacının tamamını veya belirli öğelerini imzalayabilir. Bunlar yalnızca Yanıt öğelerine değil, herhangi bir XML Nesnesine uygulanabilir. Aşağıda XML İmzalarının temel türleri bulunmaktadır: ### XML İmzasının Temel Yapısı Bir XML İmzası, aşağıdaki temel öğelerden oluşur: ```xml ...