Hoe ga je om met gebruikersidentiteit in de cloud?

Identity management is een hot topic momenteel en dat zal door de komst van cloud-technologie en -oplossingen de komende jaren alleen maar belangrijker worden. Want hoe bescherm je als organisatie de toegang tot informatie in de cloud en hoe waarborg je de privacy van de medewerkers? Terecht wordt hier kritisch naar gekeken. Hoe veilig is het bijvoorbeeld om met één inlogaccount te werken en hoe kan het bedrijfsnetwerk aan de cloud gekoppeld worden? Dit artikel gaat over de manieren om gebruikers te identificeren in de cloud.

Het principe van authenticatie stamt nog uit de tijd dat gebruikers zich moesten identificeren op mainframes met een 001 code en een wachtwoord dat alleen uit cijfers kon bestaan. Daardoor zijn authenticatiemechanismen erg gericht op de interne bedrijfsvoering van organisaties. Tegenwoordig kunnen we met onze social media accounts op allerlei externe sites inloggen. Bijvoorbeeld met je Facebook-account inloggen op Foursquare of YouTube.

Het principe van het inloggen met één account, ook wel de ‘single sign-on experience' genoemd, en daarmee toegang hebben tot verschillende applicaties is voor organisaties ook erg wenselijk. Maar hoe zit het met bedrijfsapplicaties die in de cloud draaien, zoals bijvoorbeeld Microsoft Office 365? Hoe kun je daar via ‘single sign-on' inloggen?

Om met een authenticatiemechanisme, of inlogmechanisme te werken is een database of een Active Directory nodig. De Active Directory is de plek waar accountinformatie, zoals de inloggegevens van een gebruiker, is opgeslagen en die geraadpleegd wordt op het moment dat een gebruiker gaat inloggen.

Er zijn organisaties die op dit moment nog helemaal niet met een Active Directory werken omdat ze bijvoorbeeld relatief weinig mensen in dienst hebben. Echter, omdat de cloud juist zo toegankelijk is voor kleinere organisaties heeft Microsoft een mechanisme ontwikkeld waarmee deze organisaties op een eenvoudige manier een inlogmechanisme kunnen opzetten.

De middelgrote en enterprise organisaties werken vaak al met een authenticatiemechanisme met bijbehorende Active Directory die ze zelf onderhouden en waarover ze zelf controle hebben. Als er dan gekozen wordt om oplossingen in de cloud te zetten, gaat de voorkeur naar het behoud van de single sign-on experience. Met andere woorden, gebruikers moeten met hun bestaande inlognaam en wachtwoord zowel intern kunnen inloggen als extern op een Microsoft Office 365 cloud-omge-ving. Voor al deze typen organisaties biedt Microsoft oplossingen om authenticatiemechanismen op te zetten.

Authenticatiebronnen en -vormen

Voordat we het over de authenticatiemechanismen hebben, is het belangrijk te weten via welke kanalen een gebruiker zijn cloud-applicatie kan benaderen. De belangrijkste bronnen van herkomst zijn:

• via de browser (Internet, Firefox, etcetera) op bijvoorbeeld het bestaande intranet,
• via de Client-applicaties zoals Outlook, Lync, Office-documenten als Word en Excel,
• via Mobiele apparaten zoals Windows Phone, iPad of iPhone.

Het is belangrijk dat het authenticatiemechanisme kan omgaan met deze bronnen zodat de gebruikers herkend kunnen worden én gecontroleerd kan worden of zij wel toegang tot de desbetreffende applicatie of documenten hebben.

Om je als gebruiker te kunnen identificeren in de cloud biedt Microsoft twee mogelijkheden. De eerste is Microsoft Online Services en de tweede is Active Directory Federation Services. Er is ook nog een Partner Acces waarmee mensen die niet verbonden zijn aan de organisatie uitgenodigd kunnen worden. Maar deze laten we in dit artikel even buiten beschouwing.

Microsoft Online Services voor kleinere organisaties

Met Microsoft Online Services kunnen relatief eenvoudig gebruikersprofielen worden aangemaakt binnen een Office 365-omgeving. Via een inlognaam en wachtwoord kan een gebruiker inloggen op de cloud-omgeving. Dit is met name interessant voor kleinere organisaties tot ongeveer 50 personen die voor het eerst gaan werken met een Microsoft Office 365-omgeving. Via een import uit Excel kunnen in één keer meerdere profielen ge-upload worden en als er mensen in dienst of uit dienst gaan, worden deze profielen toegevoegd of verwijderd. Voor de gebruiker betekent dit wel dat hij twee keer moet inloggen. Eén keer op zijn interne netwerk en één keer op de cloud-omgeving. Er zijn dus twee identiteiten voor een gebruiker.

Het onderhoud en beheer van de gebruikers-profielen gebeurt ook op twee plaatsen: het interne netwerk en in de cloud-omgeving zoals in dit geval Microsoft Office 365. Voor kleine organisaties is dit op zich nog wel te overzien, voor grotere organisaties wordt dit wat omslachtiger omdat er dan veel meer gebruikers zijn. Dit allemaal handmatig onderhouden is veel te arbeidsintensief.

Doordat er met Microsoft Online Services met twee identiteiten wordt gewerkt voor de gebruiker is er geen sprake van een single sign-on. De opzet van een authenticatiemechanisme is juist om het de gebruiker zo makkelijk mogelijk te maken zodat deze zo min mogelijk hoeft in te loggen. Dat betekent bij voorkeur één keer per dag inloggen en maximaal twee keer per dag. Als gebruikers meer dan twee keer per dag moeten inloggen, vinden ze dat snel vervelend.

Desktop Setup assistant

Om toch te voorkomen dat de gebruiker meerdere keren per dag moet inloggen om toegang tot de cloud-applicaties te krijgen heeft Microsoft een tool ontwikkeld. Deze heet de ‘Microsoft Office 365 Desktop Setup Assistant'. Als de gebruiker voor de eerste keer naar het Office 365-intranet gaat, wordt er automatisch een programma op de desktop van die gebruiker geïnstalleerd. Dit programma zorgt er onder andere voor dat als de gebruiker de volgende keer in een Office 365-applicatie is ingelogd, er niet nog een tweede keer ingelogd hoeft te worden. Deze tool omzeilt als het ware het vele inloggen op Office-applicaties om zo toch een soort verborgen single sign-on experience te creëren. De tool zorgt er verder ook voor dat Microsoft Office up-to-date blijft en dat de service packs en patches geïnstalleerd worden. Eindgebruikers werken zo altijd met de nieuwste versie van het desbetreffende Microsoft-product.

DirSync

Microsoft Online Services is dus met name interessant voor organisaties tot ongeveer 50 medewerkers. Voor organisaties die groter zijn heeft Microsoft ook een oplossing. De Directory Sync, kort gezegd ook wel DirSync.

Bij DirSync zijn er twee Active Directory's. De bestaande on-premise Active Directory op het interne netwerk en de gekopieerde versie, via DirSync, in de cloud. Met andere woorden: de cloud Active Directory wordt in sync gehouden met de Active Directory op het interne netwerk. Alle basisinformatie van de gebruiker die in zijn profiel staat wordt ook gesynchroniseerd naar de cloud. Het enige dat niet meegesynchroniseerd wordt zijn de wachtwoorden van de gebruikers, dit is uit veiligheidsoverwegingen. Ook in dit geval is er dan nog steeds geen single sign on-ervaring. In de cloud is er wel een accountnaam, maar geen wachtwoord. De gebruiker kan het wachtwoord wel hetzelfde maken als op het interne netwerk, maar dit moet dan wel weer handmatig gebeuren. Het zijn nog steeds twee gescheiden accounts en dus identiteiten.

Volledige controle

Het voordeel van de DirSync is dat er volledige controle is op de accounts en dat deze maar op één plek onderhouden hoeven te worden, namelijk in de Active Directory op het interne netwerk. Als er dus een nieuw account wordt aangemaakt omdat iemand nieuw in dienst komt, hoeft dit account alleen in de Active Directory op het interne netwerk aangemaakt te worden. Via DirSync wordt er automatisch ook een account in de cloud aangemaakt.

Voor organisaties die meer dan 50 medewerkers hebben en al met een Active Directory werken verandert er in principe niet veel. Daar wordt al onderhoud en beheer op de accounts gedaan. Maar via DirSync worden deze accounts ook automatisch in de cloud aangemaakt om gebruikers toegang te geven tot de Office 365-omgeving. Het enige wat extra gedaan moet worden is voor de cloud-variant een apart wachtwoord instellen. Voor de gebruiker betekent dit in de praktijk dat hij nog steeds twee keer moet inloggen.

Microsoft Online Services en DirSync vallen beide onder de noemer Microsoft Online Services. Orga-nisaties die al dan niet een eigen IT-afdeling hebben, kunnen snel een authenticatiemechanisme opzetten, er is geen grote infrastructuur nodig en er hoeven niet allerlei servers aangeschaft te worden. DirSync is niet heel complex, het kan vrij eenvoudig opgezet worden. Alleen zal een gebruiker altijd twee keer moeten inloggen. Een gebruiker heeft dus verschillende identiteiten.

Active Directory Federation Services

Voor organisaties die echt voor een volledige single sign-on experience willen gaan, heeft Microsoft de Active Directory Federation Services. De technische uitleg is ‘creëer een federation trust tussen een Active Directory in het interne netwerk en een Active Directory in de cloud'. Hiermee wordt dus een volledige single sign-on experience gerealiseerd. Eén wachtwoord, één account, één user, één identiteit. De gebruiker is wie hij zegt dat hij is en met zijn wachtwoord heeft hij toegang tot het interne netwerk als ook tot de applicaties in de cloud. Echter, de authenticatie vindt plaats via de Active Directory in het interne netwerk.

De infrastructuur van een Active Directory Federation Services opzet is wat uitgebreider. Ook in deze opzet wordt gebruik gemaakt van DirSync. Hoe het principe van Active Directory Federation Services werkt proberen we uit te leggen aan de hand van de afbeelding op de volgende pagina.

De gebruiker (0) wil inloggen op de Office 365-omgeving (1). Vanuit de Office 365-omgeving wordt er een signaal afgegeven dat een gebruiker toegang wil en dat er gebruik gemaakt wordt van Active Directory Federation Services (ADFS). Office 365 kan nu niet authenticeren dus het verzoek wordt via de laptop (2) doorgestuurd naar de ADFS-server (3) in de cloud. Deze server stuurt het verzoek via de laptop (4) weer door naar de ADFS-server op het interne netwerk (5) om ook daadwerkelijk via de Active Directory (6) bevestigd te krijgen dat de gebruiker is wie hij zegt dat hij is in combinatie met het wachtwoord dat hij gebruikt. Deze goedkeuring (authenticatie) gaat dan weer via de laptop (7) naar de Office 365-omgeving (8) en vervolgens kan de gebruiker daadwerkelijk inloggen.

De federation trust in dit verhaal is dat Office 365 niet meer zelf authenticeert omdat er gebruik gemaakt wordt van Active Directory Federation Services. De gebruiker wordt via het interne netwerk van de organisatie geauthenticeerd. Als er vanuit dit netwerk een ‘goedkeuring' wordt afgegeven heeft de gebruiker toegang tot de cloud-omgeving.

Net als bij DirSync is er ook bij Active Directory Federation Services maar één plek waar alle accounts worden onderhouden en beheerd, namelijk op het interne netwerk. Hier worden de profielen onderhouden. Via DirSync wordt alles in de cloud gezet. In dit geval is er voor de gebruiker ook een single sign on experience, hij heeft met één gebruikersnaam en wachtwoord toegang tot zowel het interne netwerk als de cloud-omgeving. Er zit wel een nadeel aan de Active Directory Federation Services-oplossing. Omdat er ingelogd wordt vanuit het interne netwerk en dit netwerk ligt er bijvoorbeeld uit door een storing, dan is er ook geen toegang mogelijk tot de cloud-omgeving.

Conclusie

Samengevat is Active Directory Federation Services voor de eindgebruiker een single sign-on experience, hij hoeft maar één keer in te loggen. Organisaties hoeven maar op één plek de accounts aan te maken en te onderhouden. Het is wel heel belangrijk dat de Active Directory op het interne netwerk volledig up-to-date is en gevuld is met de juiste informatie. Daarnaast vergt de Active Directory Federation Trust ook wel wat van de infrastructuur, er zijn meer servers nodig zoals de ADFS-server en een ADFS Proxy-server en indien gewenst willen organisaties deze ook dubbel uitvoeren. En zo is er nog een aantal zaken die belangrijk zijn maar die we nu verder buiten beschouwing laten.