Artikel

De toekomst van Single Sign-On

Facebook als Identity Provider

Met de komst van cloudapplicaties wordt het toepassen van Single Sign-On in het bedrijfsnetwerk een stuk complexer. Sociale media lijken een goede kans te maken om de rol van identity provider te gaan vervullen.

TTen applicaties nog geheel ‘on-premise’ beheerd werden, was de implementatie van een Single Sign-Onoplossing vrij eenvoudig. Het werkstation van de medewerker bevond zich immers in het netwerk, evenals de applicaties waar die toegang toe wilde hebben. De medewerkers authentiseren
zich met hun gebruikersnaam en wachtwoord tegen de Active Directory en via een LDAP-standaard kunnen zij de voordelen van Single Sign On ondervinden. Voor iedere applicatie die de gebruiker vervolgens opent, hoeft hij geen wachtwoord en gebruikersnaam in te voeren.

Met de komst van cloudapplicaties wordt het toepassen van Single Sign-On in het bedrijfsnetwerk een stuk complexer. Veel applicaties bevinden zich nu in een ander technisch domein, de cloud, waardoor de relatie tussen de gebruiker en de applicatie, namelijk het netwerk en de Active Directory, niet langer aanwezig is. Naast de komst van cloudapplicaties maakt ook de trend richting Bring Your Own Device (BYOD) het toepassen van Single Sign-On complexer. Het device waarmee de gebruiker wil inloggen is nu flexibel. Het is niet alleen de pc van de werknemer, maar kan bijvoorbeeld ook een telefoon of tablet zijn. De medewerker wil ook nog eens locatie-onafhankelijk toegang hebben tot de benodigde applicaties.

OpenID en SAML

Single Sign On is niet meer dan dat een gebruiker zich authentiseert tegen een trusted source. Wanneer dat succesvol is gedaan, krijgt de gebruiker een token mee, die vervolgens kan worden gebruikt om zich automatisch te authentiseren voor andere resources. Wanneer applicaties
zich in de cloud bevinden, ontbreekt de ‘trusted source’ waartegen gebruikers zich kunnen authentiseren om toegang te krijgen tot bedrijfsapplicaties. Dit is normaal gesproken namelijk de Active Directory.
Organisaties proberen dit op te lossen door gedecentraliseerd authenticatiemechanismen zoals OpenID en SAML in te zetten. Het probleem hierbij is dat je als organisatie afhankelijk bent van de leveranciers van cloudapplicaties. Als een organisatie heeft gekozen voor OpenID als
authenticatiemechanisme ontstaat er een probleem als de gewenste cloudapplicatie alleen SAML ondersteund. Helaas besteden leveranciers van cloudapplicaties weinig tijd aan het loginproces. Hun focus ligt op het ontwikkelen van nieuwe functionaliteiten in hun applicaties.
Het advies aan organisaties is te kiezen voor een model waarbij men niet afhankelijk is van interfaces en leveranciers. Er zijn diverse leveranciers van zogenaamde Enterprise Single Sign-Onoplossingen, waarbij de SSO-client zich bevindt op iedere willekeurige applicatie van de medewerker en zo dus BYOD ondersteunt. Wanneer de medewerker een applicatie aanroept, al dan niet in de cloud, herkent de software het inlogscherm van de applicatie en vult het automatisch de juiste logingegevens in. Deze logingegevens zijn encrypted opgeslagen in een SSO-database in het netwerk.

Omdat dit model gebaseerd is op herkenning van loginschermen en dus niet afhankelijk is van het authenticatiemechanisme die de leverancier ondersteunt, is het zeer krachtig. Het grootste voordeel is dat dit altijd werkt voor alle applicaties, onafhankelijk van het type (web, java, client/server, telnet, mainframe, Unix, Windows, etc.), waar deze zich bevindt (LAN, datacenter, Cloud, etc.), vanaf een willekeurige apparaat (Windows PC, Android, Tablet, Smart phone, iOS, etc.) en vanaf iedere locatie
(werk, thuis, onderweg, buitenland, niet verbonden laptop, etc.). Het is dus mogelijk om eindgebruikers in alle gevallen SSO aan te bieden.

Facebook
Binnen de consumentenbranche worden social media accounts, zoals Facebook en Google, vaak gebruikt als Identity Provider. Wanneer gebruikers zijn ingelogd op Facebook kunnen zij ook automatisch inloggen, zonder logincredentials in te voeren, op andere applicaties.
Bijvoorbeeld als de gebruiker is ingelogd in Facebook, kan hij automatisch toegang krijgen tot bijvoorbeeld Spotify, wanneer die accounts aan elkaar zijn gekoppeld. Of Facebook foto’s worden automatisch opgeslagen op Picasa.

Mensen zijn vaak meer betrokken bij hun eigen Facebook account dan het Active Directory account van hun werk. Het zal niet vaak voorkomen dat mensen de logingegevens van hun social media accounts op een post-it schrijven, zoal wel gebeurt met de logingegevens van zakelijke applicaties. Daarom kun je je afvragen of deze accounts ook niet als Identity Provider kunnen dienen voor Single Sign-On toegang tot bedrijfsinformatie. Wanneer medewerkers ingelogd zijn op hun Facebook kunnen zij ook automatisch (SSO) toegang krijgen tot  bedrijfsinformatie op systemen on-premise en in de cloud. Dit wordt ook wel BYOID (Bring Your Own Identity) genoemd. De Britse overhead is al bezig om burgers de mogelijkheid te bieden om hun social media identity te gebruiken om overheidsdiensten te
benaderen, als onderdeel van het Identity Assurance (IDA) programma. Banken zullen niet vertrouwen op Facebook als ID-provider bij het doen van risicovolle transacties. Echter dat zullen zij wel kunnen doen als het gaat om het distribueren van marketing materiaal of het beantwoorden
van een verzoek voor het openen van een rekening. Zeker nu social media leveranciers zwaar gaan inzetten op extra authenticatiemiddelen (bv. locatiebepaling) ben ik van mening dat social
media accounts in de toekomst zeer goed kunnen dienen als Identity Provider voor ook zakelijke applicaties en bedrijfsinformatie. Om het zover te laten komen, moeten IT-managers nog wel een stap maken en meer vertrouwen krijgen in deze leveranciers. Waarbij ze zich wel moeten realiseren dat bij het uitbesteden van de identificatie de verantwoordelijkheid van de ID-provider stopt bij het aanleveren van de juiste identity-gegevens. Wat je er vervolgens mee doet, en dat is belangrijker, ligt bij de ontsluiter van de applicatie. Het is authenticatie (BYOID) versus autorisatie, en van dat laatste ben je zelf nog altijd eigenaar in je applicatie.

Categorie:   
Auteur(s)
afbeelding van tseinen
Tjeerd Seinen
Tools4ever - Technisch Account Manager

Tjeerd Seinen als account manager werkzaam bij Tools4ever in Nederland. Hij beschikt over zowel een technische als commerciële achtergrond en hij is daardoor in staat om kansen in de markt om te zetten in functionaliteiten voor producten en consultancy diensten. Tjeerd heeft meer dan 20 jaar ervaring op het gebied van sales en softwareontwikkeling. Hij studeerde technische informatica aan de Hogeschool van Amsterdam. Daarnaast rondde hij de MBA-opleiding van het NIMBAS in Utrecht met succes af.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.