Patroon voor single sign-on

Uit NORA Online
Versie door NCoppens (overleg | bijdragen) op 8 apr 2014 om 12:35 (concept weg)
Naar navigatie springen Naar zoeken springen


Beveiliging
Onderdeel van
Thema's
Contact
Guus van den Berg
Guus.vandenberg@cip-overheid.nl
Status
Dit thema wordt momenteel opnieuw bekeken door de Expertgroep Beveiliging

Criteria

Vertrouwelijkheid

Context

Bedrijfsprocessen worden door een toenemend aantal IT-systemen ondersteund. Ook het aantal diensten dat via het Internet wordt aangeboden krijgt een steeds grotere omvang. Bij veel van dergelijke IT-systemen en diensten moet zekerheid bestaan over de identiteit van de gebruiker en wordt geëist dat de gebruiker zich authenticeert. Het aantal momenten dat een gebruiker zich moet authenticeren neemt daarmee sterk toe:

  • Binnen organisaties, waar medewerkers een scala aan bestaande systemen moeten bedienen, komt het voor dat ze soms wel 10 keer of vaker op een dag moeten aanloggen, waarbij tevens verschillende gebruikersnamen en wachtwoorden ingevoerd moeten worden.
  • Bij initiële gebruikerstests van mijn.overheid.nl kwam vaak naar voren dat gebruikers niet gemakkelijk konden schakelen tussen aangeboden overheidsproducten en –diensten van de aangesloten organisaties en telkens opnieuw moesten inloggen.
Single sign-on

Probleem

  1. Meerdere keren inloggen voor verschillende diensten bij één en dezelfde organisatie.
  2. Opschrijven wachtwoorden
  3. Beveiligingsincidenten, door verwarring wachtwoordgebruik: verschillende ww conventies etc.

Oplossing

Voor probleem 1: Door te zorgen dat met één keer inloggen een reeks van diensten beschikbaar komt, is voor gebruikers een van de grootste ergernissen en drempels weggenomen. Dit ‘eenmalig aanmelden’ voor toegang tot meerdere systemen of diensten heet in vaktermen single sign-on (SSO). Als de gebruiker vervolgens uitlogt op één van deze systemen of diensten, dan is zijn sessie bij zowel deze als bij de overige beëindigd (single sign-off).

Voor probleem 2: Met behulp van federatie van identiteitsinformatie (zie patroon voor federatie van identity management) wordt de ‘noodzaak’ van het noteren van wachtwoorden of pincodes binnen organisaties voorkomen.

Voor probleem 3: Bij SSO is sprake van het ‘externaliseren’ van de authenticatie. Dat betekent dat de authenticatie door centrale componenten buiten de applicatie wordt afgehandeld. Deze centrale componenten kunnen binnen de voor die applicatie verantwoordelijke organisatie gelokaliseerd zijn of daarbuiten bij een identity provider. Op deze wijze kunnen verschillen in conventies en syntax van wachtwoorden voor BackOffice systemen aan de gebruikerskant worden vermeden.

Bij de onderstaande oplossingen wordt onderscheid gemaakt tussen SSO voor interne gebruikers binnen een organisatie, ‘interne SSO’, en SSO voor gebruikers die toegang willen tot diensten van een of meerdere externe organisaties, ‘externe SSO’.

Interne SSO met Kerberos

Een veel toegepaste en betrouwbare techniek voor interne SSO is Kerberos. Kerberos levert authenticatie (oorspronkelijk) op basis van symmetrische encryptie. SSO wordt gerealiseerd door het toepassen van zogenaamde tickets (= een set vercijferde gegevens). Een gebruiker authenticeert zich één maal, bijvoorbeeld met een wachtwoord en krijgt daarvoor een Ticket granting ticket met een bepaalde geldigheidsduur. Op basis van dit granting ticket, kunnen zonder tussenkomst van de gebruiker Servicetickets worden toegekend, waarmee automatisch op applicatie servers kan worden ingelogd. Hiermee is SSO gerealiseerd totdat het Ticket granting ticket verlopen is (bijvoorbeeld na 8 uur). Autorisatie, ofwel “wat mag de gebruiker op die server of binnen die applicatie?”, is geen onderdeel van het Kerberos protocol.

De centrale component in een Kerberos omgeving is het Key Distribution Center (KDC) waarin de Authenticatie Server de authenticatie van de client verzorgt en de Ticket Granting Server de tickets levert voor authenticatie van de client aan de applicatie servers. Sleutels, zoals voor de beveiliging met symmetrische encryptie van de berichtenuitwisseling, zijn in de Database opgeslagen.

Interne SSO met Kerberos

Na inloggen door de gebruiker met bijvoorbeeld gebruikersnaam/wachtwoord op de client worden de volgende stappen (op hoofdlijnen) doorlopen:

  1. De client vraagt een Ticket granting ticket aan bij de authenticatieservice.
  2. De authenticatieservice identificeert de gebruiker en stuurt een Ticket granting ticket (de master ticket) naar de client waar het tijdelijk (afhankelijk van de geldigheidsduur maar uiterlijk totdat de gebruiker uitlogt) wordt opgeslagen.
  3. Zodra een client toegang wil tot een bepaalde applicatieservice, wordt hiervoor een Service ticket aangevraagd. Omdat hiervoor het opgeslagen ticket granting ticket gebruikt kan worden hoeft de gebruiker zich niet opnieuw te authenticeren, waarmee SSO is gerealiseerd.
  4. De ticket granting server stuurt een ticket om toegang te krijgen tot de applicatieserver.
  5. De client stuurt de Serviceticket naar de applicatie server om toegang te krijgen.
  6. Optioneel bericht voor authenticatie van de applicatie server door de client (wederzijdse authenticatie).
  7. Gebruiker krijgt toegang tot de gevraagde applicatieservice.

Voor de eerste twee berichten wordt de hash van het gebruikerswachtwoord als encryptiesleutel gebruikt, die ook bekend moet zijn bij het KDC en op basis waarvan de authenticatie van de gebruiker plaatsvindt. Daarna wordt een sessiesleutel toegepast voor de beveiliging van de berichten.

Dit mechanisme biedt alleen SSO voor services met hetzelfde beveiligingsniveau. Als gebruikers inloggen op services met een hoger beveiligingsniveau, dan moeten zij hiervoor apart inloggen, of inloggen met een authenticatiemiddel dat voor de verschillende niveaus geschikt is. Als het beveiligingsbeleid verbiedt dat een gebruiker tegelijk op verschillende niveaus is ingelogd, dan zijn er aparte Kerberos sessies nodig.

Applicaties kunnen Kerberos integreren via de standaard GSS-API. Deze techniek wordt door MS-Directory Services vaak toegepast voor het authenticatiedeel.

Een client kan ook toegang krijgen tot applicaties die onder een ander KDC regiem vallen, wanneer die KDC en het eigen KDC een vertrouwensrelatie hebben en onderling een symmetrische sleutel hebben afgesproken. De betreffende client vraagt dan bij zijn eigen KDC een authenticatie service aan voor een ticket granting ticket van de andere KDC. Hiervoor wordt de onderlinge KDC sleutel gebruikt. Daarna verloopt het proces op dezelfde manier als bij toegang tot de eigen applicaties, maar nu binnen het andere regiem. Op deze wijze kan een netwerk van KDC’s gecreëerd worden.

Externe SSO: Portaal met SSO-federatie

Met single sign-on functionaliteit tussen client en webapplicatie loggen gebruikers éénmalig in bij een webapplicatie en kunnen vervolgens het portaal benaderen en alle webapplicaties, die behoren tot de groep Client SSO. Het maakt hierbij niet uit of de portaalapplicatie dan wel één van webapplicaties of de authenticerende applicatie is. De BackOffice applicaties zijn vervolgens te benaderen door op het portaal één keer in te loggen.

Portaal met SSO-federatie

Wat is er voor nodig?

Voor het inloggen op het portaal is authenticatie vereist, bijvoorbeeld met DigiD voor mijn.overheid.nl. Als aangesloten organisatie die toegang verleent via het portaal dient men zich aan te sluiten bij de SSO-federatie. Dit kan met ieder systeem. De federatie verzorgt vervolgens de gezamenlijke authenticatie.

Authenticatie

Een gebruiker logt in en authenticeert zich. Zijn gegevens worden door de server van de federatie gecontroleerd en bijgehouden. Deze authenticatie vindt bijvoorbeeld plaats op basisniveau, dat wil zeggen ‘gebruikersnaam en wachtwoord’. Organisaties bepalen zelf welk niveau authenticatie vereist is. Als het authenticatieniveau hoger is dan waarmee de gebruiker is ingelogd, ontvangt deze gebruiker een melding met het verzoek op een hoger niveau in te loggen (bijvoorbeeld met SMS-authenticatie) en wordt in de federatie het hogere inlogniveau geregistreerd.

SSO-federatie

De single sign-on federatie is de gemeenschappelijke factor – de zogenaamde ‘Federatie component’ die de sessies beheert en vaststelt of een partij een sessie kan overnemen.

Webbrowser SSO

Een provider van webservices kan de SSO authenticatie overlaten aan een derde partij, een identity provider, onder voorwaarde dat daarmee een vertrouwensrelatie bestaat. De webservice provider (“relying party”) vertrouwt de identity provider. Dit is vooral aantrekkelijk voor de eindgebruiker wanneer die al bij die vertrouwde identity provider is geregistreerd. Een dergelijke oplossing waarbij vanuit een webbrowser toegang gevraagd wordt tot de webservices van de provider is geschetst in onderstaande figuur.

Webbrowser SSO
  1. De gebruiker wil toegang tot een webservice van de provider en voert daartoe de URL van de webservice in de webbrowser in. De browser moet daarbij aangeven welke identity provider gebruikt moet worden.
  2. Als de gebruiker nog niet al van een andere service gebruik maakt (er is nog geen geldige context van die gebruiker aanwezig) dan dient deze eerst geauthenticeerd te worden. De webservice provider stuurt hiervoor een SAML verzoek naar de webbrowser die geherrouteerd wordt naar de identity provider.
  3. De identity provider vraagt de gebruiker zich te authenticeren.
  4. Na geldige authenticatie genereert de identity provider een SAML antwoord (de z.g. Assertion van de identiteit) en stuurt dat naar de webbrowser die het weer doorstuurt naar de URL van de webservice. De webservice provider verifieert het SAML antwoord (op basis van de public key van de identity provider) en maakt een geldige context voor die gebruiker aan.
  5. De webservices provider verleent de gebruiker toegang en herrouteert de webbrowser naar de desbetreffende service.

Als de gebruiker vervolgens een andere service wil toepassen, dan hoeft niet opnieuw te worden ingelogd (single sign-on) omdat er al een geldige context aanwezig is. In het voorbeeld wordt na het verzoek (1) direct de service (5) geleverd. De context wordt ongeldig zodra wordt uitgelogd en de gebruiker krijgt geen toegang meer tot de services (single sign-off) totdat er opnieuw wordt geauthenticeerd.

Afwegingen

  • Het gebruik van SSO leidt tot een stapeling van risico’s: als het password van de gebruiker in verkeerde handen komt, dan vallen alle rechten die de gebruiker zijn toegekend in verkeerde handen. Dit staat tegenover de risicoverlaging van het opschrijven van wachtwoorden.
  • Bij single sign-on moet overwogen worden of één sign-on afdoende is voor alle achterliggende toepassingen.
  • SSO wordt gekenmerkt door “eilanden rond grote softwareleveranciers”. Binnen één technologie voor applicatieservices (Microsoft, Oracle, Tivoli, CA) is er veel mogelijk, maar bruggen tussen deze werelden en de mogelijkheden voor het aansluiten van ‘als standalone’ ontwikkelde applicaties zijn vaak onvolwassen. Voor de bruggen tussen de werelden bestaan ontwikkelingen zoals SAML. Voor de standalone applicaties is men afhankelijk van de ontwikkelaar.

Voorbeelden

Implicaties

Single sign-on impliceert standaardisatie van de interfaces naar de achterliggende systemen. Vooral wanneer applicaties draaien op verschillende soorten applicatieplatformen, (bijvoorbeeld Microsoft, Oracle, Tivoli en IBM-applicaties) is het realiseren van betrouwbare single sign-on niet eenvoudig. Met single sign-on krijgt een gebruiker met slechts één gebruikersnaam/wachtwoordcombinatie toegang tot meerdere informatiebronnen. De impact van compromittering van de credentials wordt daarmee evenredig groter wat al snel een reden kan zijn om sterke authenticatie (met token en/of biometrie) toe te passen. Bij SSO oplossing is sprake van externalisering van authenticatie, dat wil zeggen dat het door een centrale voorziening wordt uitgevoerd in plaats van door elke applicatie afzonderlijk. Om SSO geen single-point-of-failure te laten zijn, dient deze voorziening dubbel te worden uitgevoerd.

Gerelateerde patronen

  • Themapatroon Identity & Access Management
  • Federated Identity & Access Management

Standaarden

Overgenomen van "https://www.noraonline.nl/index.php?title=Patroon_voor_single_sign-on&oldid=7835"