Dybdedyk i SAML-autentificering
Forstå SAML ved single sign-on med Salesforce
Inden for autentificering spiller SAML (Security Assertion Markup Language) en nøglerolle for problemfri adgang på tværs af applikationer. Lad os dykke ned i SAML, forstå, hvorfor det er vigtigt for single sign-on (SSO), og se på, hvordan det bruges med Salesforce.
Sammenhængen
Forestil dig, at du har to Salesforce-orgs: en identitetsudbyder (IDP) og en tjenesteudbyder. Tjenesteudbyderen har de data, du vil have adgang til, men i stedet for at bruge flere sæt loginoplysninger vil du klare dig med ét. Idéen lyder enkel, men mekanikken bag kulisserne kan være indviklet.

Nøglebegreber i SAML-landskabet
Brugeradgang: Når en bruger forsøger at nå en beskyttet ressource hos tjenesteudbyderen, før vedkommende har autentificeret sig.
Omdirigering: Hvis brugeren ikke er autentificeret, omdirigerer tjenesteudbyderen vedkommende til identitetsudbyderen med en SAML-forespørgsel. Om nødvendigt kan en relay state (den URL, brugeren først ville besøge) sendes med.
Autentificering hos IDP’en: Identitetsudbyderen kontrollerer brugerens identitet, typisk med brugernavn, adgangskode eller multifaktorgodkendelse.
SAML-assertion: Efter autentificeringen sender IDP’en en SAML-assertion til tjenesteudbyderen.
Tjenesteudbyderens tillid: Tjenesteudbyderen validerer SAML-assertionen, trækker brugeroplysningerne ud og giver adgang. Hvis der tidligere blev sendt en relay state, navigerer tjenesteudbyderen til netop den URL.

Fordelene ved single sign-on
Enklere adgang: Brugerne har kun brug for ét sæt loginoplysninger for at få adgang til flere tjenester.
Sikkerhed: SAML bruger digitale signaturer til at sikre dataintegriteten og forhindre manipulation.
Interoperabilitet: Fordi SAML er en standardprotokol, kan det arbejde sammen med forskellige IDP’er og tjenesteudbydere på tværs af teknologistakke.
Dybere ned: et nærmere kig på SAML-flowene
SAML-forespørgsel: Sendes af tjenesteudbyderen til IDP’en og beder den om at autentificere en bruger.

SAML-svar: En meddelelse fra IDP’en efter autentificeringen med oplysninger om brugeren.

Assertions: Det er udsagn fra IDP’en om brugeren med attributter som brugernavn eller e-mail.
Digitale signaturer: De bruges til at verificere assertions og sikre, at de ikke er blevet ændret uretmæssigt.
Relay state: Et dybt link, der sikrer, at brugeren sendes tilbage til det mål, vedkommende oprindeligt ville nå, efter autentificeringen.
Når en bruger beder om adgang, sendes en SAML-forespørgsel til IDP’en, som efter kontrollen sender en SAML-assertion tilbage. Når tjenesteudbyderen har valideret assertionen, får brugeren den adgang, vedkommende ville have.

Med værktøjer som SAML Tracer til browsere kan man visualisere flowet. Det giver et gennemsigtigt billede af autentificeringsprocessen, fra den første forespørgsel til den sidste omdirigering efter autentificeringen.
Sikkerhedsforanstaltninger i SAML-assertions
For at imødegå mulige sikkerhedstrusler:
Tidsstempler bruges til at forhindre replay-angreb, så SAML-assertionen kun er gyldig i et kort tidsvindue.
Digitale signaturer garanterer, at data ikke er blevet manipuleret under udvekslingen.
Derudover kan assertions indeholde brugerattributter som e-mailadresser eller brugertyper, hvilket giver mulighed for mere detaljeret adgangskontrol hos tjenesteudbyderen.
Konklusion
SAML er i bund og grund en XML-baseret protokol med de vigtigste elementer til autentificering. Det kan virke som magi, men det er resultatet af gennemtænkt teknologi, der er designet til at stoppe angreb som »man-in-the-middle« eller replay-scenarier.
Evnen til at forbinde flere tjenesteudbydere med IDP’er på forskellige teknologistakke gør SAML til en hjørnesten i den digitale autentificerings verden.
Hold øje
Tag hul på din rejse med Salesforce Identity med selvtillid! For flere indsigter og tips, hold øje her på www.SteveTechArc.com og på YouTube-kanalen @SteveTechArc (opens in a new tab). Abonnér, og styrk din forståelse af Salesforce Identity.
Vi hjælper med at forandre verden ved at dele integrationsviden med andre arkitekter og med dem, der er på vej til at blive arkitekter!
Transskription med hjælp fra AI
STA 3.6