{{#include ../../banners/hacktricks-training.md}}

# SAML Genel Bakış

**Security Assertion Markup Language (SAML)**, kimlik sağlayıcılarının (IdP) hizmet sağlayıcılarına (SP) yetkilendirme kimlik bilgilerini göndermesine olanak tanır ve tek oturum açma (SSO) işlemini kolaylaştırır. Bu yaklaşım, birden fazla web sitesinde tek bir kimlik bilgisi setinin kullanılmasına izin vererek birden fazla oturum açma işleminin yönetimini basitleştirir. IdP'ler ve SP'ler arasında standartlaştırılmış iletişim için XML kullanır ve kullanıcı kimliğinin doğrulanmasını hizmet yetkilendirmesi ile ilişkilendirir.

## SAML ve OAuth Arasındaki Karşılaştırma

- **SAML**, işletmelere SSO oturum açma güvenliği üzerinde daha fazla kontrol sağlamak için tasarlanmıştır.
- **OAuth**, daha mobil dostu olacak şekilde tasarlanmış, JSON kullanmakta ve Google ve Twitter gibi şirketlerin iş birliği ile 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 gönderiyi kontrol edin**. Bu bir özet:

SAML kimlik doğrulama süreci, şemada gösterildiği gibi birkaç adım içerir:

![https://epi052.gitlab.io/notes-to-self/img/saml/saml-flow.jpg](https://epi052.gitlab.io/notes-to-self/img/saml/saml-flow.jpg)

1. **Kaynağa Erişim Denemesi**: Kullanıcı korumalı bir kaynağa erişmeye çalışır.
2. **SAML İsteği 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 kullanıcının tarayıcısından geçerek IdP'ye yönlendirilir.
4. **IdP İsteği Alır**: IdP, SAML İsteğini alır.
5. **IdP'de Kimlik Doğrulama**: IdP, kullanıcıyı kimlik doğrular.
6. **Kullanıcı Doğrulama**: IdP, kullanıcının talep edilen kaynağa erişim yetkisini doğrular.
7. **SAML Yanıtı Oluşturma**: IdP, gerekli beyanları içeren bir SAML Yanıtı oluşturur.
8. **SP'nin ACS URL'sine Yönlendirme**: Kullanıcı, SP'nin Beyan Tüketim Servisi (ACS) URL'sine yönlendirilir.
9. **SAML Yanıtı Doğrulama**: ACS, SAML Yanıtını doğrular.
10. **Kaynağa Erişim Verildi**: İlk talep edilen kaynağa erişim izni verilir.

# SAML İsteği Ö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 talep ettiği durumu düşünün. SP, kimlik doğrulama eksikliğini tespit eder ve bir SAML İsteği oluşturur:
```
GET /secure/ HTTP/1.1
Host: shibdemo-sp1.test.edu
...
```
Ham SAML İsteği şu şekilde görünür:
```xml
<?xml version="1.0"?>
<samlp:AuthnRequest ...
</samlp:AuthnRequest>
```
Bu isteğin ana unsurları şunlardır:

- **AssertionConsumerServiceURL**: IdP'nin SAML Yanıtını kimlik doğrulama sonrası nereye göndermesi gerektiğini belirtir.
- **Destination**: İsteğin gönderildiği IdP'nin adresi.
- **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 bir **302 yönlendirmesi** ile yanıt verir ve tarayıcıyı SAML İsteği'nin HTTP yanıtının **Location** başlığında kodlanmış olduğu IdP'ye yönlendirir. **RelayState** parametresi, işlem boyunca durum bilgisini korur ve SP'nin SAML Yanıtını aldığında ilk kaynak isteğini tanımasını sağlar. **SAMLRequest** parametresi, ham XML parçasının sıkıştırılmış ve kodlanmış bir versiyonudur ve Deflate sıkıştırması ile base64 kodlaması kullanır.

# SAML Yanıt Örneği

[Burada tam bir SAML yanıtı bulabilirsiniz](https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/). Yanıtın ana bileşenleri şunlardır:

- **ds:Signature**: Bu bölüm, bir XML İmzasıdır ve beyanın vericisinin bütünlüğünü ve doğruluğunu sağlar. Örnekteki SAML yanıtı, bir mesaj için ve diğeri beyan için olmak üzere iki `ds:Signature` öğesi içerir.
- **saml:Assertion**: Bu kısım, kullanıcının kimliği ve muhtemelen diğer nitelikler hakkında bilgi tutar.
- **saml:Subject**: Beyandaki tüm ifadelerin ana 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ı detaylandırır.
- **saml:AuthnStatement**: IdP'nin Beyanın konusunu kimlik doğruladığını onaylar.
- **saml:AttributeStatement**: Beyanın konusunu tanımlayan nitelikleri içerir.

SAML Yanıtının ardından, 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ğine yol açar. POST isteği, `RelayState` ve `SAMLResponse` parametrelerini içerir. ACS, SAML Yanıtını işlemekten ve doğrulamaktan sorumludur.

POST isteği alındıktan ve SAML Yanıtı doğrulandıktan sonra, kullanıcının başlangıçta talep ettiği korumalı kaynağa erişim verilir. Bu, `/secure/` uç noktasına bir `GET` isteği ve kaynağa başarılı erişimi gösteren bir `200 OK` yanıtı ile gösterilmektedir.

# XML İmzaları

XML İmzaları çok yönlüdür, tüm bir XML ağacını veya içindeki belirli öğeleri imzalama yeteneğine sahiptir. Herhangi bir XML Nesnesine uygulanabilir, yalnızca Yanıt öğelerine değil. Aşağıda XML İmzalarının ana türleri bulunmaktadır:

### XML İmzasının Temel Yapısı

Bir XML İmzası, aşağıda gösterildiği gibi temel unsurlardan oluşur:
```xml
<Signature>
<SignedInfo>
<CanonicalizationMethod />
<SignatureMethod />
<Reference>
<Transforms />
<DigestMethod />
<DigestValue />
</Reference>
...
</SignedInfo>
<SignatureValue />
<KeyInfo />
<Object />
</Signature>
```
Her `Reference` öğesi, URI niteliği ile tanımlanabilen belirli bir kaynağı imzalamaktadır.

### XML İmzalarının Türleri

1. **Enveloped Signature**: Bu tür imza, imzaladığı kaynağın bir alt öğesidir, yani imza, imzalanan içeriğin bulunduğu aynı XML yapısı içinde yer alır.

Örnek:

```xml
<samlp:Response ... ID="..." ... >
...
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
</ds:Signature>
...
</samlp:Response>
```

Enveloped signature'da, `ds:Transform` öğesi, `enveloped-signature` algoritması aracılığıyla sarıldığını belirtir.

2. **Enveloping Signature**: Enveloped signature'ların aksine, enveloping signature'lar imzalanan kaynağı sarar.

Örnek:

```xml
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
<samlp:Response ... ID="..." ... >
...
</samlp:Response>
</ds:Signature>
```

3. **Detached Signature**: Bu tür, imzaladığı içerikten ayrıdır. İmza ve içerik bağımsız olarak var olur, ancak ikisi arasında bir bağlantı korunur.

Örnek:

```xml
<samlp:Response ... ID="..." ... >
...
</samlp:Response>
<ds:Signature>
<ds:SignedInfo>
...
<ds:Reference URI="#...">
...
</ds:Reference>
</ds:SignedInfo>
</ds:Signature>
```

Sonuç olarak, XML İmzaları, XML belgelerini güvence altına almak için esnek yollar sunar; her tür, farklı yapısal ve güvenlik ihtiyaçlarını karşılar.

## Referanslar

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

{{#include ../../banners/hacktricks-training.md}}