Veel bedrijfsapplicaties verschuiven van on-premise naar de cloud. In plaats van Office op het netwerk kiezen zij bijvoorbeeld voor Office365 of Google Apps. Voor het toepassen van Single Sign On (eenmalig inloggen) is deze ontwikkeling ongunstig. In een situatie waarbij het werkstation en de applicaties zich binnen het bedrijfsnetwerk bevinden, is het toepassen van Single Sign On eenvoudig. De gebruiker authentiseert zich met zijn gebruikersnaam en wachtwoord tegen de Active Directory en wanneer dat is gedaan kan Single Sign On worden toegepast. Voor iedere applicatie die de gebruiker vervolgens opent, hoeft hij geen wachtwoord en gebruikersnaam in te voeren.
Wanneer het gaat om cloud-applicaties ontbreekt de relatie tussen de gebruiker en de cloud-applicatie, namelijk het bedrijfsnetwerk en de Active Directory. Bedrijven moeten op zoek naar een ander mechanisme om gebruikers zichzelf te laten authentiseren en Single Sign On voor cloud-applicaties mogelijk te maken.
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 login-credentials in te voeren, op andere applicaties.
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. Dat gebeurt echter wel met de logingegevens van zakelijke applicaties.
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 (Bring Your Own Identity), die vervolgens kan worden gebruikt om zich automatisch te authentiseren voor andere resources. In deze omschrijving kan Facebook, LinkedIn en Google als trusted source dienen. En omdat medewerkers zeer betrokken zijn bij hun social media account, kun je je afvragen of deze accounts ook niet als Identity Provider kunnen dienen voor toegang tot bedrijfsinformatie.
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.
Arnout van der Vorst (a.van.der.vorst@tools4ever.com) is Identity Management Architect bij Tools4ever, expert in Identity & Access Management.
Hoi Arnout,
Interessante suggestie. De suggestie zoemt al enkele jaren rond, maar vindt vooralsnog weinig weerklank in de zakelijke markt. Maar dat ligt niet, zoals je stelt, voornamelijk aan een gebrek aan vertrouwen van de IT-manager. Het ligt meer aan het gebrek aan vertrouwen van zakelijke managers enerzijds en veel gebruikers anderzijds. Niet zo gek als je bedenkt dat diezelfde sociale media constant op zoek zijn naar nieuwe manieren om te verdienen aan de persoonlijke informatie van de gebruiker. Wat thuis voor velen (lang niet iedereen!) een acceptabele ruil is voor gebruiksgemak en een gratis dienst, wordt als ongepast beschouwd in een zakelijke omgeving waar databeveiliging gewoon professioneel geregeld dient te worden. En dan mag best betaald worden met euro’s in plaats van met gebruik(er)sdata.
Groet,
Peter
Ha Arnout,
Tijdje niet gezien!
Ik zie dit punt uiteraard in de dagelijkse praktijk langskomen. Gebruikers willen enterprise-single-sign-on. Dus intern aangemeld moet ook extern aangemeld zijn. Daar hebben we in principe geen cloud authenticator voor nodig. Want welke kun je vertrouwen? Facebook en Google in ieder geval niet. De geheide oplossing lijkt me dat de lokale credentials via SAML naar de cloud partij worden overgebracht. Veel cloud leveranciers zijn hier zonder meer toe in staat. Het voorkomt weer externe vastlegging en afhankelijkheden.
Deze oplossing werkt prima in een ouderwetse omgeving op kantoor of onderweg waar de eindgebruiker is geauthenticeerd binnen een gesloten omgeving. Dan zijn de credentials beschikbaar. In een volle cloud infrastructuur, zonder eigen inlog, verandert de zaak. Want dan authenticeer je je bij de eerste clouddienst die je opstart. Hoe krijg je dan single-sign-on naar de volgende clouddienst? Ik denk dat we in dat geval zeker wel een cloud authenticator nodig hebben. Ik teken hem al in architectuurplaatjes binnen de cloud strategie. Voor de eerste tien jaar verwacht ik een hybride situatie met authenticatie intern. Zijn we dan aan een cloud authenticator toe dan hoop ik dat er inmiddels een keuze uit betrouwbare partijen is!
Groetjes,
Hans
Leuk en zinvol artikel van Arnout. helaas zien wij in het bedrijfsleven een grote groei van goed beveiligde applicaties die in een DMZ draaide met VPN en token beveiliging naar een vrij ‘open’ cloud infrastructuur waarmee de security vaak zo overboord wordt gezet. Echter met oplossing zoals two factor authenticatie (zie ook: http://www.wesecure.nl/oplossingen/netwerkbeveiliging/two-factor-authentication )
middels SAML2 protocol kun je het security niveau van de cloud services een stuk hoger leggen