SAML Basics
SAML-oorsig
Security Assertion Markup Language (SAML) maak dit moontlik vir identiteitsverskaffers (IdP) om gebruik te word vir die stuur van outorisasie-legitimasie na diensverskaffers (SP), wat enkel-aanmelding (SSO) fasiliteer. Hierdie benadering vereenvoudig die bestuur van veelvuldige aanmeldings deur 'n enkele stel legitimasie te gebruik vir verskeie webwerwe. Dit maak gebruik van XML vir gestandaardiseerde kommunikasie tussen IdP's en SP's, wat die outentisering van gebruikersidentiteit koppel met diens-outorisasie.
Vergelyking tussen SAML en OAuth
SAML is toegespits op die bied van groter beheer aan ondernemings oor SSO-aanmeldingsbeveiliging.
OAuth is ontwerp om meer mobielvriendelik te wees, maak gebruik van JSON, en is 'n samewerkingspoging van maatskappye soos Google en Twitter.
SAML-outentiseringsvloei
Vir verdere besonderhede, kyk na die volledige berig vanaf https://epi052.gitlab.io/notes-to-self/blog/2019-03-07-how-to-test-saml-a-methodology/. Hierdie is 'n opsomming:
Die SAML-outentiseringsproses behels verskeie stappe, soos geïllustreer in die skema:
Toegangspoging tot hulpbron: Die gebruiker probeer toegang verkry tot 'n beskermde hulpbron.
SAML-versoekgenerering: Die SP herken die gebruiker nie en genereer 'n SAML-versoek.
Omleiding na IdP: Die gebruiker word omgelei na die IdP, met die SAML-versoek wat deur die gebruiker se blaaier gaan.
IdP ontvang versoek: Die IdP ontvang die SAML-versoek.
Outentisering by IdP: Die IdP outentiseer die gebruiker.
Gebruikersvalidering: Die IdP valideer die gebruiker se legitimiteit om toegang te verkry tot die versoekte hulpbron.
SAML-antwoordgenerering: Die IdP genereer 'n SAML-antwoord met nodige bewerings.
Omleiding na SP se ACS-URL: Die gebruiker word omgelei na die SP se Assertion Consumer Service (ACS)-URL.
SAML-antwoordvalidering: Die ACS valideer die SAML-antwoord.
Toegang tot hulpbron toegestaan: Toegang tot die aanvanklik versoekte hulpbron word toegestaan.
Voorbeeld van SAML-versoek
Beskou die scenario waar 'n gebruiker toegang tot 'n veilige hulpbron aanvra by https://shibdemo-sp1.test.edu/secure/. Die SP identifiseer die gebrek aan outentisering en genereer 'n SAML-versoek:
Die onbewerkte SAML-versoek lyk soos volg:
Belangrike elemente van hierdie versoek sluit in:
AssertionConsumerServiceURL: Spesifiseer waar die IdP die SAML Response na outentifikasie moet stuur.
Destination: Die IdP se adres waarna die versoek gestuur word.
ProtocolBinding: Definieer die oordragmetode 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 omleiding, wat die blaaier na die IdP rig met die SAML-versoek gekodeer in die HTTP-reaksie se Location-kop. Die RelayState-parameter handhaaf die toestandinligting gedurende die transaksie, om te verseker dat die SP die oorspronklike bronversoek herken wanneer die SAML Response ontvang word. Die SAMLRequest-parameter is 'n saamgedrukte en gekodeerde weergawe van die rou XML-snippet, wat gebruik maak van Deflate-samepersing en base64-kodering.
Voorbeeld van 'n SAML Response
Jy kan 'n volledige SAML-response hier vind. Die sleutelkomponente van die response sluit in:
ds:Signature: Hierdie gedeelte, 'n XML-handtekening, verseker die integriteit en egtheid van die uitreiker 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 bevat inligting oor die identiteit van die gebruiker en moontlik ander eienskappe.
saml:Subject: Dit spesifiseer die hoofonderwerp van al die verklarings in die bewering.
saml:StatusCode: Verteenwoordig die status van die operasie in reaksie op die betrokke versoek.
saml:Conditions: Gee besonderhede oor voorwaardes soos die geldigheidstyd van die Bewering en die gespesifiseerde Diensverskaffer.
saml:AuthnStatement: Bevestig dat die IdP die onderwerp van die Bewering geoutentiseer het.
saml:AttributeStatement: Bevat eienskappe wat die onderwerp van die Bewering beskryf.
Na die SAML Response sluit die proses 'n 302 omleiding van die IdP in. Dit lei tot 'n POST-versoek na die Diensverskaffer se Assertion Consumer Service (ACS) URL. Die POST-versoek bevat RelayState- en SAMLResponse-parameters. Die ACS is verantwoordelik vir die verwerking en geldigverklaring van die SAML Response.
Nadat die POST-versoek ontvang is en die SAML Response geldig verklaar is, word toegang verleen tot die beskermde bron wat aanvanklik deur die gebruiker versoek is. Dit word geïllustreer met 'n GET-versoek na die /secure/-eindpunt en 'n 200 OK-reaksie, wat suksesvolle toegang tot die bron aandui.
XML-handtekeninge
XML-handtekeninge is veelsydig en kan 'n hele XML-boom of spesifieke elemente binne dit onderteken. Dit kan toegepas word op enige XML-objek, nie net Response-elemente nie. Hieronder is die sleuteltipes van XML-handtekeninge:
Basiese struktuur van XML-handtekening
'n XML-handtekening bestaan uit essensiële elemente soos hieronder getoon:
Elke Verwysing element dui op 'n spesifieke bron wat onderteken word, wat identifiseerbaar is deur die URI-eienskap.
Tipes XML-handtekeninge
Ingeslote Handtekening: Hierdie tipe handtekening is 'n afstammeling van die bron wat onderteken word, wat beteken dat die handtekening binne dieselfde XML-struktuur as die ondertekende inhoud bevat word.
Voorbeeld:
In 'n ingeslote handtekening dui die ds:Transform element aan dat dit ingesluit is deur die ingeslote-handtekening algoritme.
Insluitende Handtekening: In teenstelling met ingeslote handtekeninge, wikkel insluitende handtekeninge die bron wat onderteken word in.
Voorbeeld:
Losgekoppelde Handtekening: Hierdie tipe is geskei van die inhoud wat onderteken word. Die handtekening en die inhoud bestaan onafhanklik van mekaar, maar 'n skakel tussen die twee word behou.
Voorbeeld:
Ter opsomming, XML-handtekeninge bied buigbare maniere om XML-dokumente te beveilig, waarby elke tipe verskillende strukturele en veiligheidsbehoeftes dien.
Verwysings
Last updated
