saml-2.0 Zelfstudie
Aan de slag met saml-2.0
Zoeken…
Opmerkingen
SAML2.0 is een open standaard die wordt gebruikt voor het overdragen van authenticatie- en autorisatiegegevens tussen serviceproviders en identiteitsproviders.
Het meest voorkomende gebruik is webgebaseerde SSO, waarbij SAML een gebruiker in staat heeft gesteld om in te loggen bij een applicatie met referenties van een ander systeem, zonder dat de twee systemen rechtstreeks met elkaar verbonden moeten zijn tijdens authenticatie.
De SAML2.0-authenticatiestroom
SAML specificeert drie belangrijke rollen:
De identiteitsprovider (IdP)
De partij die de identiteit van de gebruikers verstrekt en onderhoudt. Dit kan een directoryservice zijn zoals ADFS of een aangepaste databaseoplossing.
De dienstverlener (SP)
De serviceprovider is de daadwerkelijke service waarbij de gebruiker probeert in te loggen. Dit kan een website, een applicatie of elke service zijn waarvoor een gebruiker zich zou moeten aanmelden.
De opdrachtgever / de gebruiker
De daadwerkelijke gebruiker die het verzoek indient of probeert toegang te krijgen tot een bron van de serviceprovider (SP).
De belangrijkste SAML-use case is Web Based SSO , waarbij het SAML-proces wordt uitgevoerd door een set omleidingen in de browser van de gebruiker, waarbij de gebruiker fungeert als de token-carrier tussen de IdP en SP.
Er zijn twee stromen voor webgebaseerde SSO met SAML:
Identity Provider (IdP) geïnitieerd
De gebruiker meldt zich aan bij de IdP en wordt vervolgens doorgestuurd naar de gewenste SP. Een gebruiker logt bijvoorbeeld in op een bedrijfsintranet en krijgt alle beschikbare applicaties te zien.
Service Provider (SP) geïnitieerd
De gebruiker probeert in te loggen bij een toepassing, maar wordt doorgestuurd naar de IdP om de werkelijke authenticatie uit te voeren. Een gebruiker probeert bijvoorbeeld in te loggen bij een externe SaaS- toepassing, maar wordt doorgestuurd naar een bedrijfs-IdP zodat de gebruiker met zijn bedrijfsgegevens in de externe toepassing kan inloggen.
De door SP geïnitieerde stroom wordt sterk gevisualiseerd door de onderstaande workflow:
Bron: Wikipedia
- Een gebruiker probeert toegang te krijgen tot een bron op een specifieke applicatie of webpagina
- Een gebruiker specificeert (en) hij probeert in te loggen met een externe IdP. De SP genereert een SAML-bewering en geeft deze door (meestal via POST- of GET-variabelen) terwijl u wordt doorgestuurd naar de IdP
- De gebruiker zal zichzelf authenticeren tegen de IdP
- De ondertekende bewering en het token worden gegenereerd door de IdP
- De ondertekende bewering en het token worden teruggestuurd (opnieuw met behulp van POST- of GET-variabelen) naar de SP en indien succesvol wordt een sessie gestart op de SP
- en verder is de gebruiker in staat om aanvullende middelen van de SP aan te vragen terwijl hij een actieve sessie met de SP heeft (dwz door middel van cookies), zodat hij niet bij elk verzoek met de IdP hoeft te authenticeren.
SAML-hulpprogramma's voor foutopsporing
Met alle verzoeken en beweringen die heen en weer gaan, kan het lastig zijn om problemen met uw SAML-claims en beweringen te debuggen.
Aangezien binnen SAML een kernprincipe geen directe verbinding tussen de IdP en de SP vereist, fungeert de browser van de gebruiker als een berichtendrager tussen de twee. Hierdoor verloopt alle communicatie - zij het gecodeerd - via uw eigen browser.
Met behulp van verschillende foutopsporingshulpmiddelen kunt u de exacte communicatie en verzoeken zien die worden gedaan en doorgestuurd tussen IdP en SP.
Om u op weg te helpen, zijn hier enkele hulpmiddelen voor verschillende browsers die u op weg moeten helpen:
Chrome
Firefox
Met bijvoorbeeld SAML Tracer kunt u gedecodeerde SAML-beweringen en -verzoeken in realtime bekijken tijdens het testen en debuggen