SAML Oorsig

Security Assertion Markup Language (SAML) stel identiteitsverskaffers (IdP) in staat om gebruik te word om magtigingsbewyse na diensverskaffers (SP) te stuur, wat enkel aanmelding (SSO) fasiliteer. Hierdie benadering vereenvoudig die bestuur van verskeie aanmeldings deur 'n enkele stel van magtigingsbewyse oor verskeie webwerwe te gebruik. Dit benut XML vir gestandaardiseerde kommunikasie tussen IdP's en SP's, wat die verifikasie van gebruikersidentiteit met diensmagtiging verbind.

Vergelyking tussen SAML en OAuth

• SAML is gerig op die verskaffing van groter beheer oor SSO aanmeldingsveiligheid vir ondernemings.
• OAuth is ontwerp om meer mobiele-vriendelik te wees, gebruik JSON, en is 'n samewerkende poging van maatskappye soos Google en Twitter.

SAML Verifikasie Stroom

Vir verdere besonderhede, kyk na die volledige pos van https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/. Dit is 'n opsomming:

Die SAML verifikasieproses behels verskeie stappe, soos geïllustreer in die skema:

1. Hulpbron Toegang Poging: Die gebruiker probeer om toegang te verkry tot 'n beskermde hulpbron.
2. SAML Versoek Generasie: Die SP herken nie die gebruiker nie en genereer 'n SAML Versoek.
3. Herlei na IdP: Die gebruiker word na die IdP herlei, met die SAML Versoek wat deur die gebruiker se blaaier gaan.
4. IdP Ontvang Versoek: Die IdP ontvang die SAML Versoek.
5. Verifikasie by IdP: Die IdP verifieer die gebruiker.
6. Gebruiker Validasie: Die IdP valideer die gebruiker se legitimiteit om toegang tot die aangevraagde hulpbron te verkry.
7. SAML Antwoord Skepping: Die IdP genereer 'n SAML Antwoord wat nodige bevestigings bevat.
8. Herlei na SP se ACS URL: Die gebruiker word na die SP se Assertion Consumer Service (ACS) URL herlei.
9. SAML Antwoord Validasie: Die ACS valideer die SAML Antwoord.
10. Hulpbron Toegang Gegee: Toegang tot die aanvanklik aangevraagde hulpbron word gegee.

SAML Versoek Voorbeeld

Oorweeg die scenario waar 'n gebruiker toegang tot 'n veilige hulpbron by https://shibdemo-sp1.test.edu/secure/ aanvra. Die SP identifiseer die gebrek aan verifikasie en genereer 'n SAML Versoek:

GET /secure/ HTTP/1.1
Host: shibdemo-sp1.test.edu
...

Die rou SAML-versoek lyk soos volg:

<?xml version="1.0"?>
<samlp:AuthnRequest ...
</samlp:AuthnRequest>

Belangrike elemente van hierdie versoek sluit in:

• AssertionConsumerServiceURL: Gee aan waar die IdP die SAML Response na verifikasie moet stuur.
• Destination: Die IdP se adres waarnatoe die versoek gestuur word.
• ProtocolBinding: Definieer die transmissiemetode van SAML-protokolboodskappe.
• saml:Issuer: Identifiseer die entiteit wat die versoek geïnisieer het.

Na die generering van die SAML Versoek, reageer die SP met 'n 302 redirect, wat die blaaier na die IdP lei met die SAML Versoek gekodeer in die HTTP response se Location kop. Die RelayState parameter handhaaf die staat-inligting deur die transaksie, wat verseker dat die SP die aanvanklike hulpbron versoek herken wanneer die SAML Response ontvang word. Die SAMLRequest parameter is 'n gecomprimeerde en gekodeerde weergawe van die rou XML-snippet, wat Deflate-kompressie en base64-kodering gebruik.

SAML Response Voorbeeld

Jy kan 'n volle SAML response hier vind. Die sleutelkomponente van die response sluit in:

• ds:Signature: Hierdie afdeling, 'n XML Handtekening, verseker die integriteit en egtheid van die uitgever van die bewering. Die SAML response in die voorbeeld bevat twee ds:Signature elemente, een vir die boodskap en die ander vir die bewering.
• saml:Assertion: Hierdie deel hou inligting oor die gebruiker se identiteit en moontlik ander eienskappe.
• saml:Subject: Dit spesifiseer die hoofonderwerp van al die stellings in die bewering.
• saml:StatusCode: Verteenwoordig die status van die operasie in reaksie op die ooreenstemmende versoek.
• saml:Conditions: Beskryf voorwaardes soos die geldigheidstyd van die Bewering en die gespesifiseerde Diensverskaffer.
• saml:AuthnStatement: Bevestig dat die IdP die onderwerp van die Bewering geverifieer het.
• saml:AttributeStatement: Bevat eienskappe wat die onderwerp van die Bewering beskryf.

Na die SAML Response sluit die proses 'n 302 redirect van die IdP in. Dit lei tot 'n POST versoek na die Diensverskaffer se Assertion Consumer Service (ACS) URL. Die POST versoek sluit RelayState en SAMLResponse parameters in. Die ACS is verantwoordelik vir die verwerking en validasie van die SAML Response.

Nadat die POST versoek ontvang is en die SAML Response geverifieer is, word toegang verleen tot die beskermde hulpbron wat aanvanklik deur die gebruiker versoek is. Dit word geïllustreer met 'n GET versoek na die /secure/ eindpunt en 'n 200 OK response, wat suksesvolle toegang tot die hulpbron aandui.

XML Handtekeninge

XML Handtekeninge is veelsydig, in staat om 'n hele XML-boom of spesifieke elemente daarin te teken. Hulle kan op enige XML Objekt toegepas word, nie net Response elemente nie. Hieronder is die sleutelsoorte van XML Handtekeninge:

Basiese Struktuur van XML Handtekening

'n XML Handtekening bestaan uit noodsaaklike elemente soos getoon:

<Signature>
<SignedInfo>
<CanonicalizationMethod />
<SignatureMethod />
<Reference>
<Transforms />
<DigestMethod />
<DigestValue />
</Reference>
...
</SignedInfo>
<SignatureValue />
<KeyInfo />
<Object />
</Signature>

Elke Reference element dui 'n spesifieke hulpbron aan wat onderteken word, identifiseerbaar deur die URI attribuut.

Tipes XML Handtekeninge

1. Omhulde Handtekening: Hierdie tipe handtekening is 'n afstammeling van die hulpbron wat dit onderteken, wat beteken dat die handtekening binne dieselfde XML-struktuur as die ondertekende inhoud bevat is.

Voorbeeld:

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

In 'n omhulde handtekening spesifiseer die ds:Transform element dat dit omhul is deur die enveloped-signature algoritme.

2. Omhulende Handtekening: In teenstelling met omhulde handtekeninge, omhulende handtekeninge omhul die hulpbron wat onderteken word.

Voorbeeld:

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

3. Afgeskeurde Handtekening: Hierdie tipe is apart van die inhoud wat dit onderteken. Die handtekening en die inhoud bestaan onafhanklik, maar 'n skakel tussen die twee word gehandhaaf.

Voorbeeld:

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

Ten slotte bied XML Handtekeninge buigsame maniere om XML-dokumente te beveilig, met elke tipe wat verskillende struktuurlike en sekuriteitsbehoeftes dien.

Verwysings

• https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/