Inleiding

‘Who am I?’ In the context of the online world, the answer to this perennial question would be something like ‘I am a collection of disconnected islands of identity information … which I have to maintain.’ ([Sull05])

Diensten als elektronisch bankieren, on line bestellen en opvragen van (betaalde) informatie klinken niemand meer ongewoon in de oren. Allemaal diensten die ons het leven makkelijker maken. Openbare netwerken zoals internet stellen ons in staat ‘anywhere’ en ‘anytime’ informatie op te vragen. Door het slim inzetten van internet als afzetkanaal kan de dienstverlening aan klanten worden verbeterd. Bovendien kunnen forse kostenvoordelen worden behaald door het verlichten van de administratieve lasten en het à la minute verwerken van transacties. Naast de hiervoor genoemde voordelen kleeft er echter ook een aantal nadelen aan het elektronisch aanbieden van diensten, die we intussen allemaal wel kennen. Zo dienen processen vaak te worden heringericht, zal de dienst moeten worden onderhouden en, last but not least, zal de informatiebeveiliging op orde moeten worden gebracht. Vooral dit laatste is van belang, want door het aanbieden van elektronische diensten via internet staat men immers bloot aan bedreigingen vanuit de gehele wereld.

Een belangrijke maatregel in het palet van informatiebeveiliging is het implementeren van logische toegangsbeveiliging. In de praktijk betekent dit dat gebruikers worden voorzien van een unieke gebruikers-id en een authenticatiemiddel waarmee hun identiteit kan worden geverifieerd (zoals een wachtwoord of beveiligingscalculator). Tevens worden de gebruikers voorzien van rechten (autorisaties) zodat zij persoonlijke informatie kunnen inzien of wijzigen en transacties kunnen verrichten. Als een gebruiker elektronische diensten afneemt van verschillende organisaties, wordt deze gebruiker voorzien van evenzovele verschillende gebruikers-id’s en authenticatiemiddelen. Ga maar eens na hoeveel gebruikersnamen, wachtwoorden, pincodes en tokens u momenteel bezit. En vergeet vooral niet die van uw webmail, internetwinkels, nieuwsgroepen, bankpassen en uw werk mee te tellen. Juist om de omvang van deze digitale sleutelbos te verkleinen is er de laatste jaren een nieuwe trend ontstaan. Deze trend wordt ‘federated identity management’ genoemd en heeft tot doel het terugdringen van het grote aantal gebruikers-id’s en authenticatiemiddelen, de beheerlast ervan te verminderen en het algehele beveiligingsniveau te verhogen.

In dit artikel wordt ingegaan op wat authenticatie precies is en wat de nadelen zijn van de huidige geïsoleerde oplossingen. Vervolgens wordt het concept van federated identity management geïntroduceerd en uitgelegd, worden de voordelen ervan genoemd en enkele praktijkvoorbeelden gegeven.

Identificatie, authenticatie en autorisatie uiteengezet

Identificatie, authenticatie en autorisatie zijn in het kader van informatiebeveiliging veelvoorkomende termen. Deze concepten worden vaak in één adem genoemd, maar wat is nu precies het verschil?

In de context van logische toegangsbeveiliging wordt identificatie omschreven als het proces inzake het vaststellen van de identiteit van een communicatiepartner, zoals een website, machine of persoon. De gebruikers-id is het meest voorkomende gegeven dat wordt gehanteerd om de identiteit van een gebruiker uniek vast te stellen. Daarnaast kan ten behoeve van het identificatieproces van machines het IP-adres van het systeem of het MAC-adres van een netwerkkaart worden toegepast. Vanzelfsprekend is louter een identificatie niet voldoende om met zekerheid vast te kunnen stellen met welke gebruiker precies wordt gecommuniceerd. In een elektronische omgeving is het immers voor een kwaadwillende partij vrij eenvoudig zichzelf voor te doen als een andere identiteit (spoofing). Authenticatie biedt hiervoor een oplossing en staat voor het verifiëren van de identiteit waarvoor een bepaalde partij zich uitgeeft. Een in praktijk veelvoorkomend authenticatiemiddel is het wachtwoord dat behoort bij een specifieke gebruiker. Door de combinatie van een gebruikers-id en wachtwoord te controleren, kan de door de gebruiker geclaimde identiteit met grotere zekerheid worden vastgesteld. Andere voorbeelden van authenticatiemiddelen zijn digitale certificaten (PKI) en challenge/response-tokens. Nadat een gebruiker succesvol is geauthenticeerd, dient een organisatie te bepalen welke rechten en permissies deze geauthenticeerde gebruiker heeft. Het bepalen en verlenen van rechten en permissies aan een bepaalde identiteit wordt autorisatie genoemd. Nadat autorisatie is verleend, kan de gebruiker gebruikmaken van de elektronische dienstverlening, zoals het inzien van informatie of verrichten van transacties.

In dit artikel zal vooral worden ingegaan op het stroomlijnen van de stappen identificeren en authenticeren met behulp van het toepassen van federated identity management. De problematiek rondom het beheer van autorisaties wordt in het artikel van Hermans en Ter Hart behandeld.

Problemen bij het beheer van gebruikers-id’s

Tot voor kort werd het toekennen van gebruikers-id’s en wachtwoorden veelal per applicatie of toepassing geregeld. Hierdoor ontstaan als het ware geïsoleerde eilanden van gebruikers, met alle nadelen van dien. Enkele problemen waar veel organisaties mee worstelen zijn hieronder weergegeven.

Arbeidsintensief

Organisaties richten vaak per applicatie of dienst een proces in ten behoeve van het uitgeven, beheren en ondersteunen van gebruikers-id’s en bijbehorende authenticatiemiddelen. Dergelijke processen vormen normaliter geen onderdeel van de reguliere bedrijfsvoering en vergen doorgaans grote inspanning die vaak gepaard gaat met aanzienlijke (initiële) kosten. Vooral helpdeskactiviteiten en administratieve overhead voor het gebruikersbeheer en het resetten van wachtwoorden zijn vaak arbeidsintensief en kostbaar (de uitgifte van wachtwoorden is helaas toch niet gratis…). Dit effect wordt versterkt wanneer aan steeds meer soorten partijen toegang wordt verschaft, zoals werknemers, klanten, partners, leveranciers, accountants, consultants en andere externen.

Toename van aantal beveiligingsincidenten

Doordat gebruikers te veel verschillende wachtwoorden moeten onthouden, ontstaat het risico dat zij zwakke wachtwoorden kiezen, deze opschrijven of vaak hergebruiken. Denk maar eens aan de gele plakbriefjes aan de monitor of aan het wachtwoord dat u meestal gebruikt voor uw webmail of internetaankopen. Wie garandeert u echter dat de eigenaar van een louche website waar u uw wachtwoord achterlaat, dit wachtwoord niet misbruikt om zich toegang te verschaffen tot uw e-mail of om onder uw naam in te loggen op diverse webdiensten? Op internetfora wordt met enige regelmaat melding gemaakt van dergelijke incidenten (zie kader 1).

Betrouwbaar is vaak kostbaar en complex

Een ander probleem waar organisaties tegenaan lopen is het gewenste betrouwbaarheidsniveau. Op dit ogenblik is een gebruikers-id/wachtwoord-combinatie voor veel eenvoudige diensten nog voldoende veilig, maar wanneer steeds gevoeliger vormen van dienstverlening worden aangeboden, zoals het verschaffen van toegang tot financiële gegevens of medische informatie, kan blijken dat veel van de gekozen oplossingen om bovengenoemde redenen ontoereikend zijn. Dit zou inhouden dat nieuwe authenticatiemiddelen moeten worden uitgegeven en zo ook nieuwe, soms complexe en dure, uitgifte- en beheerprocessen moeten worden ingericht.

Digitale sleutelbos

Een laatste belangrijk aspect dat speelt bij het aanbieden van elektronische diensten is de ongewenste situatie waarbij een gebruiker vanuit diverse organisaties (die elektronische diensten aanbieden) wordt voorzien van een grote verscheidenheid aan wachtwoorden, tokens en smartcards. Hierdoor ontstaat wildgroei en wordt de gebruiker geconfronteerd met een zogenaamde digitale sleutelbos. Zo is op basis van een onderzoek door KPMG ([KPMG03]) naar voren gekomen dat tachtig procent van de ondervraagden op het werk meer dan twee en veertig procent meer dan drie authenticatiemiddelen bezit. Deze digitale sleutelbos heeft een negatief effect op de gebruikersacceptatie van nieuwe authenticatieoplossingen en daarmee op de betrouwbaarheid en de beheerlast ervan.

Wat is federated identity management?

Om de totale kosten met betrekking tot uitgifte en beheer van authenticatiemiddelen te beperken en het gebruikersgemak te bevorderen is de laatste jaren een trend waarneembaar genaamd federated identity management (FIM). Het woord ‘federated’ stamt af van ‘federatie’ – een verbond van samenwerkende lichamen of staten die hun zelfstandigheid behouden ([woor])’ – en ‘identity management’ stamt af van ‘het beheer van (gebruikers)identiteiten en attributen’.

FIM kan het best worden omschreven als een stelsel van afspraken, standaarden en technologieën die het mogelijk maken om elektronische identiteiten en bijbehorende profielen overdraagbaar en uitwisselbaar te maken tussen diverse autonome domeinen, zowel binnen één organisatie als tussen organisaties onderling.

Dit betekent concreet dat een authenticatieoplossing, zoals geïmplementeerd door een bepaalde organisatie of een bepaald organisatieonderdeel, door een andere organisatie of ander organisatieonderdeel kan worden hergebruikt. FIM stelt gebruikers hierdoor in staat:

• één gebruikersaccount te verkrijgen om toegang te krijgen tot verschillende (organisatieoverschrijdende) netwerken en systemen (domeinen);
• hun gebruikersaccounts over verschillende (organisatieoverschrijdende) domeinen met elkaar te verbinden, zonder dat hierbij één centrale database met accountgegevens ontstaat;
• aan te loggen op hun account door gebruik te maken van het authenticatiemiddel van hun keuze;
• toegang te krijgen tot verschillende applicaties binnen deze (informatieoverschrijdende) domeinen door slechts één keer aan te loggen (reduced/single sign-on).

In figuur 1 is het concept van FIM op hoofdlijnen weergegeven. In de figuur wordt een gebruiker door een bepaalde organisatie geauthenticeerd met behulp van een gebruikers-id en een authenticatiemiddel, waarna de identificatiegegevens van deze geauthenticeerde gebruiker worden uitgewisseld met andere organisaties. Op basis van deze ontvangen identificatiegegevens en het bijbehorende profiel kunnen deze andere organisaties steunen op de door de eerste organisatie verrichte authenticatie, de gebruiker uniek herleiden in de eigen administratie en bepalen of deze al dan niet toegang mag worden verleend tot een elektronische dienst. Behalve identiteitsinformatie kunnen in het profiel van de gebruiker aanvullende gebruikersattributen, zoals zijn leeftijd, staan vermeld. Op basis van de vermelde leeftijd kan dan bijvoorbeeld eenvoudig worden bepaald of de van toepassing zijnde gebruiker al dan niet (wettelijk) bevoegd is om een bestelling te plaatsen.

Figuur 1. Het concept van federated identity management.

Hoe werkt federated identity management?

Nu een introductie is gegeven op FIM en de achtergrond met betrekking tot toegangsbeveiliging is geschetst, wordt in deze paragraaf dieper ingegaan op de functionele werking van FIM en de voornaamste componenten binnen een FIM-oplossing.

Functionele werking federated identity management

In figuur 2 wordt aangegeven op welke wijze een FIM-oplossing qua functionaliteit werkt. In deze beschrijving gaan we uit van John, die op basis van zijn werkaccount tevens toegang krijgt tot informatie in systemen bij zijn relaties.

Figuur 2. Functionele werking van federated identity management.

Op hoofdlijnen kunnen twee primaire processen worden onderkend, te weten het initiële registratieproces (1 en 2) en het gebruikproces (3, 4, 5 en 6).

Initiële-registratieproces

Alvorens John gebruik kan maken van elektronische diensten, dient hij te zijn geregistreerd bij een authenticatiedienst, de organisatie die het authenticatieproces voor haar rekening neemt, en in het bezit te zijn van een authenticatiemiddel. In dit voorbeeld is de werkgever van John de organisatie die optreedt als authenticatiedienst en John bij zijn indiensttreding voorziet van een unieke gebruikers-id en authenticatiemiddel (1). Nu John is geregistreerd en is voorzien van een authenticatiemiddel, kan hij gebruikmaken van de elektronische voorzieningen van zijn werkgever, zoals inloggen op het bedrijfsnetwerk en openen van zijn e-mailaccount via internet.

Omdat John en zijn collega’s vanuit hun functie vaak toegang dienen te verkrijgen tot de informatiesystemen van relaties, zoals klanten of leveranciers, heeft hun werkgever besloten een directe beveiligde verbinding (bijvoorbeeld een extranet of webservice) aan te leggen tussen de eigen systemen en die van zijn relaties. Bij het aangaan van deze vertrouwensrelaties (2) worden afspraken gemaakt over onder meer het beheer van gebruikers, beveiligingseisen, het te hanteren authenticatiemiddel, het gebruik van unieke gebruikers-id’s, technische protocollen en juridische zaken zoals aansprakelijkheid.

Gebruiksproces

Voordat John toegang wordt verleend tot het systeem van zijn werkgever, dient hij zichzelf te authenticeren met behulp van zijn authenticatiemiddel (3). Op basis van de gecontroleerde identiteit bepaalt zijn werkgever vervolgens welke rechten John binnen het bedrijfsnetwerk heeft en wordt hem autorisatie verleend (4). Wanneer John voor het verrichten van zijn werkzaamheden toegang nodig heeft tot het bedrijfsnetwerk van een relatie, draagt het informatiesysteem van Johns werkgever Johns identiteitsgegevens en eventueel aanvullende informatie over aan de relatie (5). Na ontvangst van deze identiteitsgegevens bepaalt de klant of de in het bericht vermelde identiteit (John) toegang mag worden verleend tot de gevraagde diensten. Indien John voldoende rechten heeft, kan aan hem direct autorisatie worden verleend (6). Een extra authenticatie is in dit geval overbodig aangezien de relatie weet dat John reeds door zijn werkgever succesvol is geauthenticeerd.

Voornaamste componenten binnen een FIM-oplossing

Het hiervoor beschreven scenario is qua techniek niet geheel nieuw. De afgelopen jaren zijn binnen organisaties diverse systemen ontwikkeld die interne federatie van identiteitsinformatie mogelijk maken. Een bekend voorbeeld is Kerberos dat in Microsoft-omgevingen wordt ondersteund. Wat wel nieuw is, is dat deze technieken nu ook buiten het eigen domein kunnen worden gebruikt en hierdoor aanzienlijk meer voordelen kunnen worden behaald. Dit maakt de problematiek echter ook aanzienlijk complexer, omdat nu allerlei additionele afspraken moeten worden gemaakt. De voornaamste aandachtspunten zijn hieronder weergegeven. Hierbij is een onderscheid gemaakt naar technische, functionele en organisatorische componenten.

Technisch

• FIM-systeem. Dit is de voorziening die ervoor zorgt dat identiteiten aan elkaar kunnen worden gerelateerd, policies kunnen worden gedefinieerd en gebruikers- en authenticatie-informatie kunnen worden uitgewisseld tussen verschillende partijen en domeinen. Dit systeem vormt het kloppende hart van een FIM-oplossing. Voorbeelden van dergelijke systemen zijn de FIM-pakketten van RSA en IBM (Tivoli) en het open source-product A-Select.
• Directories. Dit zijn databases waarin informatie is opgeslagen over gebruikers zoals gebruikers-id’s, (sterkte van) verstrekte authenticatiemiddelen, gebruikersattributen en rollen.
• Interfaces. Het FIM-systeem zal diverse technische interfaces hebben met verschillende applicaties, webdiensten, domeinen, directories en authenticatieservers. Bij voorkeur wordt hierbij gebruikgemaakt van de aanwezige standaarden voor FIM.
• Authenticatiemiddelen. Bij een FIM-oplossing steunen applicaties op een gebruikersauthenticatie die plaatsvindt op basis van een authenticatiemiddel. Bij een FIM-oplossing zal minimaal één authenticatiemiddel moeten worden uitgegeven aan gebruikers.

Functioneel

• Gebruikersbeheer. Wanneer een gebruiker uit dienst gaat of een andere functie of rol krijgt, kan het zijn dat zijn recht om een bepaald authenticatiemiddel te gebruiken wordt ingetrokken. Het proces met betrekking tot gebruikersbeheer regelt de uitgifte en intrekking van gebruikers-id’s, attributen en, indien van toepassing, authenticatiemiddelen.
• Authenticatiedienst. Dit is een partij die gebruikers identificeert en de gebruikers voorziet van een gebruikers-id en authenticatiemiddel. De authenticatiedienst verricht tevens de authenticatie van gebruikers voor dienstaanbieders en gebruikt hiervoor doorgaans een authenticatieserver en een gebruikers- en authenticatiedatabase.
• Dienstaanbieder. Dit is een partij die één of meer online-diensten aanbiedt en voor de authenticatie van haar gebruikers gebruikmaakt van de authenticatiediensten van één of meer authenticatiediensten.

Organisatorisch

• Mapping van identiteiten. Gebruikers-id’s worden in de praktijk veelal niet consistent toegepast. Zo kan het voorkomen dat een gebruiker bij een bepaalde toepassing bekendstaat onder gebruikers-id ‘JJansen’ en bij andere toepassingen als ‘12345’ of ‘JanJansen21’. Omdat het in al deze gevallen om dezelfde gebruiker gaat, zullen deze gebruikers-id’s binnen een FIM-oplossing aan elkaar moeten worden gerelateerd. De mapping van identiteiten wordt vastgelegd in bijvoorbeeld een verwijsindex. Een alternatief voor de mapping van identiteiten is (organisatieoverschrijdende) afspraken te maken over het gebruik van één uniek gebruikers-id voor alle gebruikers. De authenticatiedienst en de dienstaanbieder zijn gezamenlijk verantwoordelijk voor de mapping van gebruikers-id’s.
• Afspraken. Alle bij een FIM-oplossing betrokken partijen (authenticatiediensten en dienstaanbieders) zullen met elkaar afspraken moeten maken over het gebruik van elkaars authenticatiemiddelen, gebruikersinformatie, te hanteren technische protocollen, vereiste betrouwbaarheidsniveau en juridische aansprakelijkheid.

FIM-architectuur

Figuur 3 geeft een overzicht van een wat complexere FIM-architectuur. De architectuur beschrijft een hypothetische oplossing waarbij een bank, een overheidsinstelling, een verzekeraar, een zorgverlener en een pensioenfonds afspraken hebben gemaakt over het onderling gebruik van de identiteitsinformatie van de bank en de overheidsinstelling.

Figuur 3. Voorbeeld van een FIM-architectuur. [Klik hier voor grotere afbeelding]

Wanneer John bijvoorbeeld via de intranetsite van zijn werkgever inlogt om vervolgens toegang te krijgen tot één van de achterliggende diensten, krijgt hij een keuzescherm te zien met welk authenticatiemiddel hij zich wenst te authenticeren. Hij kan hierbij kiezen of hij gebruik wil maken van het token (token 1) dat hij van zijn bank heeft verkregen of van een wachtwoord (PWA) dat hij van de overheidsinstelling heeft gekregen.

Afhankelijk van zijn keuze wordt John door het FIM-systeem gerouteerd naar de betreffende identiteitsaanbieder om het authenticatieproces te doorlopen. Na succesvolle authenticatie zal de authenticatiedienst de identiteitsinformatie over John aan het FIM-systeem terugkoppelen. Afhankelijk van de door John gekozen dienst zal het FIM-systeem in de verwijsindex de juiste gebruikers-id van John opzoeken en deze aan de dienstaanbieder doorgeven. De reden hiervoor is dat een dienstaanbieder bijvoorbeeld niets kan met de bank-id (1234) omdat John bij hem is geregistreerd onder een andere gebruikers-id (ABCD).

Binnen de in figuur 3 weergegeven architectuur zullen onder meer afspraken moeten worden gemaakt over de aan te sluiten diensten, de aan te sluiten authenticatiediensten, het beheer en de vulling van de verwijsindex (mapping van identiteiten), het beheer van het FIM-systeem, de betrouwbaarheidsniveaus van uitgegeven authenticatiemiddelen, de technische interfaces, aansprakelijkheid en de doorrekening van kosten (voor authenticaties en aanschaf en beheer van het FIM-systeem).

Voordelen van federated identity management

De mogelijke voordelen van de implementatie van een FIM-oplossing zijn divers. Hieronder zijn de voornaamste voordelen beschreven.

Verlaging van operationele kosten

FIM draagt eraan bij om een deel van de identity and access management-processen te stroomlijnen, te harmoniseren en te consolideren. Hierdoor hoeft het beheer van gebruikers en hun authenticatiemiddelen slechts eenmaal te worden belegd bij de verantwoordelijken en niet voor elke applicatie opnieuw te worden ingericht.

Daarnaast hoeft niet aan elke nieuwe gebruiker van een applicatie een nieuw en kostbaar authenticatiemiddel te worden verstrekt. Ten slotte zullen gebruikers, door de reductie van het aantal verschillende authenticatiemiddelen, minder snel hun authenticatiemiddel vergeten of kwijtraken, wat een significante verlaging in helpdeskkosten en overhead teweegbrengt.

Gebruikersvriendelijkheid

Een andere reden om een FIM-aanpak te hanteren is het bevorderen van het gebruikersgemak. Een gebruiker behoeft zich slechts eenmaal bij de door hem gewenste authenticatiedienst te registreren en kan zich vervolgens op basis van hetzelfde authenticatiemiddel bij diverse andere organisaties authenticeren. Hiermee wordt voorkomen dat de gebruiker wordt voorzien van een digitale sleutelbos. Daarnaast is binnen een FIM-omgeving het ‘single sign-on’-principe van toepassing. Dit houdt in dat de gebruiker zich maar eenmaal behoeft te authenticeren en, indien deze voldoende autorisaties bezit, vervolgens direct toegang heeft tot andere elektronische diensten.

Risicobeheersing

Naast de bovengenoemde redenen kan het verhogen van de betrouwbaarheid van een authenticatie eveneens een rol spelen. Doordat de gebruiker niet wordt voorzien van een diversiteit aan authenticatiemiddelen en zich meer bewust is van het feit dat het middel voor diverse toepassingen kan worden benut, zal hij geneigd zijn het authenticatiemiddel met de nodige voorzichtigheid behandelen. Daarnaast wordt de verantwoordelijkheid voor het beheer van gebruikers-id’s en authenticatiemiddelen belegd bij de juiste stakeholders. Door deze reductie in complexiteit zijn organisaties beter in staat de toegang van interne en externe gebruikers tot systemen effectief te beheersen. Hierdoor zal de toepassing van FIM bijdragen aan het kunnen voldoen aan wet- en regelgeving, zoals de Wet bescherming persoonsgegevens, het Voorschrift Informatiebeveiliging Rijksoverheid en corporate-governancerichtlijnen zoals Sarbanes-Oxley en Basel II.

Innovatie

Door het slim inrichten van FIM kunnen ten slotte nieuwe (organisatieoverschrijdende) toepassingen efficiënt en op een veilige wijze naar klanten, partners en leveranciers worden ontsloten, zonder dat hiervoor het gehele beheer van gebruikers en authenticatiemiddelen opnieuw behoeft te worden ingericht.

Federated identity management in de praktijk

De concepten achter FIM worden in de praktijk al geruime tijd toegepast. Tot een aantal jaren geleden was de aandacht er hierbij vooral op gericht de problematiek rondom het immer groeiende aantal gebruikers-id’s en authenticatiemiddelen intern op te lossen. Nu lijkt de aandacht ook te zijn verschoven naar domeinen buiten de eigen organisatie. Hieronder wordt kort ingegaan op de algemene houding van organisaties ten aanzien van FIM, enkele standaardisatie-initiatieven en worden enkele praktijkvoorbeelden gegeven.

Houding ten aanzien van FIM

In een eind 2003 door KPMG uitgevoerd onderzoek bleek de houding ten aanzien van FIM positief. Veel Nederlandse organisaties gaven aan het gebruikmaken van authenticatiemiddelen die worden uitgegeven en beheerd door derden als een serieuze optie te zien (zie figuur 4).

Figuur 4. Veel organisaties geven aan bereid te zijn authenticatiemiddelen van derden te gebruiken.

Daarnaast gaven veel organisaties aan dat zij hierbij de voorkeur geven aan authenticatiemiddelen die zijn uitgegeven door banken en overheidsinstellingen (zie figuur 5).

Figuur 5. Het gebruikmaken van authenticatiemiddelen van banken en overheidsinstellingen geniet de voorkeur.

Standaarden en specificaties

Op dit ogenblik loopt er een groot aantal verschillende initiatieven die de uitdagingen met betrekking tot FIM, zoals standaarden, oppakken. Met betrekking tot de standaarden zijn de volgende vier initiatieven het meest zichtbaar.

The Organization for the Advancement of Structured Information Standards (OASIS)

OASIS is een wereldwijde non-profitorganisatie die zich richt op standaardisatie van het XML-berichtenverkeer. OASIS heeft aan de basis gestaan van onder meer de volgende standaarden:

• Security Assertions Markup Language (SAML): een XML-formaat voor het uitwisselen van authenticatie- en autorisatiegegevens (bijvoorbeeld: ‘heeft Persoon X recht op toegang tot dienst Y?’). Deze standaard is de basis voor veel FIM-oplossingen.
• eXtensible Access Control Markup Language (XACML): een XML-formaat voor het definiëren van regels voor toegangscontrole. Om te bepalen of een gebruiker toegang krijgt tot een bepaald systeem, kunnen Policy Decision Points (PDP’s) binnen SAML autorisatie-informatie consulteren die is opgemaakt in XACML.
• Directory Services Markup Language (DSML): een XML-formaat voor het uitwisselen van directorygegevens over HTTP, in plaats van LDAP.
• Service Provisioning Markup Language (SPML): een XML-formaat voor het automatisch aanmaken, wijzigen en verwijderen van gebruikersaccounts.

The Liberty Alliance Project

The Liberty Alliance Project is een alliantie van meer dan 150 bedrijven (waaronder RSA, SUN en HP), diverse non-profitorganisaties en overheidsinstellingen. The Liberty Alliance heeft een standaard gedefinieerd voor organisatieoverschrijdend (federatief) identiteitsbeheer. De standaard is voornamelijk in gebruik ten bate van federatieve ‘single sign-on’-oplossingen voor toegang tot de diensten over meerdere organisaties heen. The Liberty Alliance maakt hiervoor onder meer gebruik van SAML.

Web Services Security (WSS)

WSS, een initiatief van Microsoft en IBM, definieert een familie van standaarden voor de beveiliging van XML-berichtenverkeer over het Simple Object Access Protocol (SOAP). De WSS-specificaties zijn ontwikkeld met als uitgangspunt dat deze interoperabel zijn met reeds bestaande beveiligingsmodellen zoals wachtwoorden, SAML en PKI.

Shibboleth

Shibboleth is een project van Internet2 en is gericht op de ontwikkeling van een gestandaardiseerde oplossing voor de uitwisseling van autorisatie-informatie. Een belangrijk doel binnen Shibboleth is het waarborgen van de privacy van gebruikers. Shibboleth is afkomstig uit de onderwijssector en is gebaseerd op SAML.

Convergentie van standaarden

Ofschoon deze organisaties in eerste instantie veelal afzonderlijk bezig waren met het ontwikkelen van eigen FIM-standaarden, lijken deze initiatieven zich nu toch meer en meer te richten op één gezamenlijke standaard welke onlangs is vastgesteld, namelijk SAML 2.0.

In de praktijk voldoen overigens lang niet alle FIM-producten volledig aan de genoemde standaarden. Bovendien zijn er in het algemeen uitbreidingen op de standaarden binnen diverse producten, hetgeen de uitwisselbaarheid van componenten beperkt. Niettemin is het gebruik van de standaarden om de hierboven genoemde redenen meestal toch een belangrijk onderdeel van een toekomstvaste en flexibele oplossing.

Praktijkvoorbeelden van FIM

In de praktijk zijn diverse voorbeelden van FIM-implementaties terug te vinden. Bekende en zichtbare implementaties zijn onder meer de Passportdienst van Microsoft en de initiatieven binnen de Nederlandse en Amerikaanse overheid.

Microsoft Passport

De .NET-passport-dienst van Microsoft stelt gebruikers in staat zich bij diverse online-diensten aan te melden door gebruik te maken van één gebruikersnaam (e-mailadres) en een wachtwoord. Indien gewenst kan de gebruiker zijn Passport-profiel vullen met persoonlijke kenmerken. Wanneer de gebruiker zich aanmeldt bij een op Passport aangesloten dienst met zijn e-mailadres en wachtwoord, deelt Passport het gebruikersprofiel met de betreffende online-dienst. Voorbeelden van door Passport ondersteunde diensten zijn Hotmail, MSN, Nasdaq, Starbucks en tot voor kort eBay.

Overheidsinitiatieven

Daarnaast zijn vooral in de overheidssector veel zichtbare FIM-initiatieven gaande. Dit zal niemand verbazen aangezien juist binnen de overheid een diversiteit aan autonome organisaties actief is, met ieder hun eigen diensten en alle dezelfde doelgroep (burgers en bedrijven). Door de authenticatiefunctionaliteit binnen de overheid centraal te beleggen, kunnen de kosten hiervan worden gedeeld en wordt de gebruiker op uniforme wijze bediend. Immers, de gebruiker kan met hetzelfde authenticatiemiddel (of een beperkt aantal authenticatiemiddelen) elektronische diensten afnemen bij diverse overheidsinstellingen.

Onder de noemer DigiD heeft de Nederlandse overheid een start gemaakt met een overheidsbrede FIM-implementatie. In kader 2 wordt nader op DigiD ingegaan. De Amerikaanse overheid heeft een soortgelijke FIM-oplossing geïmplementeerd. Deze oplossing, eAuthentication genoemd, wordt in kader 3 toegelicht.

Een FIM-implementatietraject

Stel, een organisatie onderkent de voordelen van een FIM-aanpak en besluit een FIM-oplossing te implementeren zodat zij zelf geen authenticatiemiddelen meer behoeft uit te geven aan gebruikers. Hoe dient een organisatie een dergelijk implementatietraject aan te pakken? Op basis van de ervaringen van organisaties die reeds een FIM-oplossing hebben geïmplementeerd, kan op hoofdlijnen de volgende beheersbare aanpak worden gehanteerd.

1. Bepalen van de te beveiligen diensten

De organisatie dient eerst de diensten die op basis van de FIM-oplossing moeten worden beveiligd, te bepalen en te beschrijven. Hierbij moeten de gebruikersgroepen en de kanalen waarover de dienst beschikbaar wordt gesteld, eveneens in beschouwing worden genomen. Een beschrijving van de diensten is nodig om in de volgende stap een gedegen risicoanalyse te kunnen uitvoeren.

2. Definiëren vereiste betrouwbaarheidsniveau

Nadat de diensten zijn onderkend, dient de organisatie een risicoanalyse uit te voeren teneinde de risico’s en de gewenste maatregelen in kaart te brengen. Op basis van de resultaten definieert de organisatie het gewenste betrouwbaarheidsniveau met betrekking tot authenticatie. Het gedefinieerde betrouwbaarheidsniveau kan eisen stellen aan het type, de gebruikersvriendelijkheid en het productie- en uitgifteproces van het authenticatiemiddel, alsmede het registratieproces van de gebruiker. Organisaties kunnen hierbij rekening houden met compenserende maatregelen, zodat niet altijd voor het hoogste betrouwbaarheidsniveau, en daarmee het vaak meest kostbare authenticatiemiddel, hoeft te worden gekozen. Een voorbeeld van een compenserende maatregel kan zijn een papieren terugkoppeling naar het huisadres van de gebruiker nadat deze een elektronische transactie heeft verricht of het wachten op de betaling voordat de dienst wordt geleverd. Ter ondersteuning van het uitvoeren van een dergelijke risicoanalyse heeft DigiD overigens een authenticatiewijzer beschikbaar gesteld op haar website. Zie hiervoor [digi].

3. Selecteren geschikte authenticatiedienst

Op basis van het gewenste betrouwbaarheidsniveau en overige eisen (bijvoorbeeld kosten en te hanteren standaarden) zoekt de organisatie naar geschikte authenticatiediensten. Hierbij wordt aanbevolen gebruik te maken van authenticatiediensten die zich in de praktijk hebben bewezen. Voorbeelden van dergelijke diensten zijn DigiD, maar ook SURFnet voor de hogescholen dat gebruikmaakt van bancaire middelen en GSM. Ter ondersteuning van de selectie van een geschikte authenticatiedienst is vanuit ECP.NL onder de noemer ‘e-OK’ een initiatief gaande om verschillende authenticatiediensten te classificeren. Meer informatie over dit raamwerk vindt u op [ecp].

4. Afsluiten contracten

Met de leverancier van de authenticatiedienst dienen afspraken te worden gemaakt. Een belangrijk aandachtspunt hierbij is de aansprakelijkheid. Wie is bijvoorbeeld aansprakelijk voor schade die voortvloeit uit het verkeerd authenticeren van een identiteit? Deze afspraken dienen te worden vastgelegd in contracten en service level agreements (SLA’s). Daarnaast dienen afspraken te worden gemaakt over de te gebruiken technische interfaces en standaarden.

5. Integreren authenticatiedienst

Nu de organisatorische en juridische aspecten zijn geregeld, dient de organisatie haar diensten technisch aan te sluiten op de authenticatiedienst.

Conclusie

Gezien de enorme toename in elektronische diensten en de daarmee gepaard gaande toename in gebruikers-id’s en authenticatiemiddelen, is FIM een logische reactie op een trend. FIM biedt organisaties in potentie substantiële kostenvoordelen en biedt gebruikers het aantrekkelijke vooruitzicht om niet al die wachtwoorden te hoeven onthouden. Hoewel FIM in de praktijk steeds vaker succesvol wordt toegepast, is nog niet geheel duidelijk in welke richting FIM zich zal gaan bewegen. Dit komt enerzijds doordat veel partijen simpelweg nog niet klaar zijn voor een implementatie over de organisatiegrenzen heen omdat zij eerst de eigen processen op orde zullen moeten hebben, en anderzijds doordat veel producten nog niet aan uitgekristalliseerde standaarden voldoen.

Om te voorkomen dat FIM nu onterecht naar het rijk der fabelen wordt verwezen of juist als de heilige graal wordt gezien binnen identity management, willen de auteurs de lezer graag de volgende slotoverwegingen meegeven:

• Utopische dromen over ‘één authenticatiemiddel voor alles’ zullen moeten plaatsmaken voor meer pragmatische benaderingen om het aantal authenticatiemiddelen te reduceren.
• Elektronische sleutelbossen zijn onvermijdelijk, maar kunnen substantieel worden verkleind door het toepassen van FIM.
• De acceptatiegraad bij eindgebruikers voor de uitgifte van nieuwe, geïsoleerde authenticatiemiddelen neemt steeds verder af.
• Standaarden met betrekking tot FIM beginnen nu te convergeren en zouden nu al moeten worden ingebed binnen beveiligingsarchitecturen.
• FIM gaat niet alleen over het realiseren van technische interoperabiliteit. Het gaat ook over het opbouwen van vertrouwensrelaties tussen partijen, het aangaan van juridische contracten, het omarmen van gezamenlijke beleidsuitgangspunten, authenticatiemiddelen en verklaringen.
• FIM maakt de bescherming van de privacy van de gebruikers tot een noodzaak.
• Ten slotte zegt de Burton Group nog het volgende over FIM: ‘Issues will remain, but necessity is the mother of invention’ ([BGFe]). Hierbij sluiten de auteurs zich graag aan.