SAML Basics
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) vergemaklik. Hierdie benadering vereenvoudig die bestuur van verskeie aanmeldings deur 'n enkele stel van bewysstukke 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 daarop gemik om ondernemings groter beheer oor SSO aanmeldingsveiligheid te bied.
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 verifikasie proses behels verskeie stappe, soos geïllustreer in die skema:
Hulpbron Toegang Poging: Die gebruiker probeer om toegang te verkry tot 'n beskermde hulpbron.
SAML Versoek Generasie: Die SP herken nie die gebruiker nie en genereer 'n SAML Versoek.
Herlei na IdP: Die gebruiker word na die IdP herlei, met die SAML Versoek wat deur die gebruiker se blaaier gaan.
IdP Ontvang Versoek: Die IdP ontvang die SAML Versoek.
Verifikasie by IdP: Die IdP verifieer die gebruiker.
Gebruiker Validasie: Die IdP valideer die gebruiker se legitimiteit om toegang tot die aangevraagde hulpbron te verkry.
SAML Antwoord Generasie: Die IdP genereer 'n SAML Antwoord wat nodige bewerings bevat.
Herlei na SP se ACS URL: Die gebruiker word na die SP se Assertion Consumer Service (ACS) URL herlei.
SAML Antwoord Validasie: Die ACS valideer die SAML Antwoord.
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:
Die rou SAML-versoek lyk soos volg:
Key elements of this request include:
AssertionConsumerServiceURL: Gee aan waar die IdP die SAML Response na die verifikasie moet stuur.
Destination: Die IdP se adres waarnatoe die versoek gestuur word.
ProtocolBinding: Definieer die oordragmetode van SAML-protokolboodskappe.
saml:Issuer: Identifiseer die entiteit wat die versoek geïnisieer het.
Following the SAML Request generation, the SP responds with a 302 redirect, directing the browser to the IdP with the SAML Request encoded in the HTTP response's Location header. The RelayState parameter maintains the state information throughout the transaction, ensuring the SP recognizes the initial resource request upon receiving the SAML Response. The SAMLRequest parameter is a compressed and encoded version of the raw XML snippet, utilizing Deflate compression and base64 encoding.
SAML Response Example
You can find a full SAML response here. The key components of the response include:
ds:Signature: Hierdie afdeling, 'n XML-handtekening, verseker die integriteit en egtheid van die uitgever van die bevestiging. Die SAML-response in die voorbeeld bevat twee
ds:Signatureelemente, een vir die boodskap en die ander vir die bevestiging.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 bevestiging.
saml:StatusCode: Verteenwoordig die status van die operasie in reaksie op die ooreenstemmende versoek.
saml:Conditions: Beskryf voorwaardes soos die geldigheidstyd van die bevestiging en die gespesifiseerde diensverskaffer.
saml:AuthnStatement: Bevestig dat die IdP die onderwerp van die bevestiging geverifieer het.
saml:AttributeStatement: Bevat eienskappe wat die onderwerp van die bevestiging beskryf.
Following the SAML Response, the process includes a 302 redirect from the IdP. This leads to a POST request to the Service Provider's Assertion Consumer Service (ACS) URL. The POST request includes RelayState and SAMLResponse parameters. The ACS is responsible for processing and validating the SAML Response.
After the POST request is received and the SAML Response is validated, access is granted to the protected resource initially requested by the user. This is illustrated with a GET request to the /secure/ endpoint and a 200 OK response, indicating successful access to the resource.
XML Signatures
XML-handtekeninge is veelsydig, in staat om 'n hele XML-boom of spesifieke elemente daarin te teken. Hulle kan op enige XML-objek toegepas word, nie net op Response-elemente nie. Hieronder is die sleutelsoorte van XML-handtekeninge:
Basic Structure of XML Signature
An XML Signature consists of essential elements as shown:
Elke Reference element dui 'n spesifieke hulpbron aan wat onderteken word, identifiseerbaar deur die URI attribuut.
Tipes XML Handtekeninge
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:
In 'n omhulde handtekening spesifiseer die ds:Transform element dat dit omhul is deur die enveloped-signature algoritme.
Omhulende Handtekening: In teenstelling met omhulde handtekeninge, omhulende handtekeninge verpak die hulpbron wat onderteken word.
Voorbeeld:
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:
Ten slotte bied XML Handtekeninge buigsame maniere om XML-dokumente te beveilig, met elke tipe wat verskillende struktuurlike en sekuriteitsbehoeftes dien.
Verwysings
Last updated
