SAML and SSO

Sådan fungerer SAML og muliggøre Single Sign-on

SAML (Security Assertion Markup Language) er en åben standard, der definerer, hvordan udbydere kan tilbyde både godkendelses- og godkendelsestjenester.

SAML og hvad bruges det til

SAML (Security Assertion Markup Language) er en åben standard, der gør det muligt at dele sikkerhedsoplysninger af flere computere på tværs af et netværk. Det beskriver en ramme, der gør det muligt for en computer at udføre nogle sikkerhedsfunktioner på vegne af en eller flere andre computere.

Strengt taget henviser SAML til XML-variantsproget, der bruges til at kode alle disse oplysninger, men udtrykket kan også dække forskellige protokolmeddelelser og profiler, der udgør en del af standarden. Da SAML er en åben standard, kan den koordinere sikkerhedsforanstaltninger for forskellige applikationer og systemer fra forskellige leverandører. Som følge heraf bruger mange sikkerhedsleverandører SAML som grundlag for deres kommercielle tilbud for at sikre interoperationalitet.

SAML 2.0 blev introduceret i 2005 og er fortsat den nuværende version af standarden. Den tidligere version, 1.1, er nu stort set udfaset. (SAMLDiffs har et godt resumé af forskellen mellem versionerne.)

Single Sign-on

Mens SAML blev designet med en bred vifte af brugssager i tankerne, er langt den mest almindelige i praksis Single Sign-on (SSO). Som navnet antyder, giver en bruger mulighed for at logge ind en gang og få adgang til flere tjenester – websteder, sky- eller SaaS-apps, fildelinger osv. I et SSO-scenarie outsourcer alle disse tjenester deres godkendelses- og godkendelsesfunktionalitet til et enkelt system, der derefter sender identitetsoplysninger om brugeren til disse tjenester.

Dokumenter skrevet i SAML er en måde, hvorpå Single Sign-on-oplysninger kan overføres. SAML’s åbne natur og interoperationalitet gør det til en særlig attraktiv kandidat til denne rolle, da kunderne ofte ønsker en Single Sign-on-løsning, der kan forbinde applikationer fra flere leverandører.

Godkendelse vs. godkendelse

Før vi går videre, skal vi diskutere to forskellige roller, som SAML kan spille i et SSO-system

Godkendelse: Bestemmelse af, at brugerne er dem, de hævder at være

Autorisation: Bestemmelse af, om brugere har ret til at få adgang til bestemte systemer eller indhold

Det er klart, at enhver SSO-platform bliver nødt til at spille begge roller for at udføre sit job. Et interessepunkt er, at SAML ikke behøver at blive brugt til begge dele. For eksempel har Microsoft en SSO-implementering, der bruger SAML til godkendelse, men OAuth (en anden åben standard, som vi vil diskutere mere detaljeret senere i denne artikel) til godkendelse.

SAML-udbyder

I SAML-lingo er en udbyder en enhed – generelt en server eller anden computer – i et system, der hjælper brugeren med at få adgang til de tjenester, han eller hun ønsker, og som producerer eller forbruger SAML-tjenester. Generelt kaldes de faktiske programmer, du ønsker at få adgang til, som SaaS-applikationer eller beskyttede filservere, tjenesteudbydere, mens identitetsudbydere sørger for, at brugeren virkelig er den, de hævder at være eller har ret til at få adgang til de systemer, de prøver at få adgang til – det giver med andre ord godkendelse eller autorisation.

SAML-standarden i sig selv definerer ikke, hvordan disse udbydere udfører deres job; i stedet fastlægger den, hvilke oplysninger de har brug for til at kommunikere med hinanden, og hvordan denne kommunikation og dens flow er struktureret.

SAML-påstand

En SAML-påstand er XML-dokumentet, hvormed alle de oplysninger, vi har diskuteret, overføres fra en computer til en anden. Når en identitetsudbyder har fastslået, at du er den, du siger, du er, og har ret til at få adgang til det indhold eller de tjenester, du er interesseret i, sender den en SAML-påstand til den server, der rent faktisk kan levere disse tjenester til dig. En SAML-påstand kan krypteres for øget sikkerhed.

For mere om alle disse vilkår, se den officielle SAML-ordliste fra OASIS.

SAML-godkendelse

Hvis brugeren er i et miljø med Single Sign-on og forsøger at få adgang til en ressource på en server. Hændelsesforløbet går sådan her:

  1. Du forsøger at få adgang til ressourcen på serveren. Tjenesteudbyderen kontrollerer, om du allerede er godkendt i systemet. Hvis du er, springer du til trin 7; Hvis du ikke er det, starter tjenesteudbyderen godkendelsesprocessen.
  2. Tjenesteudbyderen bestemmer den relevante identitetsudbyder for dig og omdirigerer dig til den pågældende udbyder – i dette tilfælde SSO-tjenesten.
  3. Din browser sender en godkendelsesanmodning til SSO-tjenesten; tjenesten identificerer dig derefter.
  4. SSO-tjenesten returnerer et XHTML-dokument, som indeholder de godkendelsesoplysninger, som tjenesteudbyderen har brug for, i en SAMLResponse-parameter.
  5. SAMLResponse-parameteren videregives til tjenesteudbyderen.
  6. Tjenesteudbyderen behandler dette svar og opretter en sikkerhedskontekst for dig – dybest set logger den dig ind – og fortæller dig derefter, hvor din ønskede ressource er.
  7. Med disse oplysninger kan du nu anmode om den ressource, du er interesseret i.
  8. Ressourcen er endelig returneret til dig!

Hvis du vil se nærmere på tarmene i de meddelelser, der sendes frem og tilbage i en SAML-transaktion, skal du tjekke eksemplerne her fra OneLogin. Du kan grave i den fulde XML-kode for de typer påstande, der overføres fra identitetsudbyderen til tjenesteudbyderen i det scenarie, der er beskrevet ovenfor.

Implementering af SAML

Du vil bemærke, at meget af dette er ret højt niveau: for eksempel er der ingen forklaring på, hvordan SAML ved, hvad den relevante identitetsudbyder er, eller hvordan identitetsudbyderen bestemmer, at du er den, du siger, du er. Det er ikke kun os, der udelader ting: Som vi berørte ovenfor, definerer SAML-standarden ikke, hvordan disse ting sker, hvilket efterlader leverandører og implementatorer masser af spillerum til, hvordan man konfigurerer tingene. Flere teknologier kan bruges til selve godkendelsesstykket, og de teknologier, du vælger, dikterer detaljerne om, hvordan du implementerer SAML i dit miljø. Men uanset hvilket valg du træffer, vil SAML-påstande bære godkendelses- og autorisationsdata fra en udbyder til en anden.

Fordele ved SAML-godkendelse

Den vigtigste fordel ved SAML som grundlag for en SSO-løsning er, at det er en åben standard. Som vi har set, betyder det, at det kan implementeres af en lang række IAM-leverandører og integreres i altomfattende systemer som Salesforce. Det betyder også, at udbydere fra forskellige leverandører kan kommunikere med hinanden, så længe de overholder SAML-standarden.

Fordi SAML er en XML-dialekt, er den også meget fleksibel. Alle former for data kan overføres i et SAML-dokument, så længe de kan gengives i XML.

Forskellen på SAML vs. OAuth

OAuth er en noget nyere standard end SAML, udviklet i fællesskab af Google og Twitter begyndende i 2006. Det blev udviklet delvist for at kompensere for SAMLs mangler på mobile platforme og er baseret på JSON snarere end XML.

Bortset fra SAMLs mindre end stjernernes mobile support, hvad er forskellen mellem de to? Som vi har set, definerer SAML-standarden, hvordan udbydere kan tilbyde både godkendelses- og godkendelsestjenester. OAuth beskæftiger sig derimod kun med autorisation. OpenID Connect er en endnu nyere standard, udviklet i 2014, der leverer godkendelsestjenester og er lagdelt oven på OAuth.

En anden stor forskel mellem SAML og OAuth er deres brugssager. Mens SAML teoretisk set blev designet til brug på det åbne internet, er det i praksis oftest implementeret i virksomhedsnetværk til enkeltlogon. OAuth blev derimod designet af Google og Twitter til internetskala.

SAML-leverandører

SAML er en åben standard, og derfor kan alle oprette en kommerciel eller open source-implementering, der leverer godkendelsestjenester i overensstemmelse med den. Generelt er denne funktionalitet indbygget i et identitets- og adgangsstyringsprodukt (IAM), selv om denne IAM-funktionalitet igen kan samles i en mere altomfattende system- eller infrastrukturplatform. Nuværende udbydere omfatter:

  • Active Directory Federation Services (ADFS)
  • Auth0
  • Azure AD (Microsoft Azure Active Directory)
  • NetIQ Access Manager
  • Okta
  • OneLogin
  • OpenAM
  • Ping identitet
  • Salesforce
  • Shibboleth
  • SimpleSAMLphp

Her er nogle gode steder at lære mere om SAML

  • OneLogin skitserer, hvordan man udvikler til SAML på fem forskellige webudviklingsplatforme.
  • Amazon forklarer, hvordan man opretter en SAML-identitetsudbyder til AWS.
  • Hvis du bruger ZenDesk, kan du konfigurere enkeltlogon ved hjælp af Active Directory med ADFS og SAML
  • Få mere at vide om, hvordan SAML kan føje SSO-funktionalitet til dit Rails-program
  • Auth0 giver de nitty-gritty detaljer om, hvordan SAML-godkendelse fungerer

Kilde CSOonline

Foto: Pexels

Scroll to Top