Federated identity maakt groteorganisaties beheersbaar
Alle grote softwareleveranciers investeren bovendien in het aankopen, ontwikkelen en marketen van producten met federated-identityfunctionaliteit. Al met al lijkt de belangstelling voor federated identity een hype-achtig karakter te hebben.
Toch zien we dat deze vorm van identificatie en authenticatie maar moeilijk van de grond komt; het aantal implementaties is nog schaars en beperkt zich vooralsnog tot enkele branches. De voorbeelden die er zijn, zijn echter aansprekend en laten zien dat het werkt (zie het initiatief van de Amerikaanse overheid: www.cio.gov/eAuthentication). De vraag rijst dan hoe het komt dat federated identity niet op grotere schaal wordt toegepast.
De belangrijkste reden ligt voor de hand. Voor veel organisaties is het simpelweg niet relevant. Het is pas aantrekkelijk wanneer er sprake is van (relatief) grote aantallen externe gebruikers en samenwerkingsverbanden tussen partnerorganisaties. Ook is deze vorm van identiteitsbeheer geschikt voor organisaties met min of meer zelfstandige divisies of businessunits (de overheid, het hoger onderwijs, telecom- en nutsbedrijven). Er is dan een mechanisme nodig om op gecontroleerde en efficiënte, dus kostenbesparende wijze de authenticatie- en identiteitsgegevens van de relaties te beheren.
Maar ook indien wel aan bovengenoemde voorwaarden is voldaan, vragen veel organisaties zich af of de investering de moeite loont. In veel gevallen lijkt het goedkoper om via ‘ouderwetse’ web-access-managementtechnieken accountinformatie voor relaties te beheren dan te investeren in federated-identitytechnieken. Want in het laatste geval moet niet alleen geïnvesteerd worden in de technologie, maar ook in kennis. Op de langere termijn zal federated identity echter een winnaar blijken; we groeien steeds meer toe naar een wereld waarin alles door middel van XML en webservices aan elkaar wordt geknoopt, de natuurlijke transportlaag voor federated identity. Bij het opstellen van de businesscase moeten deze strategische overwegingen worden meegenomen.
Hiermee arriveren we bij SOA. In SOA-omgevingen worden bedrijfsprocessen gerepresenteerd als modulaire, herkenbare services en vertaald naar duidelijk definieerbare applicatieservices die op hun beurt door middel van open standaarden zoals webservices worden geïntegreerd. Een op deze wijze ingerichte applicatie-infrastructuur is sneller aan te passen aan veranderingen in de bedrijfsprocessen en is gemakkelijker te benaderen door businesspartners.
SOA hangt nauw samen met de-perimeterization, een concept waarbij de beveiliging van de periferie van de IT-infrastructuur, zoals firewalls, naar de applicaties en de gegevens zelf wordt verschoven, zodat de IT-infrastructuur meer opengesteld kan worden voor businesspartners en klanten, een idee dat onder meer wordt gepromoot door het Jericho Forum (www.opengroup.org/projects/jericho).
Federated identity vormt in dergelijke omgevingen een noodzakelijk hulpmiddel om het transporteren van authenticatie- en identiteitsgegevens mogelijk te maken.
Geen vertrouwen
Gebrek aan vertrouwen blijkt een volgend obstakel voor federated identity. Dit vertrouwen wordt in de eerste plaats beschaamd doordat het internet in steeds omvangrijkere mate het toneel is van kwaadwillende en criminele activiteiten die bovendien in ernst en geavanceerdheid toenemen. Waren het voorheen veelal hobbyistische hacks die de boventoon voerden, tegenwoordig zijn georganiseerde fraude en identiteitsdiefstal veel voorkomende zaken. Omdat federated identity zich niet alleen binnen maar vooral ook buiten de grenzen van de organisatie afspeelt, zijn de zorgen over de integriteit van de gegevens hier terecht. Temeer daar het om bijzonder privacy- en fraudegevoelige gegevens kan gaan, zoals naam, e-mailadres, BSN (burgerservicenummer) en creditcardnummer. Sterke authenticatie en versleuteling vormen hierop het noodzakelijke antwoord.
Om dezelfde reden heeft men in federated-identity-omgevingen bijna altijd te maken met wet- en regelgeving. Afhankelijk van de aard van de gegevens kan bijvoorbeeld financiële wet- en regelgeving relevant zijn, maar vrijwel zeker speelt privacy-wetgeving een rol. Vooral wanneer de federated-identity-omgeving landsgrenzen overschrijdt, vormt wetgeving een extra complicerende factor. Privacywetgeving, bijvoorbeeld, kan aanzienlijk verschillen van land tot land. Aandachtige bestudering en vergelijking van de wetgeving is in dat geval geboden.
Maar het zijn niet alleen externe factoren die de oorzaak zijn van dit gebrek aan vertrouwen. Ook tussen de partners onderling in de toekomstige federatie kan wantrouwen bestaan. Daarom zijn duidelijke afspraken nodig tussen de partnerorganisaties en hun relaties die de federatie willen opzetten, over hoe om te gaan met vertrouwelijke en privacygevoelige gegevens, hoe identiteiten kunnen worden geverifieerd en wie aansprakelijk is voor het geval er iets misgaat. Vanwege dit laatste facet is het van belang een goede audit- en rapportagefunctionaliteit te implementeren in de federated-identity-omgeving.
In genoemde omgevingen is het bovendien zeer belangrijk dat authenticatiegegevens meteen onklaar worden gemaakt of verwijderd, zodra de relatie met een businesspartner wordt verbroken. Om het toekennen en intrekken van authenticatiegegevens te vergemakkelijken is het daarom een goed idee om een provisioningmechanisme toe te passen, waarmee op centrale en geautomatiseerde wijze accountgegevens kunnen worden beheerd.
Ten slotte moet het gebrek aan standaardisatie genoemd worden als oorzaak van de vertraging in het aantal federated-identity-implementaties. Want ondanks het streven van organisaties als de Liberty Alliance en Oasis (zie kader), is het nog niet gelukt om een eenduidige specificatie voor federated identity op papier te zetten, die voor alle marktpartijen acceptabel is.
De twee belangrijkste specificaties op het gebied van federated identity, SAML en WS-Federation (zie kader), zijn niet volledig uitwisselbaar. Dit betekent dat partnerorganisaties die deze verschillende standaarden gebruiken, alleen een federatie kunnen aangaan met behulp van een overkoepelende productsuite of gateway-technologie.
Standaards
Een federated-identityproject kent – buiten de activiteiten die gebruikelijk zijn in ieder beveiligingsgerelateerd project, zoals het maken van een risicoanalyse – een aantal stappen die bijzondere aandacht behoeven.
Hierboven is al uiteengezet dat het maken van duidelijke afspraken tussen de partners in de federatie belangrijk is. Naast aspecten als vertrouwelijkheid en integriteit zijn afspraken nodig over welke standaards worden gebruikt voor het uitwisselen van authenticatiegegevens, wanneer deze worden toegekend en ingetrokken, hoe wordt omgegaan met afwijkingen en uiteraard over hoe de kosten worden verdeeld. Dit alles moet worden vastgelegd in een contract.
Uit het voorgaande is gebleken dat het kiezen van een standaard met veel aandacht moet gebeuren; dit zal meestal samengaan met het selecteren van een product. Criteria die hierbij moeten worden meegewogen, zijn functionaliteit, beveiliging, toekomstvastheid, interoperabiliteit en de beschikbaarheid van kennis en expertise. Indien er al een productsuite voor identiteitsbeheer in gebruik is binnen de organisatie, moet geëvalueerd worden of deze uitgebreid moet worden met de gewenste functionaliteit of dat geïnvesteerd moet worden in een nieuw product. Belangrijke leveranciers van federated-identitytechnologie zijn op dit moment (in willekeurige volgorde) IBM, Novell, RSA, Oracle, Sun, Microsoft, CA en Ping Identity. Een voorbeeld van een Nederlands product met federated-identityfunctionaliteit is het robuuste A-Select waarop onder meer DigiD is gebaseerd.
Om expertise op te doen, is het raadzaam om met een intern project te beginnen. Op deze wijze doet de organisatie relatief snel ervaring op zonder meteen gehinderd te worden door het moeizame proces van het maken van afspraken met partnerorganisaties.
Dr. R.J. van der Staaij (rob.vander.staaij@capgemini.com) is werkzaam bij Capgemini.