Vertrouwen in de SURFfederatie: schaalt dat?

Vertrouwen in de SURFfederatie: schaalt dat? Project Projectjaar Projectmanager Auteur(s) Opleverdatum Versie

: SURFworks : 2009 : Remco Poortinga-van Wijnen : Bob Hulsebosch, Maarten Wegdam, Robert de Groote : Augustus 2009 : 1.0

Samenvatting De SURFfederatie is een belangrijke dienst voor het delen van identiteitsinformatie tussen universiteiten en service providers. De voordelen zijn navenant en steeds meer partijen willen zich aansluiten bij de federatie. Dat vertrouwen een belangrijke rol speelt in elke federatie is evident. Echter, de complexiteit van het creëren en borgen van vertrouwen tussen alle partijen in de SURFfederatie kan een obstakel voor een (inter)nationale groei van deze dienst zijn. Dit rapport onderzoekt op welke manieren vertrouwen gecreëerd en gemanaged kan worden en hoe vertrouwen schaalbaar gemaakt kan worden om de verdere groei van de SURFfederatie te stimuleren.

Voor deze publicatie geldt de Creative Commons Licentie “AttributionNoncommercial-Share Alike 3.0 Netherlands”. Meer informatie over deze licentie is te vinden op http://creativecommons.org/licenses/by-nc-sa/3.0/nl/

Colofon Programmalijn: Onderdeel: Activiteit: Deliverable: Toegangsrechten: Externe partij:

SURFworks SURFfederatie PoCs Vertrouwen op grote(re) schaal Rapport “Onderzoek naar methoden voor vertrouwen op grote(re) schaal” Publiek Novay, www.novay.nl

Dit project is tot stand gekomen met steun van SURF, de organisatie die ICT vernieuwingen in het hoger onderwijs en onderzoek initieert, regisseert en stimuleert door onder meer het financieren van projecten. Meer informatie over SURF is te vinden op de website (www.surf.nl).

6 dingen die je moet weten over “Vertrouwen in de SURFfederatie: Schaalt dat?”

Context

De huidige SURFfederatie is overzichtelijk en bestaat uit een beperkt aantal aansluitingen (van IdPs en SPs) in een homogene samenstelling, wat ervoor zorgt dat het vertrouwen dat de deelnemers er in hebben relatief gemakkelijk is te bewerkstelligen. Wanneer de SURFfederatie (veel) groter gaat worden dan nu het geval is, wat zijn dan de gevolgen voor vertrouwen en wat zijn de mogelijkheden om er voor te zorgen dat het vertrouwen behouden blijft?

Wat is het?

Een beschrijving van wat vertrouwen nu eigenlijk is, hoe het gemanaged kan worden en wat de verschillende vertrouwensmodellen zijn binnen (andere) federaties. Wat zijn organisatorische en technische oplossingsrichtingen die kunnen helpen bij het behouden van vertrouwen in/binnen de SURFfederatie wanneer deze in de toekomst wordt opgeschaald.

Voor wie is het?

Voor betrokkenen bij identiteits federaties (zoals de SURFfederatie) die meer willen weten over de vertrouwensaspecten die een rol spelen bij federaties, waarom dit zo belangrijk is en hoe dit ook in de toekomst behouden kan blijven.

Hoe werkt het?

Er is niet één universeel geldige oplossing voor het behouden van vertrouwen bij het groeien van een federatie; voor de specifieke situatie van de SURFfederatie worden aanbevelingen gedaan voor de mogelijke oplossingsrichtingen (zowel technisch als organisatorisch).

Wat kan je ermee?

Extra (Bijlagen, Thema, Gerelateerde thema’s)

Schaalt dat?

Inzicht krijgen in vertrouwen en hoe dit beinvloed wordt door de verschillende organisatorische en technische kenmerken van federaties in het algemeen en de SURFnet federatie in het bijzonder. Geen.

III

Management samenvatting Het creëren van vertrouwen tussen partijen in een federatie is geen sinecure. Vele verschillende elementen dragen bij tot het ontstaan van vertrouwen: beveiliging, betrouwbaarheid, beschikbaarheid, begrijpelijkheid, privacy, wetgeving, etc. Vaak is het opbouwen van vertrouwen een langdurig proces dat bij een enkel incident weer teniet gedaan kan worden. Het is duidelijk dat in een federatie waarin steeds meer partijen participeren, en vooral Service Providers (SPs), er de nodige druk komt te liggen op het creëren en in stand houden van alle vertrouwensrelaties tussen SPs en Identity Providers (IdPs). De centrale vraag van dit onderzoek is: hoe kan binnen de SURFfederatie vertrouwen tussen SPs en IdPs schaalbaar gemaakt worden? Oplossingsrichtingen hiervoor hebben een organisatorisch en technisch karakter. Hierbij dient opgemerkt te worden dat beide typen oplossingsrichtingen niet alleen sterk afhangen van de gekozen (con)federatie strategie, maar ook afhankelijk van elkaar zijn. Een organisatorische oplossingsrichting heeft vaak een technische component. Strategisch heeft de SURFfederatie al een slimme zet gedaan door te kiezen voor een hub & spoke model. De centrale hub in de SURFfederatie schaalt vanuit vertrouwensperspectief stukken beter dan bijvoorbeeld een bilateraal model. Het vertrouwen tussen SPs en IdPs wordt immers vergemakkelijkt als ze vertrouwen hebben in de hub (SURFnet) en de manier waarop deze zorg draagt voor de kwaliteit van het identity management van de verschillende IdPs en de zorgvuldige omgang met deze gegevens door de SPs. Dit komt de schaalbaarheid ten goede. De hub biedt daarnaast een uitstekende mogelijkheid om het organisatorisch vertrouwen verder uit te bouwen. Centraal hierin staat informatievoorziening over de federatie en het gebruik hiervan aan de aangesloten IdPs en SPs. Vertrouwen is immers voor een belangrijk deel gebaseerd op informatie. Diensten die voorzien in informatie over bijvoorbeeld transactiegegevens en privacy policies zijn wenselijk en kunnen via de hub aangeboden worden aan de IdPs en SPs in de federatie. Ook kan aan IdPs en SPs de mogelijkheid geboden worden om controle te krijgen over met wie ze zaken doen in de federatie en welke informatie ze verstrekken (zelfmanagement) zonder dat dit investeringen in software vereist van deze partijen. Door deze transparantie en controle ontstaat vertrouwen en zullen nieuwe partijen sneller geneigd zijn om toe te treden. Een bijkomend voordeel van een toenemend zelfmanagement is dat de verantwoordelijkheid voor de controle meer bij de aangesloten partijen ligt dan bij SURFnet, waardoor SURFnet minder aansprakelijk wordt.

IV

Vertrouwen in de SURFfederatie

Hoewel de focus van dit onderzoek ligt bij het creëren van vertrouwen tussen IdPs en SPs in een federatie of confederatie is de rol van de eindgebruikers ook belangrijk. Als deze geen vertrouwen hebben in de federatie, hoe goed die ook mag schalen voor IdPs en SPs, dan zal er van verdere opschaling weinig komen. Naast het gemak dat ze ervoor terug krijgen is het voor gebruikers belangrijk dat ze begrijpen wat er gebeurt en dat hun privacy gegarandeerd is. Dit kan gedaan worden door de gebruiker ‘user controlled privacy’ features aan te bieden zoals dit typisch gebeurt bij user-centric identiteitsmanagementoplossingen zoals InfoCards en OpenID 1. De verantwoordelijkheid verschuift dan naar de eindgebruiker, waardoor er tussen de IdPs en de SPs minder vertrouwen ‘geregeld’ hoeft te worden; wat de schaalbaarheid weer ten goede komt. Een andere organisatorische insteek voor het opschalen van vertrouwen is om niet één hele grote federatie na te streven maar te confederen met andere federaties. Bij het confedereren is het belangrijk dat partijen uit verschillende federaties te weten komen dat ze in dezelfde confederatie zitten en dus elkaar kunnen vertrouwen. In een confederatie spelen transparantie en informatie dus ook een belangrijke rol. Cruciaal hierbij is de confederatie metadata. In deze metadata staan de gegevens van alle aangesloten federaties. Twee aspecten zijn relevant betreffende de metadata: de vindbaarheid en de betrouwbaarheid. De vindbaarheid van de metadata in confederatieverband is gerelateerd aan het centraal of decentraal aanbieden ervan. Een centrale oplossing lijkt de meest eenvoudige maar vaak ontbreekt een partij die dit wil doen. Verder is een centrale metadatafile een aantrekkelijk doelwit voor aanvallen en een potentiële performance bottleneck. Een decentrale oplossing gaat er vanuit de elke partij zijn eigen metadata managed. Dit is minder eenvoudig, vooral vanuit vertrouwensperspectief. Het borgen van de betrouwbaarheid van de metadata is een technisch vraagstuk. Technische oplossingsrichtingen voor het borgen van vertrouwen bestaan uit het beveiligen van de communicatiekanalen tussen de IdPs en SPs en de metadata. Het simpel uitrollen van een PKI is hier geen oplossing; de praktijk heeft immers uitgewezen dat een PKI slecht schaalt (vooral over domeinen heen) en erg kostbaar kan zijn. Het gebruik van self-signed certificaten is hierdoor erg aanlokkelijk maar deze genieten weer een erg lage vertrouwenswaarde. Een benadering die hier gekozen kan worden is deze certificaten onderdeel te maken van de (con)federatiemetadata en deze te laten ondertekenen door de (con)federatie operator. Partijen in de federatie hoeven dan ook niet meer een lijst met certificaten van partners in de federatie bij te houden, de zogenaamde trust anchor list. Een trust anchor list bijhouden is lastig wanneer er steeds nieuwe partijen bijkomen in de federatie en wanneer een certificaat vernieuwd of ingetrokken moet worden. Het opnemen van certificaten in de metadatafile werkt goed als er sprake is van een centrale metadatafile, maar in het geval van gedistribueerde metadata schaalt dit minder goed omdat de (con)federatie operator dan alle metadata files moet ondertekenen. In dat geval kan gedacht worden aan het taggen van metadata door een betrouwbare derde partij, bijvoorbeeld de (con)federatie operator. Door hem ondertekende tags kunnen dan in de metadata opgenomen worden. Een alternatieve manier voor het aanbieden van metadata op een betrouwbare manier zou via DNS en DNSSEC kunnen zijn. Deze aanpak wordt verder in detail uitgewerkt in een volgend document van dit project.

1

Dit is het onderwerp van het gerelateerde SURFfederatie PoCs, User Controlled Privacy project.

Schaalt dat?

V

Samenvattend, stellen we de volgende technische en organisatorische oplossingsrichtingen voor die ervoor zorgen dat vertrouwen in de SURFfederatie op een schaalbare manier geborgd kan worden: ◊

Zelfmanagement door IdPs en SPs. Bied via de hub identiteitsdiensten aan waarmee IdPs en SPs zelfmanagement kunnen doen.

◊

Afstemmen van privacy policies. Hierdoor wordt duidelijkheid gecreëerd betreffende het uitwisselen van identiteitsinformatie tussen partijen in een federatie of over federaties heen.

◊

De contractuele kant verder professionaliseren. Contractuele relaties zijn een grote drempel in het schaalbaar maken van de federatie. Vele factoren waarover overeenstemming bereikt moet worden spelen hierbij een rol en dienen professioneel aangepakt te worden om groei te accomoderen.

◊

Heldere aansluitvoorwaarden. Geef helderheid voor wat betreft de aansluitvoorwaarden tot de SURFfederatie. Waaraan moet een IdP of SP voldoen voordat hij toe mag treden tot de federatie. Heldere afspraken geven duidelijkheid en daarmee vertrouwen.

◊

User-centric identity. Geef de eindgebruiker meer verantwoordelijkheden: introduceer user-centric identiteitsmanagement. De noodzaak tot federeren neemt hiermee af en dus ook het regelen van het vertrouwen.

◊

Efficiënt metadata management. De hub gaat metadata aggregeren en dynamisch communiceren naar de SPs. Door incorporeren van certificaten en tags in de metadata kunnen alle partijen veilig met elkaar communiceren. Trusted directory services zoals DNSSEC kunnen gebruikt worden voor het veilig distribueren van de metadata.

◊

Meer aandacht voor confederatie. Het federeren van federaties tot een confederatie is een aantrekkelijke manier om op te schalen.

Het centrale hub model van de SURFfederatie biedt mogelijkheden voor een efficiënte opschaling van de federatie en zelfs tot confederatie. In de automotive sector toont Covisint aan dat op deze manier een grote succesvolle federatie kan ontstaan. Toch zien we dat op dit moment in het hoger onderwijs de meeste federatieve koppelingen op bilaterale wijze tot stand komen, waarbij er minder mogelijkheden zijn tot het ondersteunen van schaalbaar vertrouwen. De achterliggende vraag is tot hoe ver een identiteitsfederatie in het hoger onderwijs moet schalen: verwachten we dat enkele tientallen of enkele duizenden SPs een federatieve koppeling met een IdP gaan hebben? Momenteel zijn het vooral kleinschalige federaties waarbij het nog redelijk overzichtelijk is om vertrouwen te managen. Bij veel grootschaligere implementaties belanden we vermoedelijk in een andere wereld waar usercentric identity een grotere rol zal hebben, zodat er minder vertrouwen nodig is tussen SP en IdP. Onafhankelijk van organisatorische en technische maatregelen om de schaalbaarheid te verhogen, zal de uitspraak van Lao Tse blijven gelden: “Wie geen vertrouwen stelt in anderen zal ook nimmer het vertrouwen van anderen winnen”.

VI


Inhoudsopgave 1 Inleiding

1

1.1

Glazen plafond

1

1.2

Doelstelling en aanpak

1

2 Vertrouwen

2

2.1

Wat is vertrouwen?

2

2.2

Het managen van vertrouwen

3

2.3

Vertrouwensmodellen voor identiteitsfederaties

5

2.4

Vertrouwen in bestaande identiteitsfederaties

6

2.4.1 SURFfederatie

7

2.4.2 FEIDE

7

2.4.2.1

Kalmar confederatie

8

2.4.3 InCommon/Shibboleth

10

2.4.4 Covisint

11

2.4.5 STORK

13

2.4.6 GRID

14

2.4.7 eduGAIN

15

2.5

Conclusies

3 Organisatorische oplossingsrichtingen 3.1

Informatie

3.1.1 Evaluatie

3.2

Transparantie en controle

3.2.1 User-centric identiteitsmanagement 3.2.1.1

Relatiemanagement

3.2.2 Evaluatie

3.3

Confederaties

3.3.1 Evaluatie

3.4

Reputatiemanagement

3.4.1 Evaluatie

3.5

18

21 21 21

21 22 23 24

24 26

26 27

Identiteitszekerheid

28

3.5.1 Levels of Assurance

28

3.5.1.1

Schaalt dat?

Liberty Alliance Identity Assurance

28

VII

3.5.1.2

NIST

29

3.5.1.3

LoA in identiteitsfederaties

29

3.5.2 MyID.is Certified

30

3.5.3 Evaluatie

30

3.6

Outsourcing

30

3.6.1 Evaluatie

31

3.7

Governance

31

3.7.1 Liberty Alliance IGF

31

3.7.2 Evaluatie

33

3.8

Samenvatting

4 Technische oplossingsrichtingen 4.1

33

34

Metadata uitwisseling

34

4.1.1 Centraal/decentraal

35

4.1.2 Out of band/in band

37

4.1.2.1

Dynamic SAML / Auto-Connect

37

4.1.3 Metadata tagging

40

4.1.4 Licenties op metadata

40

4.1.5 Automatische metadata down- en upload in MDS

40

4.1.6 Evaluatie

41

4.2

Trusted directory services

4.2.1 Evaluatie

4.3

PKI

42 42

43

4.3.1 EV Certificaten

44

4.3.2 Evaluatie

45

4.4

Samenvatting

45

5 Conclusies

46

6 Aanbevelingen voor de SURFfederatie

47

6.1

VIII

Aanbevelingen

48


1 Inleiding De SURFfederatie stelt studenten en werknemers in het hoger onderwijs in staat om op een betrekkelijk eenvoudige en gebruikersvriendelijke manier toegang te krijgen tot online diensten. Door gebruik te maken van een federatieve identiteitsmanagementinfrastructuur hoeft een gebruiker zich slechts één keer te authenticeren om vervolgens toegang te krijgen tot meerdere diensten. De identiteitsmanagementinfrastructuur zorgt ervoor dat identiteitsgegevens op de juiste manier tussen de betrokken partijen worden gecommuniceerd. In de SURFfederatie zijn dit typisch de identiteitsproviders (IdPs) van de gebruikers, de service providers (SPs), eventuele attribuut providers (APs) en de centrale hub bij SURFnet.

1.1

Glazen plafond

Een federatieve identiteitsmanagementinfrastructuur biedt tal van voordelen voor de betrokken partijen. Eindgebruikers krijgen op een vriendelijke en efficiënte manier toegang tot tal van diensten en data zonder daarvoor steeds opnieuw in te hoeven loggen. Verder worden persoonlijke gegevens met zorg gecommuniceerd zodat privacy tot op zekere hoogte gewaarborgd is. De SPs hoeven zelf geen authenticatievoorzieningen meer te treffen omdat de IdPs de eindgebruikers authenticeren. Succes lijkt gegarandeerd. Echter, een belangrijke voorwaarde voor een federatieve identiteitsmanagementinfrastructuur is dat er een bepaalde vertrouwensrelatie bestaat tussen de betrokken partijen. Het moge duidelijk zijn dat in een federatie waarin steeds meer partijen gaan participeren, en vooral SPs, er de nodige druk komt te liggen op het creëren en in stand houden van alle vertrouwensrelaties. De vraag is dus of en hoe vertrouwen schaalt in een groeiende identiteitsfederatie als de SURFfederatie. Met andere woorden, is er sprake van een glazen plafond 2 voor federatief identiteitsmanagement, en indien zo, wat zijn oplossingsrichtingen om de schaalbaarheid te verbeteren.

1.2

Doelstelling en aanpak

Het voorliggende document probeert een antwoord te geven op deze vragen. In hoofstuk 2 gaan we dieper in op het begrip vertrouwen, en behandelen we hoe vertrouwen geregeld is in verschillende bestaande identiteitsfederaties. Hierna wordt in de hoofdstukken 3 en 4 een inventarisatie gemaakt van mogelijke organisatorische en technische oplossingen voor het schaalbaar maken van vertrouwen. Vervolgens zal in hoofdstuk 5 gekeken worden in hoeverre deze oplossingen toepasbaar zijn voor het oplossen van de vertrouwenskwesties in de SURFfederatie. Enkele aanbevelingen voor het opschalen van vertrouwen zullen geponeerd worden. Hoofdstuk 6 sluit af met een concluderende samenvatting van onze bevindingen.

2

Burton Group gebruikt deze term om schaalbaarheidsproblemen voor identity federatie aan te duiden, e.g., Glass Ceiling for Federation Technologies, podcast, http://podcast.burtongroup.com/ip//federation/ (2007).

Schaalt dat?

1

2 Vertrouwen In dit hoofdstuk gaan we dieper in op het begrip vertrouwen en hoe je het kan managen, leggen we uit welke modellen er zijn om vertrouwen te creëren in de digitale wereld, en kijken we hoe vertrouwen momenteel geregeld is in enkele bestaande identiteitsfederaties.

2.1

Wat is vertrouwen?

Het begrip vertrouwen is niet zo eenvoudig te definiëren. Vertrouwen is een abstract begrip dat vele aspecten, zoals persoonlijke, sociale, economische en zelfs filosofische, kent. Vertrouwen heeft een aantal eigenschappen: ◊

Het hangt af van de situatie: een chirurg is wel te vertrouwen in het goed uitvoeren van een hartoperatie maar minder in het aanleggen van een verwarmingsinstallatie.

◊

Het is directioneel - heeft een richting: de chirurg kan de loodgieter vertrouwen maar dit hoeft omgekeerd niet het geval te zijn.

◊

Is meetbaar: iemand 100% vertrouwen of maar een beetje.

◊

Het verandert in de tijd: vertrouwen neemt toe of af in de loop der tijd, met name afhankelijk van ervaringen in het verleden. Het opbouwen van vertrouwen kost vaak veel tijd en inspanning terwijl het verliezen ervan zo gebeurd is.

◊

Het kan overdraagbaar zijn: Het lenen van de auto van de broer van je vriendin is vaak geen probleem (delegatie van vertrouwen).

Naast bovenstaande meer generieke eigenschappen, zijn er verschillende andere factoren die meer specifiek het vertrouwen in een ICT-dienst op een of andere manier beïnvloeden:

2

◊

Beveiliging: een goed beveiligde ICT-dienst geeft de gebruikers ervan vertrouwen.

◊

Betrouwbaarheid: een betrouwbare ICT-dienst geeft de gebruikers ervan vertrouwen.

◊

Beschikbaarheid: een ICT-dienst die regelmatig niet beschikbaar is geniet weinig vertrouwen bij de gebruikers ervan.

◊

Veiligheid: het veilig kunnen gebruiken van een systeem zal gebruikers gerust stellen.

◊

Tijdigheid: een ICT-dienst die niet tijdig antwoord of resultaten geeft is onbetrouwbaar.

◊

Onderhoudbaarheid: een lastig te onderhouden systeem zal minder vertrouwen genieten dan een eenvoudig te onderhouden systeem.

◊

Traceerbaarheid: het kunnen zien wie wat wanneer gedaan heeft in een systeem biedt bepaalde garanties.

◊

Inschatbaarheid: het kunnen inschatten van bijvoorbeeld risico’s door de gebruiker tijdens het gebruik van een systeem werkt drempelverlagend.

◊

Gebruikersvriendelijkheid: als een gebruiker niet begrijpt wat hij aan het doen is daalt zijn vertrouwen in het systeem.

◊

Privacy: als de gebruiker anoniem kan blijven zal hij meer vertrouwen hebben in het systeem.


◊

Wetgeving: de aanwezigheid van een juridisch kader voor de gebruiker om op terug te vallen ten tijde van een calamiteit geeft vertrouwen.

Deze elementen dragen allen bij tot het creëren van vertrouwen, of, beter gezegd, dragen bij tot het komen van een afweging om wel of niet gebruik te gaan maken van diensten. Ze zullen daarom in ogenschouw genomen dienen te worden bij het inrichten van een identiteitsfederatie.

2.2

Het managen van vertrouwen

Zoals we gezien hebben is vertrouwen een proces en processen dienen gemanaged te worden. Vertrouwen zal opgebouwd, onderhouden en geëvalueerd moeten worden – ook in een federatie. Dit zal zowel vanuit technisch als organisatorisch perspectief gedaan moeten worden. Vertrouwensmanagement gaat in op de relaties die bestaan tussen de partijen. In een identiteitsfederatie is het opbouwen van een vertrouwensrelatie in eerste instantie een organisatorisch probleem dat in tweede instantie met technische middelen onderbouwd kan worden. De organisatorische kant betreft het maken van afspraken over hoe partijen met elkaar zaken doen. Deze afspraken bevatten elementen over relatiemanagement, aansprakelijkheid en wetgeving en worden typisch vastgelegd in een contract. Het aangaan van een zakelijke overeenkomst wordt naast de bovengenoemde overwegingen als beschikbaarheid en eerdere ervaringen ook vaak gebaseerd op een risicoafweging. In een identiteitsfederatie hangt deze laatste afweging af van de gevoeligheid van de dienst voor identiteitsfraude en van de persoonlijke informatie die nodig is om toegang te krijgen tot de dienst. Specifieke diensten vereisen vaak specifieke informatie over de eindgebruiker. Afspraken over toegangsrechten tot diensten en (persoonlijke) informatie zijn dus onderdeel van een zakelijke overeenkomst en zijn vaak geënt op juridische procedures (zoals de Wet Bescherming Persoonsgegevens). Centraal in de zakelijke overeenkomst staat dus aansprakelijkheid. Tenzij technologie en wetgeving geregeld zijn ten aanzien van identiteiten is er geen bescherming van identiteitsgegevens. En als er geen bescherming is, dan is er geen aansprakelijkheid. En als er geen aansprakelijkheid is, dan kan dit ten koste gaan van het vertrouwen. Deze afhankelijkheid is weergegeven in de onderstaande Figuur 1.

Schaalt dat?

3

Trust

Aansprakelijkheid

Bescherming van gegevens

Eigenschappen van een identiteit

Figuur 1: Piramide van vertrouwen.

De technische aspecten van vertrouwen omvatten grotendeels het managen van de beveiliging van de communicatie-infrastructuur en het garanderen van de authenticiteit en integriteit van identiteitsgegevens. Grotendeels is dit geënt op cryptografische oplossingen. Dit betekent dat sleutelmanagement (sleutellengte, sleutelvalidatie, protocollen) goed geregeld moet zijn. Daarnaast zijn er nog andere technische aspecten zoals back-up voorzieningen, fysieke beveiliging en de kwaliteit van de connectie die van toegevoegde waarde zijn voor het creëren van vertrouwen. In een identiteitsfederatie komt er nog een extra dimensie bij die van belang is voor het vertrouwen: dat zijn de attributen die over de gebruiker gecommuniceerd worden en de betrouwbaarheid daarvan. Vaak komen die bij de IdP vandaan maar soms ook van een AP. Drie deelproblemen voor vertrouwensmanagement zullen aangepakt moeten worden: 1. Het uitdrukken en verifiëren van vertrouwen op een flexibele, schaalbare en verantwoorde manier. 2. Monitoren van vertrouwensrelaties in de tijd zodat misbruik ervan gedetecteerd kan worden. 3. Managen en evalueren van vertrouwensrelaties gebaseerd op automatische detectie van misbruik. De laatste twee deelproblemen zorgen ervoor dat vertrouwensrelaties continue in de gaten gehouden worden zodat bij misbruik ervan de verantwoordelijke simpel en snel terecht gewezen kan worden. Partijen die op een of andere manier misbruik maken van hun vertrouwen zullen uit een identiteitsfederatie verwijderd moeten kunnen worden.

4


Het proces van het verwijderen of vernieuwen van identiteitsgegevens is een belangrijk element in elke federatie. Als dit proces niet goed ingericht is ontaardt een identiteitsfederatie, waar partijen veel vertrouwen hechten aan de authenticiteit en integriteit van identiteitsgegevens, al snel in een bron van fraude voor identiteitsdiefstal en misbruik van bronnen. Een effectief systeem voor het uitrollen, verifiëren en intrekken van identiteitsgegevens voor partijen die deze aanleveren en gebruiken is daarom essentieel voor een betrouwbare federatie. Voor het schaalbaar maken is delegatie een voor de hand liggende aanpak. Dit delegeren dient wel op basis van aansprakelijkheid te gebeuren. In veel van de huidige identiteitsfederaties worden zogenaamde claims gebruikt om vertrouwen te delegeren. Een claim bevat een aantal elementen (attributen) die iets zeggen over de gebruiker. De IdP bijvoorbeeld beweert dat een gebruiker 18 jaar of ouder is en de SP kan deze claim al dan niet accepteren op grond van een vertrouwensrelatie met de IdP. In grote federaties is het werken met claims niet altijd even eenvoudig: 1. Hoe zit het met de betrouwbaarheid van de claims? Is de uitgever ervan betrouwbaar genoeg? 2. Hoe zorg je ervoor dat de communicatie van claims op een veilige manier gebeurt? De integriteit en authenticiteit van de claims dient geborgd te worden. 3. Hoe zorg je ervoor dat op een goede manier met de informatie in de claims wordt omgegaan? Wordt er niet teveel informatie opgevraagd, wordt deze informatie niet te lang bewaard of doorgegeven aan derden? Om aansprakelijkheid te bepalen moeten de partijen die in de federatie actief zijn (eindgebruiker, zijn IdP, de SP) geïdentificeerd kunnen worden met een bepaalde mate van zekerheid. De eindgebruiker heeft hiervoor vaak een gebruikersnaam en wachtwoord, de IdP en de SP gebruiken veelal een digitaal (X.509) certificaat. Hiermee kan zekerheid gecreëerd worden door identiteitsinformatie op een integere en confidentiële te communiceren en doordat partijen gedane transacties niet meer kunnen ontkennen (non-repudiation). Daarnaast zullen de partijen die participeren in een federatie zich moeten conformeren aan de richtlijnen (policies) voor het gebruik van identiteitsinformatie zoals gespecificeerd door de federatie. Ook tussen federaties onderling zullen deze policies afgestemd moeten worden. Het gemak waarmee dit gedaan kan worden bepaald mede de schaalbaarheid van de federatie.

2.3

Vertrouwensmodellen voor identiteitsfederaties

Identiteitsfederaties zijn gebouwd op vertrouwen. Vertrouwen in een identiteitsfederatie wordt enerzijds gekenmerkt door de bereidheid van SPs om een transactie met een eindgebruiker aan te gaan op grond van zijn door de IdP overhandigde identiteitsgegevens en anderzijds door de bereidheid van de IdP om privacy gevoelige informatie prijs te geven. Voor zowel de SP als de IdP is deze bereidheid in eerste instantie een beleidskwestie. Technische kwesties zijn secondair maar dragen zeker bij. De authenticiteit en integriteit van de uit te wisselen identiteitsgegevens dienen immers geborgd te worden. Partijen die in de communicatieketen van de identiteitsgegevens zitten moeten elkaar vertrouwen.

Schaalt dat?

5

OASIS definieert drie hoog niveau vertrouwensmodellen [ 1]. Hoewel gericht op SAML, zijn deze generiek toepasbaar op identity federaties in het algemeen. Deze drie zijn: 1. Pairwise: waarbij een directe vertrouwensrelatie bestaat tussen de twee betrokken partijen.

IdP

SP

2. Brokered: waarbij een derde partij garant staat voor een vertrouwensrelatie tussen twee partijen. De derde partij wordt vaak gezien als vertrouwensmakelaar, ook wel trusted third party (TTP) genoemd. De relatie met de TTP kan direct of indirect zijn.

IdP

TTP

SP

3. Community: waarbij gezamenlijke afspraken en gedeelde belangen zorgen voor een vertrouwensrelatie. Er is hier sprake van een vertrouwensdomein of “circle of trust”. Bijvoorbeeld het lid zijn van een gemeenschap. Community vertrouwen kan geïmplementeerd worden middels een public key infrastructuur (PKI).

IdP

SP

Feitelijk zijn deze vertrouwensmodellen strategieën voor het inrichten van een federatie. Het moge duidelijk zijn dat een pairwise model in een federatieve context veel minder goed schaalt dan een brokered of community model. Het vertrouwensmodel van de SURFfederatie bevat elementen uit alle modellen. Er is een vertrouwen tussen de SURFfederatie hub en de IdPs, en tussen de hub en de SPs, de hub vormt daarbij dus als een soort TTP voor een indirect vertrouwen tussen de IdPs en de SPs, en in het bijzonder tussen de IdPs is sprake van een community vertrouwen omdat ze allen in het hoger onderwijs opereren. Er is ook sprake van pairwise vertrouwen omdat IdP specifiek kunnen aangeven voor welke SPs ze wel of niet hun gebruikers willen identificeren.

2.4

Vertrouwen in bestaande identiteitsfederaties

Om een beter overzicht te krijgen van hoe vertrouwen geregeld is in identiteitsfederaties zullen we in de komende secties een aantal bestaande identiteitsfederaties beschrijven en analyseren. We beginnen met de SURFfederatie zelf.

6


2.4.1

SURFfederatie

De SURFfederatie is een unieke identiteitsfederatie in de zin dat het gebruik maakt van een hub [ 2]. Alle identiteitsgegevens verlopen via de hub alwaar filtering kan plaatsvinden. De hub wordt door de partners (IdPs en SPs) technisch alswel organisatorisch vertrouwd. Hierdoor is het niet noodzakelijk dat er een directe technische en/of organisatorische vertrouwensrelatie tussen de IdPs en de SPs is. In de praktijk zien we dat er wel een directe organisatorische vertrouwensrelatie bestaat tussen de IdP en de SP omdat beide partijen actief zijn in de onderwijssector. Technisch is er vaak geen vertrouwensrelatie tussen de IdP en SP omdat de hub de handtekening van de IdP openbreekt tijdens het filteren van attributen. Als dit niet gedaan wordt kan er alsnog een directe technische relatie ontstaan. Vanuit aansprakelijkheidsperspectief kan dit gewenst zijn. In principe, echter, zorgt het hub model er voor dat het opbouwen van een federatie stukken makkelijker gaat omdat partijen ‘slechts’ vertrouwen hoeven te hebben in de hub. Onderstaande Figuur 2 geeft de vertrouwensrelaties in de SURFfederatie weer.

Hub

Trust

t us

Trust Gebruiker

Trust

Tr

IdP

SP

Figuur 2: Vertrouwensrelaties in de SURFfederatie.

Er is een standaard overeenkomst die partijen (in termen van de SURFfederatie: partners en members) kunnen ondertekenen om gebruik te maken van de SURFfederatie dienst. Deze overeenkomst is relatief ‘soft’, dat wil zeggen, er wordt uitgegaan van een SLS op basis van best effort en er zijn relatief weinig middelen om te controleren of de overeenkomst nageleefd wordt.

2.4.2

FEIDE

Feide is de Noorse tegenhanger van de SURFfederatie [ 3]. Feide maakt gebruik van een enkele IdP die een centrale login service biedt. De daadwerkelijke authenticatie van de eindgebruiker wordt door de aangesloten instellingen zelf gedaan. Basistechnologieën die binnen Feide gebruikt worden zijn LDAP en simpleSAML. De door Feide gekozen LDAP oplossing zorgt ervoor dat alle wachtwoorden “langs” een centrale Feide component komen. Dit impliceert dat gebruikers en IdPs een erg groot vertrouwen in Feide als organisatie moeten hebben. Ter vergelijking: in de SURFfederatie worden gebruikersnamen en wachtwoorden direct tussen de IdP en de eindgebruiker uitgewisseld zonder tussenkomst van de SURFfederatie hub.

Schaalt dat?

7

Tot voor kort moesten SPs een webformulier invullen om zich aan te sluiten bij de Feide federatie. Door gebruik te maken van Dynamic SAML hoeft dit echter niet meer. Metadata wordt nu automatisch uitgewisseld doordat de URL van de metadata gebruikt wordt als zogenaamde entityID. Als de simpleSAMLphp identiteitssoftware in Feide een inkomend SAML Request of Response krijgt, kijkt het in de opgeslagen metadata van Feide. Als daar geen vermelding is van de betreffende partij, dan kijkt het naar het entityID. Bij Dynamic SAML is dit een URL naar de metadata. De simpleSAMLphp software zal dan de metadata ophalen om vervolgens te kijken of er een entityID in staat dat overeen komt met het entityID van het SAML Request of Response. Op deze manier kunnen SPs en IdPs met elkaar communiceren zonder enige voorconfiguratie. Technisch schaalt deze oplossing goed maar voor wat betreft vertrouwen zullen nog wat andere maatregelen genomen moeten worden. De oplossing hier ligt in het betrouwbaar maken van het metadatadocument van de federatie. Op dit moment wordt in Feide de metadata nog niet ondertekend waardoor het alleen gebruikt kan worden in open federaties en tests. Voor gesloten federaties zal binnenkort functionaliteit voor het valideren van digitale handtekeningen onder metadata toegevoegd worden. Naast bovenstaande SAML gebaseerde IdP, biedt Feide een experimentele OpenIdP aan waarbij iedere willekeurige SP zich kan aansluiten [ 4]. Er hoeft hiervoor geen contract ondertekend te worden. Er is geen SLA; de IdP dienst wordt dus als best effort aangeboden. Eindgebruikers kunnen zelf een account registreren bij Feide’s OpenIdP. Gastbezoekers van Noorse universiteiten kunnen op deze manier eenvoudig toegang krijgen tot SPs.

2.4.2.1 Kalmar confederatie Feide is ook aan het experimenteren met confedereren met het Finse Haka, het Zweedse SWAMID en de WAYFs van Denemarken en IJsland, de zogeheten Kalmar confederatie [ 5]. Alle partijen hebben hiervoor een ‘memorandum of understanding’ getekend. Hierin staan o.a. de zakelijke, privacy en security, en technische en operationele voorwaarden beschreven [ 6]. Extra aandacht is er voor de privacy aspecten van de eindgebruiker. Door slechts de noodzakelijke attributen te delen en de eindgebruiker hiervan te informeren en consent te vragen wordt voldaan aan de Europese richtlijn voor Data Protection. De Kalmar identiteitsmanagement infrastructuur is volledig gebaseerd op SAML2.0 met een centrale SAML2.0 metadata file waarin alle geaggregeerde metadata staat (zie Figuur 3).

8


Kalmar metadata aggregate FEIDE

Univ of Oslo

SP

Uninett: Foodle

SP

NorduGrid: SLCS

SP

Ordbogen.com

SP

NIAS: AsiaPortal

FEIDE

IdP Univ of Bergen WAYF

Univ of Iceland IdP

Univ of Copenhagen

WAYF

Univ of Aarhus Haka

Haka

SWAMID

Univ of Helsinki

IdP

SP

CSC: supercomputer

Univ of Turku

IdP

SP

NMS in i ICT: Moodle

Univ of Uppsala

IdP

SP

Univ of Uppsala: LMS

Univ of Umeå

IdP

SP

Univ of Umeå: wiki

SWAMID

Figuur 3: Technische set-up van de Kalmar confederatie (uit [7]).

De geaggregeerde metadata file bestaat uit een verzameling van nationale metadata files. Hierin staan de IdP en SP Entity Descriptors. In deze Entity Descriptors zelf zijn weer de eigen certificaten van de deelnemers opgenomen waardoor geen PKIX nodig is (zie Figuur 4).

Figuur 4: Nationale metadata file en de Entity Descriptors daarin.

Het nadeel van een centrale geaggregeerde metada file is dat het alles of niets is en het lastig wordt om bepaalde informatie voor de andere federaties te verbergen. De Finse federatie mag bijvoorbeeld alleen maar de SPs (de zogenaamde SPEntities) zien en niet de IdPs (IdPEntities). Om dit op te lossen is Feide RnD bezig met het delegeren van subsets van entities naar andere metadata documenten. Hiervoor zijn wel enkele uitbreidingen nodig op het SAML2.0 Metadata Schema [ 8]. Als Feide hierin slaagt, heeft het een extra vorm van vertrouwensmanagement geïntroduceerd in een confederatie: het kunnen delegeren van federaties in een confederatie naar specifieke metadata waardoor niet iedereen zomaar overal bij kan komen. Andere aandachtspunten voor de Kalmar confederatie op korte termijn zijn het afstemmen van de attributen tussen de leden (verplichte attributen, semantiek en unieke identifiers), het vaststellen van de minimale IdP eisen voor toetreding tot de confederatie, en gebruikersonderzoek.

Schaalt dat?

9

2.4.3

InCommon/Shibboleth

De Amerikaanse federatie voor het hoger onderwijs, InCommon [ 9], is gebaseerd op Shibboleth technologie [ 10]. InCommon maakt gebruik van zogenaamde POPs (Participant Operational Practices) waarin beschreven staat waaraan leden van de federatie moeten voldoen. Als hieraan voldaan wordt zal voor toetreding tot de federatie een Participation Agreement (PA) getekend moeten worden. Deze PA kan gezien worden als een lage drempel om toe te treden tot InCommon maar biedt slechts beperkte aansprakelijkheid indien er iets mis gaat. Veel vertrouwen komt uit het feit dat alle partijen uit het hoger onderwijs komen en elkaar dus enigszins kennen. Alle partijen die meedoen in InCommon moeten hiervoor: ◊

Een contract ondertekenen waarin gedefinieerd staat hoe de partijen in de federatie samenwerken.

◊

Conventies adopteren betreffende de betekenis van attributen.

◊

Voldoen aan de eisen voor de beschikbaarheid van deze attributen.

◊

Zich conformeren aan de geaccepteerde CAs voor het tekenen van de certificaten of overeenstemming krijgen over het gebruik van self-signed certificaten.

◊

Metadata delen.

◊

Instemmen met de door de federatie opgelegde levenscyclus van de metadata.

◊

Zorgen voor een goed onderhouden Where Are You From dienst voor het lokaliseren van de IdP.

Het is de verantwoordelijkheid van elke partij zelf in de federatie om de betrouwbaarheid van de partij waarmee zaken gedaan worden te valideren. Naast het controleren van het certificaat dat gebruikt is voor het opzetten van een veilig communicatiekanaal kan de federatie metadata hierbij helpen (is een bepaalde partij lid van de federatie?). IdPs zijn verantwoordelijk voor het op een goede manier authenticeren van de eindgebruikers; de SPs zijn ervoor verantwoordelijk nooit gebruikersgegevens verzamelen, meer vragen dan nodig is, of gegevens te delen met derden. Zoals gezegd wordt Shibboleth gebruikt als de onderliggende technologie voor de InCommon federatie. In Shibboleth wordt alle metadata informatie op een centrale plaats verzameld. Iedere partij die daar in staat doet mee met de federatie en is te vertrouwen. De federatie metadata wordt ondertekend door InCommon als TTP. Certificaten en CAs zijn onderdeel van de metadata. Alles is gebaseerd op PKIX. Daarnaast wordt ‘extra’ vertrouwen geput uit het matchen van de sleutel in het certificaat dat gebruikt is voor het opzetten van een veilig communicatiekanaal met de sleutel van het certificaat in de metadata. InCommon gebruikt zijn eigen federatiespecifieke CA als vertrouwensbasis. Dit gemak gaat ten koste van de voordelen die een bestaande, commerciële CA kan aanbieden. Het meenemen van certificaten in de federatie metadata brengt wel een extra last met zich mee voor de federatie coördinator. Deze moet ervoor zorgen dat de juiste certificaten zich in de metadata bevinden.

10


De ondertekende federatie metadata file wordt dus regelmatig geüpdate om ervoor te zorgen dat de gegevens zo betrouwbaar mogelijk zijn. Vaak is de update frequentie van de metadata file hoger dan dat van de certificaten die erin zitten zodat revocatieproblemen zich niet zo snel zullen voordoen. De huidige metadata file is nog betrekkelijk klein, maar dit kan in de toekomst veranderen waardoor de schaalbaarheid in het geding komt. Mogelijke korte termijn oplossingen om de metadatadistributie beter te laten schalen zijn het opsplitsen naar aparte IdP en SP metadata files, gebruiken van compressietechnologie, of door de federatie op te splitsen in kleinere federatie die met elkaar geconfedereerd zijn. Voor de langere termijn heeft Shibboleth de ambitie om over te gaan op een decentraal systeem voor metadatamanagement. Dit kan door de partijen zelf hun metadata te laten uitgeven. Echter, hierdoor kan de vertrouwensketen onder druk komen te staan. Verder kunnen bepaalde metadata elementen (zoals de lijst van betrouwbare CAs) niet door een individuele partij uitgegeven worden.

2.4.4

Covisint

Covisint is de spin in het wiel van Amerika’s grootste federatie in de automobielindustrie [ 11]. Netwerken van fabrikanten, toeleveranciers en handelaren worden door Covisint aan elkaar geknoopt en ontsloten via SAML. Covisint is dus een TTP voor haar klanten en kan dus ook gezien worden als een hub. Maar dan eentje die nadrukkelijk identiteitsmanagement als een service aanbiedt. Hiermee lijkt Covisint een beetje op de SURFfederatie. Beide federaties houden zich bijvoorbeeld bezig met protocoltranslaties en het algemene management van de federatie. Echter, Covisint biedt een aantal diensten aan die het potentiële gebruikers makkelijker maken om toe te treden en voor participerende partijen een stuk zelfmanagement faciliteren en hun van waardevolle informatie voorzien. Dit soort diensten zijn onder andere: ◊

Een interface waarmee de klant zelf zijn connecties met andere partijen in de federatie via de hub kan configureren. Klanten kunnen bijvoorbeeld zelf bepalen of ze vindbaar zijn in de federatie. Bestaande relaties kunnen eenvoudig opgeschort worden via de interface. Nieuwe relaties worden door een request/approval workflow mechanisme beklonken. En alles wordt gelogd. Met andere woorden, taken die in de SURFfederatie nog handmatig verricht worden door SURFnet zijn door Covisint geautomatiseerd en zodanig dat de partijen in de federatie hiervoor zelf verantwoordelijk zijn.

◊

Het loggen van in- en uitgaand verkeer is een andere nuttige dienst voor het borgen van vertrouwen. Covisint houdt op transactiebasis precies bij wie wat met wie doet. Samenvattingen en gedetailleerde rapporten zijn beschikbaar via de klantinterface (vorige punt) zodat iedereen op de hoogte is van alle relevante informatie. Partijen kunnen elkaar hiermee verantwoordelijk stellen voor uitgevoerde transacties.

◊

Het gebruik van verschillende authenticatieniveaus op grond waarvan partijen de toegang tot hun diensten kunnen controleren. Deze partijen kunnen zelf het gewenste niveau van authenticatie instellen. Covisint biedt het raamwerk van authenticatieniveaus aan zodat iedereen dezelfde taal spreekt.

Schaalt dat?

11

◊

Doorklikschermen om tot een vertrouwensovereenkomst te komen. Covisint maakt de contractuele aspecten van een federatie zo simpel mogelijk door online template gebaseerde overeenkomsten aan te bieden. Elke partij die zich bij de hub wil aansluiten moet een dergelijke standaard template invullen. Daarnaast heeft elke partij de mogelijkheid om zijn eigen overeenkomsten te uploaden die betrekking hebben op de relaties die aangegaan worden met andere partijen in de federatie. Covisint houdt middels versie- en timestamping een volledig audit record bij van de overeenkomsten tussen alle partijen.

Stuk voor stuk zijn dit diensten die bijdragen aan het creëren en schaalbaar maken van vertrouwen. Daarnaast doet Covisint er ook van alles aan om haar status als TTP zo hoog mogelijk te krijgen en te houden, bijvoorbeeld door te laten zien dat ze gecertificeerd is in termen van beschikbaarheid, robuustheid en veiligheid. De vraag is of klanten altijd op basis van vertrouwen in zee gaan met Covisint. Voor sommige (kleinere) klanten is aansluiten bij Covisint de enige manier om te overleven. Een totaaloverzicht van het Covisint Trusted Identity Framework is afgebeeld in Figuur 5.

Figuur 5: Covisint Trusted Identity Framework [12].

Recentelijk heeft Covisint, samen met Microsoft, ook haar vleugels uitgeslagen in de zorgsector. Duidelijk is dat een TTP niet noodzakelijkerwijs met een enkel domein geassocieerd hoeft te worden. Ook kijkt Covisint naar steeds meer andere sectoren zoals financieel en overheid.

12


2.4.5

STORK

Bijna elk land in Europa heeft een eigen oplossing voor het identificeren en authenticeren van haar burgers voor e-government diensten. Nederland heeft bijvoorbeeld het op primair gebruikersnaam en wachtwoord gebaseerde DigiD, België en Duitsland hebben een identiteitskaart waarop informatie staat, en in Estland wordt zelfs een met persoonsgegevens verrijkte bankpas gebruikt.

a. STORK Probleem

b. STORK oplossing: definieer QAA niveaus en mappings Figuur 6: STORK uitdaging.

Schaalt dat?

13

Het Europese STORK project heeft als doel om interoperabiliteit te creëren tussen de verschillende nationale authenticatie-oplossingen (Figuur 6, [ 13]). Een Nederlandse burger kan dan bijvoorbeeld zijn DigiD gebruiken voor het aanvragen van een vergunning in Spanje. De Spaanse SP moet dan wel vertrouwen hebben in de Nederlandse oplossing. STORK lost dit op door een Quality Authentication Assurance raamwerk te definiëren. Dit QAA raamwerk biedt de lidstaten de mogelijkheid om hun nationale identificatie- en authenticatie-oplossingen te kwalificeren. Gebaseerd op de mogelijke impact van een foute identiteit zijn vier niveaus van authenticatie gedefinieerd. Bij het laagste niveau is bijna geen zekerheid over de identiteit van de gebruiker; bij het hoogste niveau is zeer veel zekerheid. Een zevental aspecten bepalen de hoogte van het niveau: identificatie van de burger, het uitgifteproces van digitale identiteiten, de betrouwbaarheid van de uitgevende instantie, life-cycle management van identiteiten, authenticatie token type, technische protocollen en het management van claims. Merk op dat de eerste vier aspecten van organisatorisch aard zijn terwijl de laatste drie een sterk technisch karakter hebben. Het STORK QAA raamwerk maakt het mogelijk om niveaus van authenticatie op elkaar te mappen zodat interoperabiliteit ontstaat. Zo kan een Duitse SP STORK niveau vier eisen voor service toegang; een Nederlandse burger zal met zijn DigiD dat in STORK terminologie een niveau twee oplossing is dus nooit toegang krijgen tot deze dienst. De STORK infrastructuur voorziet in functionaliteit voor het op elkaar mappen van authenticatieniveaus (zie Figuur 7).

Service Provider

requested level

National Levels

STORK QAA Levels

STORK QAA Levels

National Levels

requested a level

Service Providers

Figuur 7: Mappen van authenticatieniveaus in STORK.

Het niveau van authenticatie geeft de SP dus voldoende zekerheid voor het al dan niet toelaten van burgers uit andere landen tot zijn dienst. Dit is dus een puur technische oplossing. Afspraken over aansprakelijkheid en het monitoren van gedrag in STORK vormen een heet hangijzer en zijn nog niet gemaakt.

2.4.6

GRID

De Euro Grid Policy and Management Authority is een overkoepelend orgaan dat ervoor zorgt dat onderzoekers op een betrouwbare manier toegang krijgen tot Grid resources in Europa [ 14]. EUGridPMA regelt de trust fabric voor authenticatie in de Europese e-science Grid. Het werkt samen met peers in Azië en Amerika onder de coördinatie van de International Grid Trust Federation [ 15]. Zoals gebruikelijk in de Grid wereld is het vertrouwen geregeld door middel van een X.509 PKI. Binnen de onderzoekswereld is dit acceptabel maar in identiteitsfederaties waarbinnen commerciële partijen actief zijn ligt deze oplossing minder voor de hand.

14


2.4.7

eduGAIN

Het doel van eduGAIN is om een inter-operabele authenticatie- en autorisatie-infrastructuur te bouwen voor het verbinden van verschillende identiteitsfederaties in het hoger onderwijs [ 16]. Studenten in een ander land kunnen dan gewoon gebruik maken van hun eigen IdP om toegang te krijgen tot diensten in dat land. Het EU STORK project heeft een soortgelijk doel voor ogen maar dan voor burgers in het algemeen. De eduGAIN infrastructuur zoekt uit tot welke federatie de eindgebruiker behoort (waar zijn IdP staat), vertaalt berichten die uitgewisseld worden tussen federaties (van federatie interne protocollen naar eduGAIN protocollen en vice versa) en borgt het vertrouwen tussen de deelnemende partijen (federaties en hun partners). Om dit doel te bereiken zijn er twee basisdiensten gedefinieerd: de MetaDataService (MDS) voor het uitwisselen van confederatiespecifieke informatie (metadata) en de zogenaamde Bridging Elements (BEs) voor het koppelen van de verschillende federaties in/aan eduGAIN. Federaties kunnen hun metadata via Federation Peering Points (FPPs) publiceren aan de MDS. Hiervoor is een certificaat nodig dat is uitgegeven door een CA die vertrouwd wordt door eduGAIN. De via de FPP geuploade metadata betreft informatie over de locatie van de authenticerende en autoriserende partners (IdPs en SPs en de daaraan gecorreleerde EntityDescriptors) in een federatie. De betreffende authenticatie- en autorisatieverzoeken worden door de BEs zodanig verwerkt dat ze uitkomen bij de eigen IdP van de eindgebruiker. Om het vertrouwen te borgen moeten de EntityDescriptors in de metadata een digitale handtekening en certificaat van de betreffende partner bevatten die beiden gecontroleerd kunnen worden. Daarbovenop wordt de digitale handtekening van de FPP gezet. Dit is weergegeven in Figuur 8. Hierdoor is het mogelijk om op een gecontroleerde manier certificaten in te trekken zonder dat de vertrouwenshiërarchie geschonden wordt (openbreken van handtekeningen).

Schaalt dat?

15

Figuur 8: Metadata handtekeningen en certificaten constructie in eduGAIN [17].

Een hoog-niveau eduGAIN infrastructuur en de berichtenuitwisseling erin is weergegeven in Figuur 9.

Figuur 9: eduGAIN infrastructuur en berichtuitwisseling.

De MDS is gebaseerd op REST interfaces voor het transporteren van SAML 2.0 metadata. Metadata wordt gepubliceerd en opgehaald door middel van respectievelijk POST en GET operaties.

16


In eduGAIN wordt de vertrouwensrelatie tussen twee partijen uit verschillende federaties op een dynamische manier tot stand gebracht. Dit moet wel omdat het onmogelijk is om vooraf alle vertrouwensrelaties op te bouwen; partijen uit verschillende federaties kennen elkaar vaak niet. De metadata verkregen van de MDS wordt dus gebruikt als basis voor het vertrouwen tussen twee uit verschillende federaties interacterende partijen. eduGAIN maakt naast het uitwisselen van metadata gebruik van een PKI voor het opbouwen van dit vertrouwen [ 18]. De validatieprocedure bestaat uit regulier certificaatvalidatie op grond van trust path evaluatie, handtekeningen en herroeping. Certificaten worden ook gebruikt om TLS connecties op te zetten tussen de infrastructurele componenten (twee-weg validatie is verplicht) en voor de verificatie van ondertekende beweringen. Een component ID wordt gebruikt in de certificaten voor peer identificatie. Belangrijk is dus ook dat alle partijen voldoende vertrouwen hebben in de eduGAIN infrastructuur. In het bijzonder de BEs waar bijvoorbeeld de voor interoperabiliteit benodigde data- en protocoltransformaties plaatsvinden zijn hierin een kritieke factor [ 19]. De vraag is of het haalbaar is dit vertrouwen te creëren. Wie staat ervoor in als er iets fout gaat bij een BE? Misschien is het beter om eerst af te vragen of de aanwezigheid van BEs wel noodzakelijk is. Door de razendsnelle ontwikkelingen op het gebied van identiteitsfederaties is er onlangs een discussiedocument opgesteld dat de bruikbaarheid van de eduGAIN infrastructuur ter discussie stelt [ 20]. Omdat steeds meer partijen overgaan op SAML 2.0 als de standaard voor het uitwisselen van identiteitsgegevens is de noodzaak voor BEs steeds minder geworden. Naast het feit dat deze BEs voor nogal wat overhead en complexiteit zorgen, creëren ze ook een extra component waarin vertrouwen gesteld moet worden. Het voorstel pleit er dan ook voor een alternatieve oplossing zonder BEs waarin het vertrouwen uit de metadata gehaald wordt. Een ‘meta-metadata’ dienst wordt voorgesteld als oplossing (zie Figuur 10). Deze dienst aggregeert in feite alle metadata uit de gekoppelde federaties tot een grote metadata file.

Schaalt dat?

17

Figuur 10: Een alternatief voor de huidige eduGAIN infrastructuur voor confederatie.

2.5

Conclusies

Vertrouwen is opgebouwd uit een complexe verzameling van elementen. Het managen van vertrouwen is daardoor niet eenvoudig. Duidelijk is wel dat er onderscheid gemaakt dient te worden tussen verschillende typen van vertrouwen in een identiteitsfederatie: vertrouwen in de SURFfederatie zelf (organisatorisch vertrouwen) en vertrouwen in de technologie die de SURFfederatie gebruikt (technisch vertrouwen). Vertrouwen in een autoriteit verschilt immers zeer van vertrouwen in technologie. Vertrouwen in technologie is meer objectief, terwijl vertrouwen in een andere partij of een autoriteit meer subjectief van aard is. Het vertrouwen in de SURFfederatie vereist bijvoorbeeld inzicht van de gebruikers en deelnemende partijen in de integriteit en de mogelijkheid van SURFnet om de federatiedienst op een juiste manier aan te bieden. Vertrouwen is dan de verwachting dat de beloften en handelingen van SURFnet en de SURFfederatiedienst en hun deelnemers betrouwbaar zijn. De mate van vertrouwen van partijen in elkaar bepaalt ook welke informatie uitgewisseld wordt. Een risico-analyse ligt hier vaak aan ten grondslag maar ook meer subjectieve aspecten als gevoel of ervaring. Het verkrijgen van dit soort organisatorisch vertrouwen tussen de SURFfederatie aan de ene kant en de SPs en IdP aan de andere kant, en daarmee van de SPs en IdPs onderling, kan dan op de volgende manieren gebeuren: ◊

18

door gebruik te maken van bepaald interactiemodel: pairwise, brokered of community. Dit geldt niet alleen voor de inrichting van de federatie zelf, maar kan ook toegepast worden over federaties heen. Bij dit laatste spreken we van confederaties ofwel het federeren van federaties.


◊

door middel van reputaties of certificering. Ebay is een goed voorbeeld van vertrouwen op basis van reputaties. Een verkoper op Ebay met een positief feedback profiel zal in de regel meer vertrouwen genieten van potentiële kopers dan een verkoper met een minder sterk profiel. Een certificaat van een erkende instelling (ISO, NEN) straalt betrouwbaarheid uit naar de buitenwereld.

◊

door transparantie te verstrekken aan eindgebruikers of partners over bijvoorbeeld op welke manier identiteitsgegevens uitgewisseld worden. Inzicht op de processen en organisatie ervan levert helderheid op en daarmee vertrouwen. Ook jaarverslagen vormen een bron van informatie voor buitenstaanders waaruit vertrouwen te halen is voor mogelijke toetreding tot de federatie.

◊

door het monitoren van goed gedrag. Audits en het loggen van transacties kunnen ervoor zorgen dat achteraf partijen aangesproken kunnen worden over hun activiteiten in de federatie.

Technische hulpmiddelen kunnen helpen om dit meer subjectieve vertrouwen te vergroten. Hierbij dient onderscheid gemaakt te worden tussen het vertrouwen in een partij en het vertrouwen dat gehecht kan worden aan de informatie die verstrekt wordt door die partij. Het technisch verwerven van beide ‘vertrouwenssmaken’ kan op de volgende manieren: ◊

door het uitwisselen van informatie betreffende de (technische) inrichting van de federatie. Deze informatie wordt ook wel federatie metadata genoemd. Op basis van de metadata kunnen partijen inschatten of ze elkaar vertrouwen. Organisatorische vertrouwensaspecten worden soms impliciet meegenomen in de metadata. Denk hier bijvoorbeeld aan een lidmaatschap element op basis van een community certificaat dat in de metadata zit.

◊

door middel van cryptografie of door berichten digitaal te ondertekenen met een (digitale) handtekening. Dergelijke technieken leveren dan het ‘bewijs’ dat iets betrouwbaar genoeg is om vertrouwen aan te schenken.

We hebben ook gezien dat technische hulpmiddelen, zoals bridges om verschillende federaties aan elkaar te koppelen waardoor een grotere confederatie ontstaat, gepaard gaan met additionele vertrouwenskwesties. Ook de bridges zullen vertrouwd moeten worden en dat is nog niet zo eenvoudig te realiseren, zeker niet op een schaalbare manier. In identiteitsfederaties wordt vertrouwen over het algemeen gecreëerd door een federatieoperator in de vorm van standaarden, regels en afspraken. Verschillende federaties pakken deze aspecten op hun eigen manier aan voor het schaalbaar maken van vertrouwen. In relatief kleine federaties is het nog behapbaar om met iedere partij een contractuele overeenkomst te tekenen waarin alle risico’s en aansprakelijkheden afgedekt worden. Hierbij helpt het vaak als partijen in het zelfde domein of keten actief zijn zoals het onderwijs. Ondanks het feit dat dit model niet echt schaalt, zien we dat internationaal veel onderwijsfederaties kiezen voor bilaterale afspraken. Het risico dat hiermee gepaard gaat is dat afspraken en regels, ten faveure van het uitbreiden van de federatie, steeds minder goed geregeld worden. Misschien dat het glazen plafond voor identiteitsfederaties eigenlijk een soort filter is dat ervoor zorgt dat het borgen vertrouwen afneemt naarmate de federatie groter wordt.

Schaalt dat?

19

In domeinen of ketens waarin een sterke, dominante partij aanwezig is wordt het hub model regelmatig toegepast voor het schaalbaar maken van de federatie. Ook het managen van vertrouwen in technische en organisatorische zin wordt hierdoor eenvoudiger. De hub regisseur als federatie operator bepaald de spelregels in termen van standaarden en overeenkomsten. De SURFfederatie heeft een dergelijk hub model geadopteerd. Hierdoor is de hub voor SPs een aantrekkelijke partner omdat ze dan niet met iedere afzonderlijke IdPs afspraken hoeven te maken. Voor het hub model spelen domeingebaseerde vertrouwensrelaties en afhankelijkheden een nog grotere rol dan in de kleine federaties. Zodra de ambitie bestaat om federatiepartners van buiten het domein te halen ontstaan de problemen. Deze partners hebben vaak eigen eisen en wensen betreffende vertrouwen (ze zijn immers niet bekend met het domein) en de elementen waarop ze dit baseren (beveiliging, aansprakelijkheid, beschikbaarheid, etc.). En hier lopen veel federaties momenteel tegen aan. Opvallend is dat veel federaties dit proberen op te lossen door informatie te verstrekken in de vorm van efficiënte(re) metadata management en het vertrouwen in de metadata onder te brengen, standaardisatie of door het overdragen van verantwoordelijkheden door zelfmanagement. Welke andere oplossingen zijn er nog meer? In de volgende twee hoofdstukken gaan we dieper in op de schaalbaarheid van de al geïdentificeerde en enkele nieuwe oplossingsrichtingen voor het organisatorisch en technisch creëren van vertrouwen.

20


3 Organisatorische oplossingsrichtingen In dit hoofdstuk beschrijven we de volgende organisatorische oplossingsrichtingen voor het schaalbaar(der) maken van vertrouwen in identiteitsfederaties: ◊

Informatie;

◊

Transparantie en controle;

◊

Confederaties;

◊

Reputatiemanagement;

◊

Identiteitszekerheid;

◊

Outsourcing;

◊

Governance.

We beginnen met informatie en hoe dat kan helpen bij het opbouwen van vertrouwen.

3.1

Informatie

Als een partij een privacy policy heeft, een contract heeft getekend of een gekwalificeerd certificaat heeft is dit nog geen garantie dat deze partij te vertrouwen is. Er bestaat dan nog steeds de kans dat deze partij toch verkeerd omgaat met identiteitsinformatie. Eigenlijk is dit het echte probleem van vertrouwen: hoe er achter te komen dat zo’n partij doet wat hij belooft. Om te beginnen is het dan verstandig om zoveel mogelijk informatie over die partij te verzamelen. Uit bijvoorbeeld de jaarverslagen, uit interviews met andere klanten, via Google, etc. Daarnaast is het monitoren van het gedrag van een dergelijke partij essentieel. Hoewel het kwaad dan al geschied kan zijn biedt dit toch de mogelijkheid om partijen die zich niet aan de federatiepolicy houden te detecteren en uit de federatie te zetten.

3.1.1

Evaluatie

Vertrouwensbeslissingen worden over het algemeen genomen op grond van informatie. Hoe meer informatie beschikbaar is des te beter kan een risico-afschatting gemaakt worden om wel of niet een partij toe te laten tot de federatie of om zaken mee te doen. Het moge duidelijk zijn dat deze manier, ondanks dat het waarschijnlijk de beste is, slecht schaalt en dan nog steeds geen 100% zekerheid geeft dat een partij te vertrouwen is. Bij een veranderende context kan een partij zich ineens heel anders gaan gedragen. Logging van activiteiten en audits kunnen de vertrouwensafweging op grond van minder informatie vergemakkelijken. Een partij die zich niet aan de federatiepolicy houdt kan dan alsnog tot de orde geroepen worden.

3.2

Transparantie en controle

Bij de Covisint federatie hebben we al gezien dat zij op verschillende manieren hun leden van informatie voorzien en een bepaalde mate van controle geven in de vorm van transactie logfiles en een gebruikersvriendelijke interface voor het managen van relaties. Nog een stapje verder is de eindgebruiker inzage en controle te geven in welke identiteitsinformatie hij doorgeeft aan de SPs. De nog relatief nieuwe user-centric identiteitsmanagementoplossingen spelen hierop in.

Schaalt dat?

21

3.2.1

User-centric identiteitsmanagement

In het vorige hoofdstuk hebben we gezien dat federaties goed functioneren als eindgebruikers gebruik van diensten kunnen maken in een goed afgebakend en vertrouwd domein (bijvoorbeeld het onderwijs of de automotive). Partijen kunnen dan relatief eenvoudig overeenkomsten afsluiten over het delen van identiteitsinformatie. Vaak gebeurt dit zonder dat de eindgebruiker hier zelf iets vanaf weet of bij betrokken is. Het enige waarop de eindgebruiker kan hopen is dat in deze afspraken rekening gehouden wordt met de vigerende wetgeving betreffende het uitwisselen van persoonsinformatie. Deze persoonsinformatie betreft niet alleen gegevens als NAW, leeftijd en geslacht maar ook specifieke identifiers zoals het Burger Service Nummer (BSN) die een unieke link vormen naar de betreffende identiteit van persoon in kwestie. Zodra een eindgebruiker van diensten gebruik wil maken uit meerdere domeinen, waarbij partijen die de diensten leveren elkaar niet goed kennen, ontstaan de problemen. Identiteitsinformatie moet dan gedeeld worden met partijen waar amper een vertrouwensrelatie mee is. Dit motiveerde de ontwikkeling van user-centric identiteitsmanagementoplossingen waarin de eindgebruiker centraal wordt gezet. Er zijn een aantal identiteitsmanagementoplossingen voorhanden die de eindgebruiker een zekere mate van controle geven over welke persoonlijke gegevens zij aan SPs communiceren en welke IdP dit zou kunnen doen. In deze oplossingen wordt een stuk verantwoordelijkheid bij de eindgebruiker geplaatst waardoor deze direct aanspreekbaar wordt in geval van een incident. Hierdoor komt er minder druk op het creëren van zogenaamde circles of trust met complexe vertrouwensrelaties tussen IdPs en SPs. De SPs geven in dit geval aan welke attributen zij eisen voor toegang en welke IdPs zij vertrouwen en het is aan de eindgebruiker om hiermee akkoord te gaan en ervoor te zorgen dat de gegevens door een geprefereerde IdP aangeleverd worden. Een interessant aspect van enkele user-centric oplossingen, zoals Windows Cardspace [ 21] en Higgins [ 22], is dat ze gebruik maken van zogenaamde infocards. Deze kaartjes bevatten de identiteitsgegevens die de SP nodig heeft en worden naar de eindgebruiker toe gepresenteerd als een soort identiteitskaart. De achterliggende motivatie hiervoor is dat dit een metafoor is die de gebruiker begrijpt, waardoor de transparantie en daarmee ook het vertrouwen bij de eindgebruiker toenemen. Er zijn twee typen infocards: managed en self-issued cards. De managed cards zijn ondertekend door de IdP, de self-issued cards zijn door de eindgebruiker zelf aangemaakt. Het spreekt voor zich dat de managed cards de SPs meer zekerheid bieden betreffende de juistheid van de identiteitsgegevens die ermee geassocieerd zijn.

22


Het nadeel van dit soort user-centric identiteitsmanagementoplossingen is dat de eindgebruiker altijd consent moet geven en dus potentieel vaak ‘lastig gevallen’ moet worden. In Microsoft’s Geneva zit al functionaliteit die het automatiseren van toestemming van de gebruiker om gegevens te delen mogelijk maken zodat hij/zij niet steeds lastig gevallen wordt met het geven van toestemming. In Higgins wordt gebruik gemaakt van zogenaamde relationship cards (r-Cards) om gebruikers van identiteitsgegevens, onder controle van de eigenaar, deze dynamisch te laten ophalen van een of meerdere locaties [ 23]. In een r-Card zit namelijk een pointer naar een SP die bepaalde informatie over een gebruiker heeft. De eigenaar van de persoonsgegevens geeft middels een r-Card dus indirect toestemming aan de gebruiker van deze gegevens om ze op te halen bij de attribuut SP. Deze attribuut SP haalt hier zijn vertrouwen uit. r-Cards vertegenwoordigen verschillende typen relaties – tussen personen, tussen een persoon en een verkoper, tussen verkopers – en kunnen dus gebruikt worden om gegevens als e-mail adressen en spaarkaartpunten te delen en te synchroniseren. 3.2.1.1 Relatiemanagement Sommige mensen zeggen dat het internet geen identiteitsmanagementlaag maar een relatiemanagementlaag nodig heeft om vertrouwen en daarmee toegang tot diensten beter in te regelen [ 24]. Wij denken dat beide lagen noodzakelijk zijn. Een relatiemanagement benadering streeft ernaar om vertrouwen op grond van relaties tussen betrokken partijen te borgen. De hierboven genoemde r-Card van Higgins is hiervan een goed voorbeeld. Nog verder gaat het Vendor Relationship Management (VRM) concept [ 25]. VRM is feitelijk de tegenpool van de huidige CRM-systemen die bedrijven er nu op na houden. Bij VRM wordt de eindgebruiker centraal gesteld. Het biedt de eindgebruiker de mogelijkheid om relaties te managen waarmee hij/zij identiteitsinformatie wil delen. Met andere woorden, de eindgebruiker staat centraal en bepaalt wie bij welke gegevens mag/kan komen. Het vertrouwensmodel van VRM komt voort uit de relaties die beide partijen met elkaar hebben. De vraag is echter hoe en op welke basis de relatie tot stand komt. Hierin zit een informatiecomponent (de eindgebruiker geeft data waarop de SP zijn beslissing kan maken) en een tijdsaspect (het vertrouwen groeit naarmate er meer transacties naar tevredenheid zijn uitgevoerd). In ieder geval gaan beide partijen een verplichting aan voor een relatie. Het Project VRM is momenteel druk om het VRM concept handen en voeten te geven [ 26]. Er zijn nog weinig concrete producten op de markt. SUN heeft onlangs haar implementatie van VRM onder de naam ProtectServe gepresenteerd [ 27]. ProtectServe is een op OAuth gebaseerd VRM protocol dat de eindgebruiker de mogelijkheid geeft om centraal de toegang tot persoonlijke informatie te regelen. Het ProtectServe protocol schrijft de interacties tussen vier partijen voor: de eindgebruiker/agent, een Autorisatie Manager, een attribuut SP en een consument van persoonsinformatie. Bovenop de Autorisatie Manager kan een centrale Relatie Manager applicatie gebouwd worden die opereert namens de eindgebruiker. Het gebruik van OAuth [ 28] en REST [ 29] zorgen ervoor dat ProtectServe een schaalbare en relatief generieke oplossing biedt voor user-centric identiteitsmanagement, ook in een web service omgeving.

Schaalt dat?

23

Het vertrouwensmodel van ProtectServe wordt dus sterk vanuit eindgebruikerperspectief benaderd. De eindgebruiker bepaalt wie toegang krijgt tot persoonlijke informatie; hij/zij bepaalt welke partijen hierin te vertrouwen zijn. De vraag is in hoeverre de consumenten van persoonsinformatie hiermee uit de voeten kunnen. Zij zullen afgaan op de betrouwbaarheid van de IdPs of attribuut SPs waarvan zij deze informatie verkrijgen. ProtectServe zegt niets over de vertrouwensrelatie tussen deze twee partijen.

3.2.2

Evaluatie

Door het inzetten van user-centric identiteitsmanagement oplossingen wordt de verantwoordelijkheid voor het aanleveren van identiteitsgegevens verplaatst van de IdP naar de eindgebruiker. De eindgebruiker heeft controle over welke SP welke persoonlijke data ontvangt. Dit zal hem een beter vertrouwen geven in de federatie dan wanneer alles onder water gebeurt. Voor het meekrijgen van eindgebruikers in de federatie kan het inzetten van user-centric identiteitsmanagement dus helpen. Toch zal er een vertrouwensrelatie moeten bestaan tussen de IdP en de SP. In die zin verandert er niet zo heel veel ten opzichte van een IdP-centric oplossing. Hooguit is er iets minder vertrouwen nodig tussen beide partijen omdat de eindgebruiker verantwoordelijk gesteld kan worden. User-centric identiteitsmanagement oplossingen komen beter uit de verf in publieke omgevingen waar policies die vastleggen op welke manier er met identiteitsgegevens wordt omgegaan ontbreken. In een federatie als de SURFfederatie is hier veel meer controle op waardoor er vanuit vertrouwensperspectief niet echt noodzaak is om over te stappen van een IdP-centric naar user-centric oplossing. Over de schaalbaarheid van relatiemanagement oplossingen kunnen we kort zijn: het schaalt slecht en staat nog teveel in de kinderschoenen om bruikbaar te zijn voor de SURFfederatie. Vooral voor de SPs zal het ingewikkeld worden om alle relaties met gebruikers te managen. VRM zegt niets over het intrekken van relaties in het geval van misdragingen. Ook zal de eindgebruiker door de vele te verwachten verschillende relaties met SPs op een gegeven moment door de bomen het bos niet meer zien en zal zich afvragen met wie hij nu welke identiteitsgegevens uitwisselt. Dit zal zijn vertrouwen niet ten goede komen.

3.3

Confederaties

In plaats van te streven naar één grote identiteitsfederatie en naar vertrouwensoplossingen hiervoor is een andere aanpak om verschillende relatief kleine federaties met elkaar te confedereren. Er zal dan een soort meta-vertrouwenslaag bovenop de individuele federaties moeten komen. De in sectie 2.4.2.1 beschreven Kalmar confederatie is hiervan op kleine schaal (qua aantal federaties) al een goed voorbeeld. Op grotere schaal wordt binnen eduGAIN ook gewerkt aan een Europees dekkende confederatie voor het hoger onderwijs.

24


Vanuit organisatorisch perspectief is het inrichten van een confederatie geen sinecure. De vertrouwensproblemen in een federatie herhalen zich in een confederatie maar dan op een iets hoger niveau. Federatie operators zullen afspraken moeten maken over zaken als metadata uitwisseling, privacy policy afstemming, semantiek en syntax van attributen, en aansprakelijkheid. Maar bovenal zal gekeken moeten worden naar een gedeeld vertrouwenselement. Dit kan zijn omdat iedereen in het hoger onderwijs actief is maar kan ook vorm gegeven worden door een (blind) vertrouwen in een centrale (virtuele) organisatie of een PKI. Veel identiteitsfederaties gebruiken bijvoorbeeld een eigen CA als vertrouwensbasis voor een PKI. Het koppelen van federaties betekent dus ook dat de CAs gekoppeld moeten worden. Dit vereist een overkoepelende CA wat weer lastig is. Merk op dat voor confederaties ook weer de drie vertrouwensmodellen uit sectie 2.3 opgaan. De confederatie kan bestaan uit federaties die met elkaar bilaterale afspraken gemaakt hebben, die kiezen voor een betrouwbare centrale broker die zorgt voor de ‘vertrouwenslijm’, of die kiezen voor een domeinspecifieke oplossing. Waarbij weer gezegd kan worden dat de laatste twee modellen het beste schalen vanuit vertrouwensperspectief. Omdat een confederatie (zoals eduGAIN) typisch federaties uit verschillende landen herbergt, zal internationale wetgeving van toepassing zijn op het gebruik van identiteitsinformatie. Hier dient rekening gehouden te worden, bijvoorbeeld in het gebruik van identifiers door IdPs en SPs (landen als Duitsland en Oostenrijk accepteren geen persistente identifiers) en het verdere gebruik van de data door SPs (vooral als SPs uit de V.S. participeren). Ook zullen IdPs en SPs in een federatie op de hoogte willen zijn van eventuele confederatieverbanden. Voor IdPs betekent het dat ze identiteitsgegevens doorsturen naar SPs uit een andere federatie en potentieel een ander domein waar ze misschien geen band mee hebben. Voor SPs betekent het dat ze moeten vertrouwen op de gegevens verstrekt door een IdP uit een andere federatie en mogelijk uit een ander domein. Het is dan niet geheel onbegrijpelijk dat beide partijen enige aarzeling zullen hebben voor participatie in een confederatie. Ze zullen in staat gesteld moeten worden om te kiezen tussen wel of niet participeren in de confederatie. De hieruit voortvloeiende complexiteit van SPs en IdPs die soms wel en soms niet meedoen in de confederatie kan voor de nodige overhead zorgen en lijkt erg foutgevoelig en weinig schaalbaar. Transparantie is dus een vereiste in een confederatie.

Schaalt dat?

25

3.3.1

Evaluatie

Het confederatie model is een aantrekkelijke aanpak voor het opschalen van de federatie. In plaats van te streven naar één grote federatie lijkt het koppelen van verschillende kleinere federaties (in het zelfde domein) een betere keuze. Het is belangrijk dat iedereen in de confederatie hiërarchie weet heeft van zijn positie. Dit geldt niet alleen voor de federaties, maar ook voor de SPs en IdPs die daaronder hangen. Cruciaal hierbij is dat alle federaties in de confederatie om weten te gaan met elkaars metadata. Dan pas wordt optimaal gebruik gemaakt van de schaalbaarheid van het confederatiemodel. Hoe de metadata te managen is nog onzeker. Een centrale metadata dienst lijkt voor de hand te liggen, maar dit impliceert een centrale partij die deze beheert, en het is vaak onduidelijk wie deze partij zou moeten zijn. Een goed uitgangspunt is in ieder geval om de centrale dienst zo ‘dun’ mogelijk te houden. Een meer decentraal model biedt de mogelijkheid voor partijen om zelf hun metadata te managen. Het vinden van de metadata is een uitdaging. Bovendien moeten partijen de gevonden metadata wel kunnen vertrouwen. De focus in eduGAIN ligt met name op de techniek, er is weinig aandacht voor de organisatorische kant van het confedereren. Naast het verzamelen van alle federatie metadata zullen ook de (privacy) policies zoals die binnen de verschillende federaties aanwezig zijn op elkaar afgestemd moeten worden. Het inzetten van zogenaamde identiteitsmanagement federatie policies en best practices zoals beschreven in sectie 4.3 kunnen hierbij helpen. Ook kan het Liberty Alliance Identity Governance Framework een uitkomst bieden (zie sectie 3.7). Zie de beide betreffende secties voor meer tekst en uitleg. Daarnaast spelen bij het federeren van federaties uit verschillende landen ook juridische kwesties. Wetgeving betreffende het uitwisselen van identiteitsinformatie zal in ogenschouw genomen dienen te worden. Het gebruik van het Nederlandse BSN over staatsgrenzen heen is bijvoorbeeld niet toegestaan. Wetgeving biedt hier aan de ene kant dus de eindgebruiker een zekere privacy doordat er beperkte mogelijkheden zijn voor het communiceren van identiteitsinformatie, maar aan de andere kant belemmert het de opschaling van federaties via confederatie.

3.4

Reputatiemanagement

Reputatiemanagement omvat het proces van het traceren en rapporteren van iemands acties en de reacties van anderen hierop om vervolgens hierop weer te kunnen reageren zodat er een feedback loop ontstaat. De oplossing van Ebay waar kopers en verkopers elkaar positieve of negatieve feedback kunnen geven is hiervan een voorbeeld. In dit geval betreft het mensen maar het kan natuurlijk net zo goed een SP of IdP zijn waarover beoordeeld wordt. Het traceren en rapporteren kan in de vorm van statistische analyses van duizenden datapunten of met een paar woorden gebeuren. In plaats van het opbouwen van een complete vertrouwensinfrastructuur kan dus ook vertrouwd worden op een reputatieschema: je doet alleen zaken met mensen of partijen met een bepaalde reputatie.

26


Reputatiemanagementoplossingen worden steeds belangrijker voor het inschatten van de betrouwbaarheid van een persoon of partij die actief is in de online wereld. Een Washington Post voorpagina artikel over het onderwerp getuigt hiervan [ 30]. Reputaties zijn over het algemeen toepasbaar op personen, organisaties of communities. Zo’n reputatie kan echt, bevooroordeeld, ambivalent of totaal onwaar zijn. En hier zit vaak het probleem van reputatiemanagementoplossingen: hoe betrouwbaar zijn die reputaties? Om enige zekerheid te krijgen maken reputatiemanagementsystemen vaak gebruik van verschillende vooraf gedefinieerde criteria voor het opmaken van een reputatie. Hier zit echter de complexiteit van het begrip vertrouwen dwars: welke criteria zijn belangrijk en hoe kom je tot betrouwbare uitspraken betreffende die criteria? De context kan hierin ook een belangrijke rol spelen: vaak is het belangrijk te weten wie bijvoorbeeld feedback geeft [ 31, 32].

Figuur 11: Reputatiemanagement: realiteit of fictie?

3.4.1

Evaluatie

Al met al is het uitrollen van een infrastructuur voor reputatiemanagement niet eenvoudig. Omdat een globale aanpak in eerste instantie niet haalbaar zal zijn, zal er op federatieniveau begonnen moeten worden. De reputaties zullen op een betrouwbare en gestructureerde manier in kaart gebracht moeten worden waarbij er een afhankelijkheid is van de partijen om feedback te geven. In een relatief gesloten identiteitsfederatie waarbinnen alle partijen elkaar min of meer kennen kan het geven van feedback politiek gevoelig liggen. Het toelaten van nieuwe partijen tot de federatie betekent ook dat zij de mogelijkheid moeten krijgen om feedback te geven op het gedrag van andere partijen. Het managen van de rechten hiervoor betekent een extra, centrale functionaliteit voor de federatie en druist feitelijk in tegen het lichter en eenvoudiger maken ervan. Partijen die in meerdere federaties vertegenwoordigd zijn lopen het risico dat zij feedback moeten geven en krijgen volgens verschillende profielen. Vanuit het oogpunt van schaalbaarheid gaat dit dus niet werken. Alleen in een kleine gesloten federatie kan een reputatiemanagementsysteem werken maar is de toegevoegde waarde vanuit vertrouwensperspectief minimaal.

Schaalt dat?

27

3.5

Identiteitszekerheid

Hoe zeker is men dat men daadwerkelijk te maken heeft met de persoon die hij zegt dat hij is? Een SP wil graag enige zekerheid over de juistheid van de identiteit van de persoon waarmee hij zaken wil doen. De mate van zekerheid kan voor een SP bepalend zijn om de eindgebruiker al dan niet toegang te verlenen tot een dienst en de daaraan gerelateerde privileges vast te stellen. Op deze manier wordt bovenop de bestaande vertrouwensrelatie tussen de SP en IdP en extra informatie aangeleverd door de IdP om het voor de SP mogelijk te maken een inschatting te kunnen maken betreffende de rechten van een eindgebruiker zonder dat dit contractueel vastgelegd hoeft te worden. Twee belangrijke aspecten liggen aan dit vertrouwen ten grondslag: de kwaliteit van de eindgebruikersauthenticatie en de betrouwbaarheid van de partijen die iets over de eindgebruiker zeggen (IdPs en attribuut SPs). Het eerste aspect geeft aan hoe goed de identiteit van de eindgebruiker geverifieerd is. Met andere woorden, welke technische en organisatorische middelen zijn in ogenschouw genomen om er zo zeker mogelijk van te zijn dat men met de juiste persoon te maken heeft? Het tweede aspect geeft aan welke waarde gehecht moet worden aan een authenticatiebewering van een bepaalde IdP of aan een attribuut van een bepaalde AP. Met andere woorden, is de IdP of AP geautoriseerd om iets over de persoon in kwestie te zeggen? Een manier om dit op te lossen is gebruik te maken van zogenaamde Levels of Assurance (LoAs). Een andere manier is om gericht te kijken naar de betrouwbaarheid van de IdPs of APs. Beide manieren zullen hieronder verder toegelicht worden.

3.5.1

Levels of Assurance

De term Level of Assurance (LoA) is een kwaliteitsmaat voor de authenticatie van de eindgebruiker [ 33]. Deze maat hangt sterk of van de kwaliteit van de uitgifte van persoonlijke identifiers en de technische middelen die gebruikt worden om te controleren of deze identifiers ook daadwerkelijk horen bij een persoon. Omdat er bijvoorbeeld meerdere manieren zijn om iemand te authenticeren (gebruikersnaam/wachtwoord, tokens, smartcards), en de ene manier wat beter is dan de andere vormt een LoA een maat hiervoor (laag voor gebruikersnaam/wachtwoord en hoog voor smartcards). Naast het standaardiseren van niveaus voor authenticatie dient ook rekening gehouden te worden met juridische kaders betreffende het uitwisselen van persoonsgegevens en/of identifiers [ 34]. Het Liberty Alliance consortium heeft onlangs een Identity Assurance Framework opgesteld voor federatief identiteitsmanagement. 3.5.1.1 Liberty Alliance Identity Assurance De binnen Liberty Alliance opgerichte Identity Assurance Expert Group (IAEG) heeft als doel om de adoptie van identiteitsvertrouwensdiensten te faciliteren. [ 35]. De IAEG heeft daarom het Liberty Alliance Identity Assurance Framework (IAF) opgesteld dat IdPs en SPs de mogelijkheid geeft om op een gestandaardiseerde manier over de betrouwbaarheid van eindgebruikeridentiteiten te communiceren. Het IAF specificeert daartoe de verificatie en bewijsvorming van persoonlijke gegevens, de manier waarop IdPs hun diensten moeten aanbieden en hoe gecontroleerd kan worden of IdPs opereren conform de door hun verkondigde LoAs [ 36].

28


3.5.1.2 NIST Het Amerikaanse National Institute for Standards and Technology (NIST) heeft in 2007 een uitgebreid raamwerk gedefinieerd voor het classificeren van het identificatie- en authenticatieproces in termen van niveaus. Vier niveaus zijn gedefinieerd variërend van laag (1) naar hoog (4). Op basis van een grondige risicoanalyse zijn de eisen vastgesteld waaraan een identificatie/authenticatie oplossing moet voldoen om tot een zeker niveau geclassificeerd te worden. Voor meer informatie over het NIST raamwerk verwijzen we naar de handleiding [ 37]. 3.5.1.3 LoA in identiteitsfederaties Het Engelse JISC heeft onlangs een onderzoek gepubliceerd naar de behoefte en het gebruik van LoA in identiteitsfederaties [ 38]. Uit het onderzoek blijkt dat het NIST raamwerk het meest gebruikt wordt. Bijvoorbeeld de InCommon federatie heeft op basis van NIST LoA een confederatieproject uitgevoerd met de National Institutes of Health federatie. Ongeveer 70% van de ondervraagde SPs zijn van mening dat waardevolle/gevoelige informatie door middel van een sterkere vorm van authenticatie/identificatie ontsloten moet worden. Echter, 67% van de IdPs voldoen momenteel niet aan de eisen voor NIST niveau 2. Verder bleek uit het onderzoek dat er een waarneembare noodzaak was voor LoA maar dat er weinig vertrouwen was in de haalbaarheid ervan. Verschillende andere identiteitsfederaties hebben zich afgevraagd of ze zich in moeten laten met LoA. De Australische Access Federatie (AAF) stelt voor om een 4-niveau LoA raamwerk te implementeren waarbij de leden vrij zijn om hun eigen LoA te kiezen [ 39]. Het laagste niveau wordt het zogenaamde “Floor of trust” genoemd; er moet een bepaald minimum niveau van vertrouwen zijn in de federatie. Motivaties voor LoA zijn het makkelijker kunnen toetreden van nieuwe leden als zij voldoen aan de “Floor of trust” en het mogelijk maken van een fijnmazigere toegangscontrole tot (gevoelige) gegevens en diensten. InCommon heeft haar Identity Assurance Profiles [ 40] dat spreekt in termen van bronzen en zilveren niveaus van zekerheid. Als gezegd, dit raamwerk is getest in samenwerking met de National Institutes of Health federatie. Tot slot heeft het Zwitserse SWITCHaai een federatie LoA pilot uitgevoerd welke beschreven staat in [ 41]. Ook in Zwitserland is gekozen voor een 4-niveau aanpak (brons, zilver, goud, platina). Hierbij wordt rekening gehouden met de registratieprocedure, het al dan niet fysiek aanwezig zijn bij het verkrijgen van een identiteit, het uitgifteproces van de identiteiten, de kwaliteit van de online authenticatie, de levensduur van een geauthenticeerde sessie en de geldigheidstermijn van de identiteitsgegevens. Het is onduidelijk wat de uitkomst van de pilot is geweest.

Schaalt dat?

29

3.5.2

MyID.is Certified

MyID.is Certified is een initiatief om gebruikers IDs te certificeren via een creditcard betaalconstructie [ 42]. De gebruiker wordt gevraagd om een willekeurig bedrag tussen 2 en 5 dollar dat door MyID.is Certified in rekening is gebracht te betalen en het bedrag op de website van MyID.is Certified door te geven. Op deze manier kan MyID.is Certified de identiteit van de gebruiker verifiëren. Vervolgens treedt MyID.is Certified op als TTP richting SPs. Hiervoor is MyID.is Certified ook een gecertificeerde OpenID provider. In de Nederlandse variant worden gebruikers gevraagd om 1 cent over te maken via iDeal. Het gebruiken van de betrouwbaarheid van banken/betaalsystemen om iemands digitale identiteit te binden aan een fysieke identiteit en daarmee een bepaalde mate van zekerheid te creëren is een interessante oplossing.

3.5.3

Evaluatie

Dat het belangrijk is op het internet om te kunnen vertrouwen op de correctheid van iemands identiteit is onomstotelijk. De vraag is of het bijdraagt aan de schaalbaarheid van het vertrouwen in de federatie. Immers, de SP zal nog steeds de IdP moeten vertrouwen dat deze niet liegt over de manier waarop de eindgebruiker is geauthenticeerd. Feitelijk wordt het niveau van authenticatie door de SP slechts als attribuut gebruikt bij de autorisatie van de eindgebruiker. In die zin dragen LoAs dus niet bij tot het schaalbaar maken van vertrouwen in de federatie. Daar komt bij dat veel LoA oplossingen focusseren op het bewijzen en verifiëren van iemands identiteit en dat de kwaliteit van de bijbehorende attributen niet of nauwelijks in ogenschouw genomen wordt. Terwijl attributen essentieel zijn voor het bepalen van de toegangsrechten. De status van een IdP helpt SPs over de streep te krijgen om op een gefedereerde manier zaken te doen met eindgebruikers. De aanwezigheid van betrouwbare IdPs kan dus helpen om de federatie te doen groeien. Deze IdPs zullen wel zekerheid willen hebben dat de SPs op een betrouwbare manier omgaan met de identiteitsgegevens. De federatie moet deze zekerheid geven anders zullen ze niet zo snel toetreden.

3.6

Outsourcing

Naarmate een federatie steeds groter wordt zal het technisch gezien wel mee vallen om alle partijen aangesloten te krijgen en datatransformaties te doen. Echter het managen en monitoren van alle connecties wordt steeds ingewikkelder en tijd/arbeidsintensiever waardoor de kosten stijgen en de kans op fouten toeneemt. Daarnaast worden aspecten als robuustheid en beschikbaarheid van de infrastructuur steeds belangrijker. Aspecten die niet altijd behoren tot de kerncompetenties en vaardigheden van elke bedrijf. Hierdoor wordt uitbesteden van identiteitsmanagement een interessante optie. Ook voor SURFnet valt dit te overwegen. Er zijn nog een paar minder voor de hand liggende aspecten van gefedereerde identiteitsmanagement die deze keuze ook kunnen beïnvloeden:

30


◊

In een federatie met veel verschillende partijen moet ook omgegaan kunnen worden met een verscheidenheid aan beveiligingsoplossingen. Hoe wordt gecontroleerd of deze oplossingen wel voldoende veilig zijn; een federatie is immers zo sterk als de zwakste schakel. Een groeiende federatie moet voorzien in degelijke auditfunctionaliteiten en protocollen. Maar audits vereisen speciale kennis en vaardigheden die niet iedereen in huis heeft.

◊

Verder blijkt in de praktijk steeds weer dat er geen gevestigde methodes zijn voor het afhandelen van de contractuele, juridische kant van een identiteitsfederatie. Het onderhandelen over vertrouwensrelaties in een federatiecontract is niet iets waar veel partijen zich thuis in voelen; bedrijfsjuristen weten vaak niet goed hoe ze dit moeten aanpakken. Misschien dat uitbesteden ervan een optie is?

Een goed voorbeeld van een partij die dit soort zaken uit handen neemt is Covisint (zie sectie 2.4.4).

3.6.1

Evaluatie

SURFnet zal eenzelfde pad als Covisint kunnen volgen of zal kunnen opteren om het uit te besteden. De eerste optie behelst het aanpakken van de bovengenoemde aspecten. SURFnet zal dan ook een Identity as a Service (IaaS) provider moeten worden. Daarnaast zal de bedrijfsjurist in staat moeten zijn om de contractuele kant zo efficiënt en degelijk mogelijk in te richten zodat nieuwe IdPs en SPs via standaardcontracten kunnen worden aangesloten. Kiest SURFnet voor de tweede optie dan rijst de vraag aan wie de SURFfederatie uitbesteed kan worden. Het probleem van het schaalbaar maken van vertrouwen verschuift dan naar de partij waaraan het management van de SURFfederatiedienst uitbesteedt wordt. En er zijn niet zo heel veel partijen die dit kunnen doen en die een zekere mate van vertrouwen genieten.

3.7

Governance

Een deugdelijk bestuur van een federatie is een belangrijke voorwaarde voor vertrouwen. Binnen het Liberty Alliance consortium wordt momenteel hard nagedacht en gewerkt aan een raamwerk dat het vanuit bestuurlijk perspectief eenvoudiger maakt om identiteitsinformatie te delen in een federatie.

3.7.1

Liberty Alliance IGF

Het Liberty Alliance samenwerkingsverband werkt momenteel aan een raamwerk aan de hand waarvan partijen identiteitsgegevens kunnen delen en beschermen. Het bestaat uit protocollen en richtlijnen om identiteiten te kunnen delen, onder meer voor webservices. Dit zogenaamde Identity Governance Framework (IGF) helpt partijen richtlijnen op te stellen zodat kan worden voldaan aan wetgeving zoals het European Data Protection Initiative en Sarbanes-Oxley. Het IGF is feitelijk een XML-schema waarmee regels kunnen worden gevormd betreffende het gebruik van identiteitsgegevens [ 43, 44]. In het schema kan bijvoorbeeld worden bepaald dat een applicatie bepaalde persoonlijke gegevens na 24 uur moet wissen wanneer deze niet langer nodig zijn. Het geeft partijen dus meer handhavingsmogelijkheden bij het gebruik van die privacygevoelige gegevens door beter te kunnen regelen wie, welk bedrijf, of welke applicatie de gegevens mag inzien of gebruiken.

Schaalt dat?

31

Het raamwerk borduurt voort op identiteitsstandaarden als SAML en WS-*. Waar deze echter vooral betrekking hebben op het vaststellen en ‘doorgeven’ van iemands identiteit (veelal op websites), maakt IGF het vastleggen van regels mogelijk voor wat er met die identiteitsgegevens gedaan kan worden (veelal op de systemen achter die websites). IGF biedt een raamwerk om dit op een gestandaardiseerde manier te doen zodat partijen die identiteitsgegevens met elkaar uitwisselen op een efficiënte manier tot consensus en duidelijkheid kunnen komen. Het IGF biedt daarvoor een beheermodel waarin partijen ‘contractueel’ afspreken welke informatie op welke wijze uitgewisseld wordt binnen een organisatie of naar derden. Dergelijke contracten kunnen in een speciale XML-gebaseerde taal, de Client Attribute Requirements Markup Language (CARML), gespecificeerd worden [ 45]. Daarnaast wordt gewerkt aan een programmeerinterface (CARML API) voor de uitwisseling van deze contractgegevens, een Attribute Authority Policy Markup Language (AAPML) om regels met betrekking tot het gebruik van persoonsgegevens vast te leggen [ 46], en een Identity Service voor het vaststellen van de rechten van de opvrager. AAPML sluit nauw aan bij de eXtensible Access Control Markup Language (XACML, AAPML is een XACML profile). Onderstaande Figuur 13 geeft aan waar CARML en AAPML gepositioneerd kunnen worden in een identiteitsmanagement architectuur.

.NET

Java API

Applications

Client Apps

Applications

AAPML : AAPMLUse : Attribute AAPMLUse : Attribute Policy Attribute Use Policy Policy Authority1 End-User(s)

Applications

View A

Identity Policy Engine

Delivery/Gateway/ Enforcement

API

API

Existing Applications

Optional: LDAP, legacy protocols WS-Trust STS

Query Protocol SAML / ID-WSF /SPML

CARML : CARML : Attribute CARML : Attribute Requirements CARML : Attribute Requirements Attribute Requirements Requirements

Identity Sources

Perl

View B

Admins reconcile sources and policies with client CARML requirements to create “views”

Identity Service

LDAP, ODBC, SAML Query, SAML Assertions, …

Authority2 External Partners

Authority3 HR Systems

Legend Run-Time Interactions Admin Deploy Time Interactions Admin Deploy & Run-Time Interactions

Authority4 Departmental Systems

Authority5 Enterprise Directory

Standard Components Existing or non-specified

Figuur 12: Voorbeeld architectuur voor het toepassen van CARML en AAPML.

Bijkomend voordeel van het gebruik van IGF is dat het voor auditors een stuk makkelijker wordt om na te gaan of aan de policies voldaan wordt, de policies zijn immers al gedefinieerd.

32


3.7.2

Evaluatie

De focus van het IGF ligt vooral op het goed kunnen managen van identiteitsinformatie binnen een partij: welke applicatie mag bij welke database om welke gegevens in te zien? Mogelijkerwijs is het IGF ook toepasbaar op het niveau van federaties en zelfs tussen federaties. CARML kan dan door partijen gebruikt worden om aan te geven welke informatie ze nodig hebben en hoe ze daar mee omgaan (en vormt hierbij eigenlijk een tegenhanger van user-centric identiteitsmanagement) waardoor de verstrekkers van identiteitsinformatie de benodigde informatie krijgen om een vertrouwensbeslissing te nemen. AAPML kan vermoedelijk relatief eenvoudig ingezet worden op federatieniveau om aan partijen binnen de federatie aan te geven wat de policy is voor het verkrijgen en verwerken van identiteitsinformatie en kan zelfs helpen bij het afstemmen van inter-federatie verbanden.

3.8

Samenvatting

Verschillende organisatorische oplossingen die een bijdrage kunnen leveren aan het schaalbaar maken van vertrouwen in de SURFfederatie zijn gepresenteerd. Echter, veel van deze oplossingen zijn het ‘net niet’ omdat er teveel haken en ogen aan zitten (zoals reputatiemanagement), te nieuw zijn (confederaties) of gewoon niet realistisch zijn (zoals outsourcen). Belangrijk is te realiseren dat er meerdere partijen actief zijn in een federatie en dat er gecommuniceerd moet worden met deze partijen om tot vertrouwensrelaties te komen. Het maken van heldere afspraken en het bieden van transparantie en controle zijn hierbij essentiële elementen (op respectievelijk juridisch en organisatorisch vlak) in het creëren en schaalbaar maken van vertrouwen. Opvallend is dat in veel van deze elementen een sterke technologische inslag aanwezig is om daadwerkelijk het organisatorische vertrouwen te borgen en te doen schalen. In het volgende hoofdstuk gaan we daarom verder in op potentiële technologische oplossingsrichtingen die hiervoor kunnen zorgen.

Schaalt dat?

33

4 Technische oplossingsrichtingen Dit hoofdstuk evalueert een aantal technische oplossingsrichtingen voor vertrouwen in identiteitsfederaties en hun schaalbaarheid. De volgende oplossingsrichtingen zullen aan bod komen: ◊


◊


◊

PKI

We beginnen met metadata uitwisseling.

4.1


Vertrouwen wordt voor een groot deel gebaseerd op informatie. Hoe meer de partijen in een identiteitsfederatie van elkaar weten des te beter kan er een vertrouwensinschatting gemaakt worden betreffende het al dan niet aangaan van een transactie. In die zin vormt de informatie die de partijen beschrijft een belangrijke steunpilaar voor het verkrijgen van vertrouwen in een federatie. Dit soort informatie wordt ook wel metadata genoemd. De metadata specificeert o.a. de leden in de federatie in termen van locatie, naam, kwaliteiten, certificaten, token types, etc. Vaak wordt hiervoor het SAML2.0 Metadata formaat gebruikt [8]. De certificaten in de metadata bieden op verschillende manier handvatten voor vertrouwen. Ten eerste geven ze vertrouwen betreffende de identiteiten van de partijen in de federatie. Ten tweede zegt de status van de uitgevende instantie van het certificaat, de CA, iets over de betrouwbaarheid van de in het certificaat vermelde identiteit. Tot slot bevatten ze de sleutels voor het veilig opzetten van verbindingen voor het communiceren van identiteitsinformatie. Omdat de federatie metadata certificaten bevat die gebonden zijn aan de partners in de federatie is het belangrijk dat ze regelmatig geüpdate wordt. In de Zwitserse SWITCHaai federatie gebeurt dit bijvoorbeeld dagelijks. Bij het werken met metadata spelen twee vertrouwenskwesties een rol: vertrouwen hebben in de metadata zelf en vertrouwen hebben in de partij waarop de metadata betrekking heeft. Voor het eerste geval kan het vertrouwen verkregen worden uit de handtekening van de DNS zone waarvan, op basis van een metadatalocatie URL, de metadata betrokken is. Hiermee wordt de correcte locatie van de metadata verzekerd. Dit vereist wel het gebruik van de security extensions van DNS. Verder biedt de SSL/TLS server authenticatie voor het opzetten van een veilige verbinding voor het verkrijgen van de metadata zekerheid over de identiteit van de partij die de metadata publiceert. Als metadata gecached wordt kan hierop niet meer vertrouwd worden. Voor het tweede geval kan vertrouwen afgeleid worden uit het verwerken van de handtekening onder metadata ter controle van de integriteit ervan. Er zijn verschillende manieren om vertrouwen in de handtekeningen onder de metadata te verkrijgen:

34


◊

Gebaseerd op certificaten die gebruikt worden voor het ondertekenen in combinatie met een PKI.

◊

Door middel van out-of-band certificaten die gebruikt worden als vooraf uitgewisselde en gedeelde sleutels voor het valideren van handtekeningen.

Beide manieren brengen certificaat- of sleutelmanagementproblemen met zich mee: hoe zorg je ervoor dat iedereen de juiste certificaten en sleutels heeft? De huidige oplossing hiervoor is om ze op te nemen in de metadata zelf. In de SAML2.0 Metadata Extensie staat beschreven hoe een lijst met betrouwbare root Certificaat Authorities (CAs, de zogenaamde Trust Anchors) in de metadata meegenomen kan worden [ 47]. Feitelijk wordt het certificaat distributieprobleem dus opgelost via de distributie van de metadata. Daarnaast wordt het vertrouwen in de metadata belangrijker en dus ook een betrouwbare uitwisseling ervan. Het uitwisselen van metadata in een federatie kan op verschillende manieren gebeuren: ◊

Via een centrale of decentrale oplossing.

◊

Out-of-band of in-band ofwel buiten de daadwerkelijke identiteitscommunicatie om of tijdens het uitwisselen van identiteitsgegevens.

4.1.1

Centraal/decentraal

Er zijn twee manieren om metadata in een federatie te publiceren: iedere partner publiceert het zelf of via een geaggregeerde file vanaf een centrale locatie. Het laatste model wordt gehanteerd in de meeste federaties. Met metadata aggregatie kunnen op een relatief eenvoudige manier alle partners op de hoogte gebracht worden omdat de file beschikbaar wordt gesteld via een voorgeconfigureerde bekende locatie (URL). Het vertrouwensmodel is relatief simpel: de federatiemetadata is ondertekend door uitgevende instantie, de aggregator, die typisch de rol van TTP speelt in de federatie. De distributie vanaf een centrale locatie kan op verschillende manieren gedaan worden: ◊

Push vanuit een centrale autoriteit: Een centrale autoriteit (zoals een hub of IdP) verzend de geautoriseerde metadata naar alle leden binnen de federatie. Dit kan gedaan worden door middel van LDAP replicatie, het synchroniseren van de flat files met daarin de metadata in XML formaat (zoals bijvoorbeeld gestandaardiseerd in OASIS SSTC [ 48]), of een andere vorm van synchronisatie.

◊

Pull vanuit een centrale autoriteit: Dit komt overeen met het hierboven beschreven pushmodel. Belangrijk is hier dat database backend standaardisatie vereist is.

◊

Door gebruik te maken van een zogenaamde Well-Known-Location (WKL) zoals beschreven in sectie 4.1 van de “Metadata for SAML” specificatie van OASIS in combinatie met een PKI [8]. Door de metadata via een PKI uit te wisselen kan het benodigde vertrouwen verkregen worden. Feitelijk wordt de vertrouwenskwestie in de federatie verschoven naar dat van een PKI.

Schaalt dat?

35

◊

Door een WKL te combineren met een centrale autoriteit die een lijst van betrouwbare IdPs distribueert (push of pull). De WKL wordt gebruikt voor het verkrijgen van metadata en de centrale autoriteit om te kijken welke IdPs te vertrouwen zijn. Het voordeel van deze aanpak is dat de lijst van betrouwbare IdPs in het algemeen kort en daardoor eenvoudig te verwerken is. Voor dit laatste zou de lijst idealiter gestandaardiseerd moeten worden. Het nadeel van deze aanpak is dat de WKL aanpak lang niet door alle productleveranciers ondersteund wordt.

◊

Door gebruik te maken van een WKL voor metadata en OCSP voor het borgen van het vertrouwen (centraal, zie [ 49]).

◊

SWITCHaai maakt gebruik van de centrale zogenaamde Resource Registry voor het opstellen van de federatie metadata. Deze metadata bevat alle SPs en IdPs in de federatie en de attribute release policies (ARPs) van de IdPs. Administrators hebben toegang tot de Resource Registry om metadata en policies te veranderen.

Het nadeel van een centrale metadata locatie is dat deze een aantrekkelijk doelwit vormt en daardoor gevoelig is voor Denial of Service aanvallen. Bovendien vormt het een bottleneck in de communicatie binnen de (con)federatie. De decentrale variant van metadata uitwisseling komt minder vaak voor. Feide is hier bijvoorbeeld mee aan het experimenteren (zie sectie 2.4.2). Desalniettemin is dit model onderliggend aan de SAML Metadata specificatie [8]. Het voordeel van een gedistribueerde uitwisseling is dat het meer flexibiliteit biedt in het opbouwen van relaties tussen individuele partijen. In dit model is elke partij verantwoordelijk voor het onderhouden en publiceren van zijn eigen metadata (in de vorm van een EntityDescriptor document). De locatie van de metadata kan afgeleid worden van het EntityID. SAML stelt de volgende twee methodes voor om dit te doen: ◊

Door gebruik te maken van URLs als EntityIDs. De URL verwijst dan naar de locatie van de metadata (well-known-location).

◊

Door de metadata URL te achterhalen op grond van het EntityID (host part) door middel van het Dynamic Delegation Discovery System (DDDS) [ 50].

Het decentrale ofwel gedistribueerde model heeft grote voordelen ten opzichte van het centrale model voor metadata publicatie. De metadata van een bepaalde partij kan op elk moment op aanvraag verkregen worden zonder dat er periodiek een grote geaggregeerde datafile hoeft te worden gedownload. Deze grote file bevat tal van beschrijvingen van partners die in veel gevallen nooit benaderd zullen worden. Het dynamische karakter van het gedistribueerde model staat veel makkelijker toe dat partijen op peer-to-peer en adhoc basis met elkaar kunnen vinden en samenwerken. Hierdoor wordt het toch enigszins gesloten karakter van een federatie opengebroken. Het nadeel van het gedistribueerde model is dat het opbouwen en in stand houden van een vertrouwensmodel stukken complexer is. Waar in het centrale model vertrouwd kan worden op een TTP die de metadata ondertekend, kan dit niet meer in het gedistribueerde model. Het ondertekenen van de metadata met de eigen private key heeft geen meerwaarde in termen van vertrouwen. Dus ook hier zal ergens een centrale, vertrouwde partij moeten zijn die een handtekening kan zetten onder de metadata van de federatiepartners waardoor veel van de voordelen van het gedistribueerde model teniet worden gedaan.

36


Het is belangrijk op te merken dat de SAML metadata specificatie niets zegt over het intrekken (revoken) van de metadatafile zelf. Er worden bijvoorbeeld geen middelen, zoals een tijdstip van ondertekenen of een volgnummer, gedefinieerd die bepalen wat de leeftijd van de metadata is. Hierdoor is het lastig onderscheidt te maken tussen verschillende versies. Wel kan de “validity” van een metadata element of de “cacheduration”gespecificeerd worden. Daarnaast zal de update frequentie van metadata relatief snel moeten zijn om te voorkomen dat ongewenste partijen te lang actief kunnen blijven binnen de federatie en daardoor het hele vertrouwen in de federatie gaan ondermijnen.

4.1.2

Out of band/in band

In de bovengenoemde voorbeelden is de koppeling van metadata distributie en vertrouwen losgekoppeld (out of band). Dynamic SAML communiceert metadata on the fly tijdens het uitwisselen van identiteitsgegevens (in band) [ 51]. Op deze manier wordt op een veel dynamischere wijze vertrouwen gecreëerd zonder hiervoor een centrale entiteit te hoeven inrichten. Laten we Dynamic SAML eens wat nader bekijken. 4.1.2.1 Dynamic SAML / Auto-Connect Ondanks dat SAML veel flexibiliteit en mogelijkheden biedt voor gefedereerd identiteitsmanagement worden ontwikkelaars nog regelmatig geconfronteerd met technische beperkingen: ◊

◊

Partners moeten onderhandelen over welke van de vele SAML opties te gebruiken o

Meerdere profiles & bindings

o

Meerdere identifier opties

o

Flexibele attributen

o

Hoe te koppelen met autorisatie

De IdP Selectie/Discovery is nauwelijks gedefinieerd o

Vooral voor SPs die nog geen gebruik van SP geïnitieerde SSO is het lastig om op een gebruikersvriendelijke manier de IdP van de gebruiker te achterhalen. SAML geeft hiervoor geen standaard oplossing. Er is een cookie gebaseerde oplossing die verre van optimaal is en waarvan nauwelijks gebruik wordt gemaakt. Een andere suboptimale maar vaker geïmplementeerde oplossing is dat de SP een voorgeconfigureerd dropdown menu toont van alle mogelijke IdPs. De eindgebruiker kan dan de zijne selecteren. Shibboleth maakt gebruik van deze oplossing. Voor SAAS/BPO providers is deze oplossing echter minder interessant omdat informatie zo kan weglekken naar andere providers.

◊

Partners maken nu vooral gebruik van out-of-band mechanismes om SAML configuratiedata uit te wisselen wat veel handmatige configuratie voor iedere connectie inhoud.

◊

Certificaatmanagement is problematisch

Schaalt dat?

37

o

Vertrouwen wordt gecreëerd door handmatig uitwisselen van certificaten. Partners die gebruik maken van SAML moeten statische vertrouwensrelaties opbouwen op basis van deze certificaten. Elke partij moet een lijst van partner certificaten bijhouden, een zogenaamde trust anchor list (TAL). Een SP accepteert alleen een SAML bewering van een IdP als de handtekening eronder gevalideerd kan worden met een certificaat dat in de TAL staat. In dynamische en sterk groeiende identiteitsfederaties is het op deze manier managen van vertrouwen niet efficiënt.

Het introduceren van een hub in de federatie kan helpen om het toetreden van partners in de federatie te versimpelen. Als TTP hoeven de SPs alleen maar de digitale handtekening van de hub te vertrouwen en niet van alle individuele IdPs in de federatie. Het nadeel van deze aanpak is dat een dergelijke hub opgezet moet worden wat extra kosten, inspanning en tijd met zich meebrengt. Verder blijkt uit de praktijk dat het hub-model het beste werkt in verticale ketens of gesloten domeinen waarin sprake is van een soort community vertrouwen (zie sectie 2.3). De huidige SURFfederatie is een goed voorbeeld van een hub-model. Dynamic SAML probeert een paar van de bovengenoemde technische horden te nemen. Met Dynamic SAML wordt configuratiedata op een geautomatiseerde en gedistribueerde manier uitgewisseld tussen de betrokken partijen. Dynamic SAML is dus een alternatieve oplossing voor een gecentraliseerde metadata repository. Dynamic SAML vereist geen veranderingen in de SAML specificatie en profiteert volledig van alle inherente veiligheid die SAML biedt. Figuur 14 geeft de Dynamic SAML berichtenstroom weer.

Figuur 13: Een voorbeeld van berichtenuitwisseling met Dynamic SAML. (1) De eindgebruiker (browser) probeert een dienst af te nemen van een SP. (2) De SP haalt een ondertekende metadata file op bij de IdP en controleert de handtekening. (3) De SP redirect de eindgebruiker naar de SSO URL van de IdP met daarbij een SAML AuthNRequest. (4) De IdP haalt een ondertekende metadata file op bij de SP en controleert de handtekening. (5) Vervolgens valideert de IdP het SAML AuthNRequest en (6) authenticeert de eindgebruiker. (7) De IdP maakt een SAML Assertion aan en redirect deze via de eindgebruiker terug naar de SP, die (8) op zijn beurt de SAML Assertion valideert en de eindgebruiker toegang verleent tot de dienst.

38


Dynamic SAML automatiseert SAML metadata document uitwisseling tussen federatiepartners zodat bijna instantaan en on the fly single sign-on (SSO) verbindingen gecreëerd kunnen worden. Voor het vinden van de metadata maakt Dynamic SAML gebruik van een optionele en domeingebaseerde naamgeving voor SAML EntityID URLs waarin de host name ‘saml’ voorafgaat aan de domeinnaam van de partner (domeinnaam.com → http://saml.domeinnaam.com). Een SAML EntityID is een identifier die op een unieke manier elke SAML IdP of SP in de federatie vertegenwoordigt. Daarnaast vertegenwoordigt het ook de waarde van het Issuer element in alle SAML SSO berichten. Bijvoorbeeld voor SP geïnitieerde SSO kan IdP discovery gebaseerd worden op het e-mail adres van de eindgebruiker. De eindgebruiker wordt bij het benaderen van een SP eenmaal gevraagd om zijn/haar e-mail adres in te toetsen waarmee de SP dan de IdP van de eindgebruiker kan benaderen. Door gebruik te maken van een cookie hoeft de eindgebruiker in de toekomst zijn e-mail adres niet meer op te geven. Het gebruik van EntityID URLs is eleganter dan andere bestaande discovery aanpakken zoals het Dynamic Delegation Discovery System (DDDS) via DNS of via eXtensible Resource Identifiers (XRIs) waardoor de drempel voor adoptie lager is. Dynamic SAML schrijft voor dat de certificaten die door de partijen in de federatie gebruikt worden voor het ondertekenen en valideren van de SAML berichten in de SAML metadata opgenomen zijn. Het vertrouwen in deze certificaten wordt afgeleid van het vertrouwen dat in de metadata zelf gesteld wordt. Dynamic SAML verandert dus het vertrouwensmanagement van een run-time knelpunt (toepasbaar op elk protocol bericht) naar een configuratieknelpunt (toepasbaar voor het complete metadata document). Om het metadata document te vertrouwen moet het ondertekend zijn met behulp van een certificaat. Elke partij in de federatie houdt een Trust Anchor List (TAL) bij waarin alle certificaten staan waarmee de handtekening en het certificaat in de metadata file gecontroleerd kunnen worden. Daarnaast wordt het sleuteldistributieprobleem (zoals we vaak in PKIs zien) in identiteitsfederaties opgelost via de metadata uitwisseling. Dit alles gebeurt natuurlijk wel onder het toeziend oog van de federatie administrator. Een alternatieve manier om vertrouwen toe te voegen aan Dynamic SAML is het gebruik van tokens in de EntityID URL. De federatie operator gebruikt dan zelf zijn private sleutel voor het ondertekenen van een EntityID URL (https://idp.novay.nl/saml/metadata.xml wordt dan abc12345). De resulterende URL verwijst dan naar de metadata en heeft een token in zich dat gebruikt kan worden om te controleren of de betreffende partij wel lid is van de federatie (https://idp.novay.nl/saml/metadata_abc12345_.xml). Hiervoor moet het de publieke sleutel van de federatie operator gebruiker. Zie [ 52] voor meer informatie over deze aanpak.

Schaalt dat?

39

4.1.3

Metadata tagging

Het taggen van metadata kan gebruikt worden om additionele, meer beschrijvende informatie in de metadata op te nemen. Het standaard SAML metadata schema staat dit toe. Het toevoegen van tags in de metadata wordt bijvoorbeeld al door de UK Access and Management Federation gedaan. Een voorbeeld van een metadata tag is het lidmaatschap van de federatie (<SURFfederatieMember>). Het nadeel van het gebruik van metadata tags op deze manier is dat iedereen ze kan toevoegen aan de metadata en dat alleen een handtekening over de metadata file vertrouwen geeft. Vooral als federaties willen gaan confedereren is een betere, schaalbare oplossing nodig. Verschillende partijen zijn hier momenteel mee aan het werk (SWITCH, UK, Shibboleth). De voorlopig voorgestelde oplossing betreft het toevoegen van SAML attributes of assertions als zogenaamde Entity Attributes in de vorm van een metadata extensie [ 53]. Deze SAML attributes of assertions zijn zelf weer digitaal ondertekend door de federatie operator of een TTP. Bijvoorbeeld de SURFfederatie geeft aan met een ondertekende assertion in een Entity Attribute dat een member IDP in overeenstemming met de privacy policy van de SURFfederatie opereert. Zelfs de levensduur van het ondertekende attribute of assertion kan op deze manier tot uitdrukking gebracht worden. Het grote voordeel van metadata tagging is dat er geen centrale metadata file meer geaggregeerd hoeft te worden waarin alle gegevens van elke federatie in een confederatie staan. Partijen uit verschillende federaties kunnen (als ze elkaar eenmaal gevonden hebben) op grond de metadata en de tags besluiten met elkaar te gaan communiceren. Om interoperabiliteit tussen deze partijen te creëren is het belangrijk dat er afspraken gemaakt worden over de tag types. Geschikte types voor tag kandidaten zullen vooral komen uit de federatie policies en wetgeving.

4.1.4

Licenties op metadata

Identiteitsmanagement specialist Leif Johansson opperde enige tijd geleden (oktober 2007) een licentiemodel voor federatie metadata [ 54]. In dit model kan metadata van de IdPs in een federatie door een SP gebruikt worden onder de voorwaarden die beschreven zijn in de licentie. De licentie reguleert hoe de SP de diensten van de IdPs in de federatie kan gebruiken. SPs kunnen zelf bepalen of ze wel of niet in de federatie participeren; als ze zich maar aan de licentievoorwaarden houden. Bijkomend effect is dat de metadata van de participerende SP, die ook door de SP zelf ondertekend zal zijn, geassocieerd wordt met de IdP metadata licentie. De SP zal echter voor het ondertekenen van zijn metadata een low-assurance (self signed) sleutel gebruiken. Mogelijk staan er partijen op die dit uit handen van de SPs gaan nemen, de metadata gaan aggregeren en er een betere handtekening onder gaan zetten. Het vertrouwen neemt hierdoor toe.

4.1.5

Automatische metadata down- en upload in MDS

Als onderdeel van dit project hebben we eduGAIN als case bekeken m.b.t. het management van confederatie metadata, en hoe dit te automatiseren vanuit de SURFfederatie.

40


eduGAIN experimenteert met een centralistische opslag voor metadata, ter ondersteuning van een confederatie van alle Europese NRENs. Deze centrale server heet MDS. Voor SURFnet betekent de participatie in eduGAIN nog heel veel handmatige verwerking van metadata. Deze moet handmatig en op maat gecreëerd worden door SURFnet en vervolgens geupload worden naar de MDS. Het gevolg is dat de metadata niet regelmatig geupdate wordt (is teveel werk) en dus voor de andere federaties in eduGAIN onbetrouwbaar is. Technisch is het mogelijk om automatisch de SURFfederatie metadata (inclusief alle IdPs en SPs) te uploaden naar de MDS. Een snelle software exercitie heeft dit aangetoond. Het downloaden van metadata van andere federaties uit MDS kan op een soortgelijke wijze gerealiseerd worden. Dit is niet uitgeprobeerd, maar we verwachten geen problemen dit te implementeren. De metadata die uit de MDS gedownload wordt zal niet direct geschikt zijn gebruikt te worden in de SURFfederatie (door de PingID software). Hoewel zowel eduGAIN als de SURFfederatie de SAML Metadata hanteren zijn kleine verschillen niet ondenkbaar. Mogelijk zullen hier nog wat syntactische vertaalslagen plaats moeten vinden om de metadata op elkaar te mappen. Gedurende de experimenten met MDS en het uploaden van metadata bleek dat veel software slecht onderhouden is en er weinig betrokkenheid van de andere eduGAIN partners is. Sommige partners zijn inmiddels zelfs aan het nadenken over totaal andere oplossingsrichtingen die uitgaan van een sterk gedistribueerd model van metadata uitwisseling. Een centrale oplossing, zo blijkt nu wel, is lastig te realiseren en vereist veel afstemming en draagvlak bij alle partijen. Eén van de toekomstige modellen voor eduGAIN is het gebruik van metadata tagging (zie ook sectie 4.1.3). Op deze manier kunnen alle partijen lokaal hun eigen metadata beheren met daarin de tags van een betrouwbare partij zoals eduGAIN. De volgende uitdaging is dan het vinden van de metadata. Hier kan het Domein Naam Systeem (DNS) een rol in spelen. In een vervolgdocument zal in meer detail bekeken worden of DNS en DNSSEC een rol kunnen spelen bij het uitwisselen van betrouwbare (con)federatiemetadata.

4.1.6

Evaluatie

De metadata bevat informatie waaruit veel vertrouwen geput wordt door de federatie. Het is daarom uitermate belangrijk dat de metadata up-to-date is en op een veilige manier gedistribueerd wordt. Als een buitenstaander toegang kan krijgen tot de metadata dan kan hij zich voordoen als een SP en allerlei eindgebruikerinformatie opvragen. Het management van de metadata vereist nogal wat inspanning. Verschillende manieren zijn mogelijk voor de distributie van de metadata: installatie bij de SPs en IdPs door de federatie operator, via e-mail naar de federatiepartners, handmatig te verkrijgen via een website, of geautomatiseerd vanaf een bekende locatie. Binnen de SURFfederatie wordt de metadata momenteel vooral handmatig verwerkt (via e-mails) en via een centrale locatie aangeboden. Kansen op fouten bestaan hierdoor en maken SURFnet aansprakelijk. Hoewel partijen SURFnet er wel in vertrouwen dat de verwerking van de metadata goed gebeurt. Om op te schalen is het noodzakelijk dat de aangesloten partijen zelf de verantwoordelijkheid krijgen om veranderingen in hun metadata zelf te verwerken en aan te bieden. Binnen de Covisint federatie is deze aanpak momenteel de dagelijkse praktijk. Dit aanbieden kan vanaf een centrale locatie of gedistribueerd vanaf de eigen locaties. De voorkeur gaat daarbij uit naar het laatste model omdat de praktijk uitwijst dat het creëren van een centrale entiteit lastig is omdat er vaak geen verantwoordelijke partij is die dit op zich neemt. Bovendien is een centrale entiteit vaak kwetsbaar voor Denial of Service (DoS) aanvallen en vormt het een bottleneck ten aanzien van de performance. Partijen willen eigenlijk ook alleen maar de metadata hebben van de partners waarmee ze zaken doen en willen niet overweg hoeven gaan met een gigantische centrale metadatafile waarin alles staat.

Schaalt dat?

41

Een gedistribueerd en dynamisch metadatamodel is dan een logische vervolgstap. Partijen die met elkaar zaken willen doen kunnen dan op dynamische manier metadata uitwisselen op grond waarvan beslissingen gemaakt worden. De keuze voor dit model hangt ook samen met de strategie van SURFnet voor de hub in de huidige SURFfederatie. Als men ervoor kiest om deze hub te zijner tijd uit te faseren dan is een decentraal model voor data-uitwisseling gewenst. Belangrijk is dat de metadata voldoende vertrouwenselementen bevat. Het taggen van metadata is dan een interessante optie voor het schaalbaar maken van metadata uitwisseling tussen federaties. Als men voor het ‘dikker maken’ van de hub opteert dan ligt het aanbieden van een geaggregeerde federatie metadatafile voor de hand. Het hanteren van licenties voor het gebruik van metadata is interessant maar heeft sinds zijn introductie in 2007 weinig opvolging gekregen (alleen de Zweedse federatie maakt er gebruik van). Waarschijnlijk komt dit doordat het lastig is om te controleren of SPs zich conform de licentie gedragen. Vooral in grote federaties schaalt dit dus slecht.

4.2


Het gebruik van trusted directory services voor het uitwisselen van informatie op een betrouwbare manier is niet nieuw. Vaak zijn dit centralistische oplossingen waarbij relatief veel overhead gecreëerd wordt als het gaat om identiteitsgegevens. Het betreft hier dan vaak een centrale database die beheerd wordt door een TTP en waarin informatie staat waarop partijen kunnen vertrouwen. Ook het Virtuele Organisatie (VO) concept zoals dat in de GRID wereld geïmplementeerd wordt is hiervan een goed voorbeeld. Een andere manier om op een betrouwbare en eenvoudige manier aan informatie te komen is door gebruik te maken van het DNS en de beveiligingsextensies ervan (DNSSEC). Het inrichten van een DNSSEC zone voor het uitwisselen van certificaten is hiervan een goed voorbeeld [ 55, 56]. Op deze manier kan makkelijk een VO of federatie ingericht worden waar partijen via DNSSEC op een betrouwbare manier certificaten kunnen verkrijgen om te controleren of ze met de juiste partner communiceren. Het feit dat een certificaat in een bepaalde DNSSEC zone staat geeft aan of de bijbehorende partij lid is van de VO of federatie. De VO of federatiemanager hoeft slechts de DNS zone te managen. Partijen kunnen eventueel zelf hun gegevens in de zone uploaden. Een ander voordeel van deze aanpak is ook dat er meegelift kan worden op alle inherente kwaliteiten van de DNS-infrastructuur zoals de beschikbaarheid/robuustheid ervan en de update en caching mechanismen. Een nadeel is dat DNSSEC nog weinig in gebruik is en dat het intrekken van een certificaat in DNS soms lang kan duren (alle caches moeten dan geüpdate zijn). Een mogelijk extensie van dit model zou kunnen zijn dat partijen hun metadatagegevens via DNSSEC gaan communiceren. Dit model wordt ook geopperd in de SAML Metadata specificatie [8].

4.2.1

Evaluatie

Het inzetten van trusted directory services bieden een goede uitkomst voor het schaalbaar maken van metadata en of certificaat/sleutel management. Vooral DNSSEC lijkt hiervoor een goede kandidaat. Nadeel van DNSSEC is dat het nog weinig gebruikt wordt. Feitelijk houdt deze oplossing een verschuiving van het vertrouwensprobleem in: hoe is het vertrouwen in DNSSEC geregeld? Toch zijn de voordelen van het gebruik van het DNS systeem, zoals de betrouwbaarheid, vindbaarheid, gedistribueerdheid, cache mogelijkheden en up-to-dateness erg aantrekkelijk.

42


4.3

PKI

Met het gebruik van digitale handtekeningen over de SAML berichten met behulp van digitale certificaten die respectievelijk de IdP en SP representeren wordt op cryptografische wijze vertrouwen gecreëerd tussen deze partijen. Bovendien kan het ondertekenen van de federatie metadata ervoor zorgen dat partijen, op grond van de CA van het hiervoor gebruikte certificaat, voldoende vertrouwen krijgen om een gefedereerde communicatie over en weer aan te gaan. Een PKI kan dus gebruikt worden voor mutuele authenticatie tussen twee partijen in een federatie en het ondertekenen van de federatie metadata. Een PKI schiet over het algemeen tekort waar het gaat om het toekennen van toegangsrechten op grond van een certificaat. Hiervoor is SAML beter van toepassing. Een ander manco van een PKI is dat het goed werkt binnen een bepaald domein en slecht schaalt over domeinen heen, vooral in termen van vertrouwen en kosten. Hier delen PKIs en gefedereerde identiteitsinfrastructuren dus een gezamenlijke kwestie. Wat in de PKI-wereld wel gebruikelijk is, is dat partijen hun vertrouwen baseren op zogenaamde Certificate Policies (CP) en Certificate Practice Statements (CPS, zie [ 57]). Deze documenten beschrijven hoe een organisatie omgaat met digitale certificaten gedurende hun levensduur vanaf de uitgifte, validatie en tot het intrekken ervan. Een zelfde aanpak ontbreekt echter in de wereld van gefedereerd identiteitsmanagement. Partijen die deel uitmaken van een federatie of confederatie zouden hun identiteitsmanagement policies and practices in een standaard formaat, zoals bijvoorbeeld het door Exostar voorgestelde Federated IdM Policy and Practice Statements (FIdPPS) raamwerk [ 58], kunnen publiceren. Een FIdPPS beschrijft dan hoe een partij omgaat met bijvoorbeeld de volgende aspecten: ◊

Identiteit- en account provisioning over gedistribueerde omgevingen;

◊

Hoe iemand zijn identiteit moet bewijzen en hoe dit geregistreerd wordt;

◊

Hoe gegevens (credentials) uitgegeven en gemanaged worden;

◊

Welke tokens gebruikt worden, hoe dit per sessie aangepakt wordt en wat de life-cycle management van beweringen is;

◊

Identity repository management;

◊

Auditing en logging;

◊

Facility management.

Door Australië’s AusCERT is iets soortgelijks voorgesteld. In analogie met de CPS en CP voor het opbouwen van vertrouwen in een PKI, stelt AusCERT voor om in identiteitsfederaties de zogenaamde SAML Metadata Aggregation Practice Statement (SMAPS) en de SAML Metadata Signing Policy (SMSP) hiervoor te gebruiken [ 59]. SMAPS beschrijft hoe de geaggregeerde metadata is gecreëerd en wie dat gedaan heeft; SMSP beschrijft waarom dit was gedaan en waarvoor het gebruikt mag worden.

Schaalt dat?

43

Voor IdPs en SPs geven de beschikbaarheid van FIdPPS of SMAPS en SMSP duidelijkheid over onder welke voorwaarden de federatie opereert, welke risico’s er kleven aan het gebruiken van de metadata en daardoor dus een beter gevoel betreffende de betrouwbaarheid van de federatie. Bijkomend voordeel is dat auditors beter het opereren van een federatie kunnen beoordelen aan de hand van FIdPPs of SMAPS en SMSP. Verder kunnen dit soort gestandaardiseerde berichten bruikbaar zijn om te beoordelen of twee federaties die met elkaar willen federeren compatibel met elkaar zijn en op welke vlakken. Dit alles kan helpen in het opschalen van vertrouwen in een federatie of bij confederatie. Vaststaat dat het uitrollen van een X.509 gebaseerde PKI in een open netwerk niet eenvoudig te realiseren is. Globale certificaat hiërarchieën en name spaces zijn dan vereist; iets dat niet haalbaar is, nog afgezien van de complexiteit en kosten. De complexiteit van dit soort infrastructuren komt vaak boven water tijdens het definiëren van security policies en revocatieschema’s die hierop gebaseerd zijn. Ook in federaties geldt dat er nog maar relatief weinig applicaties zijn die volledig gebaseerd zijn op “claims”. Mogelijk kunnen beide oplossingen elkaar versterken in toekomstige betrouwbare federaties.

4.3.1

EV Certificaten

Extended Validation (EV) Certificaten zijn een bijzonder type X.509 certificaten waarbij een strengere controle van de identiteit van de eigenaar ervan bij de CA vereist is [ 60]. De procedure om een EV Certificaat te krijgen omvat een door de CA uitgevoerd strenger controle proces betreffende de identiteit van de aanvrager zodat het uitgegeven certificaat inderdaad bij de juiste persoon hoort. Het terugbellen van de aanvrager is bijvoorbeeld een dergelijke controlemaatregel. Het doel van deze striktere procedure is om te komen tot een hoger betrouwbaarheidsniveau voor de domeinnaam waarvoor het certificaat geldig is. De standaard aanpak voor het uitgeven van EV Certificaten helpt bij het creëren van een ‘common ground’ waarop partijen op een betrouwbare manier verder kunnen bouwen. EV Certificaten worden ondersteund door internet browsers als Microsoft Internet Explorer 7, Mozilla Firefox 3, Safari 3.2, Opera 9.5, en Google Chrome. Bijkomend voordeel van het gebruik van EV Certificaten is dat in deze browser de URL lijn groen oplicht of dat er een groen veldje voor de URL zichtbaar komt. Dit geeft de eindgebruiker meer vertrouwen in het feit dat hij/zij met de juiste partij verbonden is. EV Certificaten voorkomen echter niet dat phishers een nepwebsite kunnen opzetten waarvoor zij een geldig EV Certificaat hebben. Het wordt voor phishers wel onmogelijk gemaakt om een website op te zetten onder een domeinnaam waarvan ze geen eigenaar zijn. De eindgebruiker moet dan wel even de moeite nemen om de waarschuwing in de browser serieus te nemen en niet zomaar op de OK knop te drukken om verder te gaan… Het feit dat er een elektronische handtekening onder een digitaal bestand staat blijkt in de praktijk nog geen garanties te geven. Ondertekende code kan zelfs onveiliger zijn dan handtekeningloze code [ 61]. Ook valt het terugvinden van de persoon, op grond van zijn digitale handtekening, nog niet mee. Veel hackers maken gebruik van gaten in het CA certificaat uitgifteproces en van gestolen identiteiten.

44


4.3.2

Evaluatie

Kan een CA-loze federatie bestaan? In dat geval stop je alle certificaten in de metadata. Dit zijn dan typisch self-signed certificaten. Deze aanpak heeft veel voordelen omdat het beter schaalt en er geen CA hoeft te worden ingericht of diensten van hoeven afgenomen te worden. Nadelen van deze aanpak betreffen het life-cycle management (geldigheid, rollover, intrekken) van de certificaten in de metadata (moet in ieder geval met korte intervallen geüpdate worden), de onduidelijkheid of TLS hiermee kan functioneren, het ontbreken van trust paths (maar die zijn er in de praktijk toch al niet zoveel), en dat er nieuwe tools nodig zijn om op deze manier de federatie te managen. De toekomstverwachting is dat de meeste federaties een CA blijven gebruiken voor het tekenen van de metadata. Echter, omdat partijen steeds meer in verschillende federaties zullen opereren zullen ze nieuwe, federatiespecifieke certificaten niet accepteren en slechts encryptiesleutels of self-signed certificaten aanbieden. Hierdoor zullen federaties gedwongen worden om beide oplossingen aan te bieden. Daarnaast kleven er aan het gebruik van self-signed certificaten ernstige vertrouwenskwesties omdat de uitgifte ervan niet door een TTP is gecontroleerd. Voordat self-signed certificaten in bijvoorbeeld de metadata gebruikt kunnen worden dient de operator zich ervan te vergewissen dat deze certificaten daadwerkelijk bij een federatielid behoren. Typisch vindt deze verificatie via een apart kanaal plaats (telefonisch of fax). Duidelijk is wel dat dit slecht schaalt. Het kan voor identiteitsfederaties handig zijn om, in analogie met het gebruik van Certificate Policies (CP) en Certificate Practice Statements (CPS) in PKIs, soortgelijke policies en best practices te definiëren. Dit creëert duidelijkheid voor allen partijen en daardoor vertrouwen. Daarnaast kunnen deze federatiepolicies het confederatieproces vereenvoudigen mits ze op een gestandaardiseerde manier opgezet zijn. Het Liberty Alliance Identity Governance Framework (zie sectie 3.7) zegt hier iets meer over.

4.4

Samenvatting

Duidelijk is dat informatie in de vorm van metadata, delegatie en decentralisatie belangrijke elementen zijn voor het technisch schaalbaar maken van vertrouwen. Veelbelovend zijn daarom aanpakken als dynamic SAML en metadata tagging waarbij op een flexibele en gedistribueerde manier informatie kan worden uitgewisseld op grond waarvan heldere vertrouwensbeslissingen genomen kunnen worden. Het gebruik van trusted directory services zoals het DNS met haar beveiligingsextensies is een interessante alternatieve manier voor een dynamisch, decentraal, robuust en schaalbaar inrichten van metadata uitwisseling in een (con)federatie.

Schaalt dat?

45

5 Conclusies Vertrouwen is een complex begrip bestaande uit vele facetten. Het is belangrijk op te merken dat vertrouwen opgebouwd wordt op basis van zakelijke overeenkomsten die in lijn zijn met juridische kaders en gebaseerd op risico-inschattingen op grond van de beschikbare informatie. Deze aspecten representeren de meer organisatorische dimensie van vertrouwen. De technische middelen die ingezet worden om dit vertrouwen te borgen zijn van secondair belang. Zonder een productieve zakelijke relatie, een gemeenschappelijk doel, gezamenlijke spelregels, solide contractuele overeenkomsten en de bereidbaarheid om risico’s te nemen en te delen is er geen basis voor vertrouwen. Partijen die ervoor kiezen om te participeren in een identiteitsfederatie, al dan niet via een hub of multilateraal, doen dit vanuit een bedrijfseconomische context. Technische federatieve vertrouwensoplossingen, hoe goed uitgedacht en geïmplementeerd ze ook zijn, kunnen geen wonderen verrichten. Ze kunnen niet op een spontane, magische wijze vertrouwen tussen twee partijen creëren. Ze kunnen er wel voor zorgen dat al bestaande vertrouwensrelaties op een productieve manier benut kunnen worden in een waardeketen of -netwerk. Met andere woorden: ze kunnen ervoor zorgen dat, in een identiteitsfederatie, vertrouwen beter schaalt. Sleutelwoorden voor het schaalbaar maken van vertrouwen vanuit organisatorisch perspectief zijn het maken van heldere afspraken en het bieden van transparantie en controle. Essentiële elementen waar technische oplossingen aan moeten voldoen zijn het vermogen om te delegeren en te decentraliseren. Centraal in beide typen vertrouwen is het uitwisselen van informatie. De winst voor het schaalbaar maken van vertrouwen zit in het vinden van efficiënte manieren van informatieuitwisseling over de federatie. Dit zorgt ervoor dat partijen makkelijker kunnen toetreden tot de federatie en hier ook eerder geneigd toe zullen zijn. Immers, hoe meer informatie er beschikbaar is des te beter valt er een risico-inschatting te maken om wel of niet met die partij in zee te gaan. Dat federatiemetadata hierin een belangrijke rol speelt is evident. Hierin staan immers alle partijen die in de federatie participeren en staan verwijzingen naar de policies die bepalen op welke manier er in de federatie dient samengewerkt te worden. Voor nieuwkomers dus een essentiële bron van informatie op grond waarvan besloten kan worden al dan niet toe te treden tot de federatie. Omdat de metadata een zodanig bepalende rol hierin speelt is de betrouwbaarheid ervan essentieel. Alle informatie die erin staat moet kloppen en up-to-date zijn. Een voorbeeld hiervan is het opnemen van certificaten of sleutels in de metadata. Hierdoor zijn complexe PKI oplossingen niet meer nodig en verschuift het vertrouwen van de traditionele hiërarchische PKI naar de metadata. Partijen hoeven dan niet noodzakelijkerwijs een PKI certificaat aan te schaffen, wat vaak een drempel is, maar kunnen dan zelfs af met een self-signed certificaat. Partijen in de federatie hoeven dan ook niet meer een lijst met certificaten van partners in de federatie bij te houden, de zogenaamde trust anchor list. Dit is lastig wanneer er steeds nieuwe partijen bijkomen in de federatie en wanneer een certificaat vernieuwd of ingetrokken moet worden. Dit probleem is niet aanwezig in een hub en spoke model als de SURFfederatie: daar houdt de hub bij welke partijen participeren.

46


6 Aanbevelingen voor de SURFfederatie Hoewel de SURFfederatie een succesvolle federatie is, zijn er verschillende elementen die aandacht vereisen en die met name een impact kunnen hebben op het creëren en borgen van vertrouwen. Zou dit niet gedaan worden dan vormen deze elementen een potentieel struikelblok voor het verder opschalen van de SURFfederatie. In de praktijk blijkt bijvoorbeeld dat een belangrijke hindernis bij het laten toetreden van nieuwe deelnemers tot de SURFfederatie het afstemmen van de privacy policy van de toetredende partij met die van de SURFfederatie is. Dit geldt voornamelijk voor SPs, maar in mindere mate ook voor sommige IdPs. Vooral als partijen in meerdere federaties participeren creëert dit veel ongewenste complexiteit voor die partijen vanwege verschillen in de privacy policies. We merken op dat de SURFfederatie momenteel slechts een concept privacy policy hanteert 3; blijkbaar hebben de betrokken partijen voldoende vertrouwen in SURFnet en elkaar voor het correct omgaan met persoonlijke informatie. Een zelfde privacy policy afstemmingsprobleem ontstaat wanneer twee federaties met elkaar willen confedereren. In dit geval zullen de privacy policies van beide federaties op elkaar afgestemd moeten worden. Vanuit schaalbaarheidsperspectief is privacy policy management een potentieel knelpunt voor federaties die de ambitie hebben te groeien en te federeren met andere federaties. Binnen GÉANT2 is door verschillende partijen hard gewerkt aan een aanpak voor confedereren. Echter, de juiste aanpak is nog niet gevonden en op verschillende vlakken wordt nog gezocht naar oplossingen. Dit geldt vooral voor het efficiënt en betrouwbaar uitwisselen van metadata. Zoals we gezien hebben in het vorige hoofdstuk is de betrouwbaarheid van de metadata een cruciaal element in elke federatie. De metadata bevat informatie over de certificaten van de partijen in de federatie en hun eindpunten (URLs). Dit is informatie die nog wel eens wil veranderen: certificaten verlopen en worden vervangen of eindpunten veranderen bij het inrichten van een nieuwe authenticatieserver. Het is essentieel dat de meest recente informatie gecommuniceerd wordt binnen de partijen. SURFnet ondervindt veel overhead bij het managen van de metadata, aangezien dit nog grotendeels een handmatig proces is. Soms loopt men achter de feiten aan omdat men niet op de hoogte is van veranderingen. Door een pro-actieve houding tegenover de leden van de SURFfederatie weet SURFnet de schade te beperken. Dit metadata management zal in de toekomst bij een groeiende SURFfederatie alleen maar toenemen; een efficiëntere oplossing hiervoor is nodig om te voorkomen dat het een remmende werking op de groei van de federatie gaat krijgen of zelfs de vertrouwensrelatie naar de leden toe kan schaden (bij fouten in de metadata). SURFnet’s pro-actieve houding helpt bij het betrouwbaar houden van de SURFfederatie dienst. Er zijn verschillende strategieën om vertrouwen te managen: ◊

Passief: Publiceer een policy en hanteer een strikte audit procedure om ervoor te zorgen dat partijen zich aan hieraan houden.

3

Privacy Best Practice SURFfederatie (concept), http://www.surfnet.nl/nl/Thema/SURFfederatie/Documents/privacy-bestpractice.pdf, geen datum of versienummer (link gecontroleerd op 29 juli 2009).

Schaalt dat?

47

◊

Actief: Dynamisch een contractuele relatie aangaan.

Duidelijk is dat de keuze voor een bepaalde strategie zijn specifieke implicaties heeft voor het inrichten van de federatie. Een passief beleid vereist meer focus op het loggen van gegevens en het controleren of iedereen zich aan de richtlijnen voor gebruik van de federatiedienst houdt. Een actief beleid impliceert het aanbieden van diensten die het mogelijk maken dat partijen die elkaar op voorhand niet kennen een contract kunnen afsluiten over het uitwisselen van identiteitsgegevens. Te denken valt hierbij aan het aanbieden van standaard contracten die met digitale handtekeningen ondertekend kunnen worden. Voor de schaalbaarheid van vertrouwen maakt de keuze voor een bepaalde strategie niet zo heel veel uit. De gekozen strategie bepaalt wel welke oplossingsrichtingen het beste aansluiten.

6.1

Aanbevelingen

Uit de hierboven beschreven obstakels voor het schaalbaar maken van vertrouwen in de SURFfederatie valt af te leiden dat privacy policy en metadata management nog weinig efficiënt zijn ingericht en een voorspoedig groeimodel in de weg staan. Beide management aspecten dragen ertoe bij dat SURFnet relatief veel handelingen moet verrichten om de SURFfederatie draaiende te houden. De onderhoudbaarheid staat onder druk en de kans op fouten neemt toe naarmate meer en meer partijen zich aansluiten. Ondanks het feit dat contractueel is vastgelegd dat SURFnet niet aansprakelijk is voor de eventuele gevolgen van een verkeerd geconfigureerde privacy policy of fout in de metadata, is het hierdoor wel kwetsbaar voor het oplopen van vertrouwensschade in het geval van een incident. Kijkende naar de oplossingen die voorhanden zijn is dit onnodig. We stellen daarom de volgende technische en organisatorische oplossingen voor om ervoor te zorgen dat vertrouwen in de SURFfederatie op een degelijke manier geborgd kan worden: ◊

48

Zelfmanagement door IdPs en SPs. Bied via de hub identiteitsdiensten aan waarmee IdPs en SPs zelfmanagement kunnen doen. Voorbeelden van dit soort diensten zijn: o

Een dashboard waarmee partijen zelf kunnen aangeven met wie ze zaken doen. Dit is efficiënter dan huidige praktijk en SURFnet wordt hierdoor niet meer of minder verantwoordelijk en daarmee ook niet meer aansprakelijk.

o

Een onderdeel van dit dashboard is de mogelijkheid voor IdPs om zelf te configureren welke attributen ze delen met welke SP. Hierdoor wordt het huidige filteren van attributen op de hub naar de IdP verplaatst waardoor deze verantwoordelijk wordt voor de data en zijn handtekening eronder kan blijven staan.

o

Loggen van alle transacties en partijen inzicht geven in hun eigen transacties zodat ze zelf kunnen bepalen of ze zaken willen blijven doen met een specifieke partner.

o

Een upload dienst voor metadata (al dan niet onderdeel van hetzelfde dashboard). Partijen kunnen in het geval van een vernieuwd certificaat of veranderd eindpunt zelf de nieuwe data uploaden.


De hub wordt dus uitgebreid met verschillende identiteitsgerelateerde diensten die ervoor zorgen dat partijen in de federatie voldoende eigen middelen hebben om hun relaties te managen en informatie te krijgen op grond waarvan zij met vertrouwen kunnen opereren in de federatie. SURFnet zit door zelfmanagement van de aangesloten partijen zelf minder in het kritische pad en zal zich voornamelijk moeten concentreren op het monitoren en mogelijk ook auditen van het gedrag van de partijen in de SURFfederatie en om ervoor te zorgen dat de SURFfederatie een voldoende kwaliteitsniveau bereikt betreffende alle vertrouwensaspecten. Audits zullen nodig zijn om dit af te dwingen. SURFnet gaat met de SURFfederatie dan meer het Covisint model volgen. ◊

Afstemmen van privacy policies. In een privacy policy staat op welke manier partijen in de SURFfederatie omgaan met persoonlijke gegevens. SURFnet moet zorgen dat dit op een integere en confidentiële manier gebeurt, SPs moeten verplicht worden niet meer dan noodzakelijke persoonsinformatie op te vragen, dit slechts voor vooraf aangegeven doeleinden te gebruiken en de informatie niet langer te bewaren dan noodzakelijk is. IdPs zullen zorg moeten dragen voor kwalitatief hoogwaardige gebruikers authenticatie en de authenticiteit van de persoonsgegevens. Vanzelfsprekend zijn er ook privacy verplichtingen voor SURFnet zelf, met name als het gaat om monitoren en het niet onnodig lang bewaren van logs. De policies van alle betrokken partijen zullen op dit vlak afgestemd moeten worden. Daarnaast zal ook de federatie policy afgestemd moeten worden tijdens een confederatie. Het afstemmen van al deze policies is, vooral bij confederaties, geen sinecure en kan daarmee schaalbaarheid in de weg staan. Het Liberty Alliance IGF is, hoewel het nog volop in ontwikkeling is, hiervoor een interessante kandidaat. Ook Europese richtlijnen voor data bescherming en privacy spelen hierbij een belangrijke rol en hebben direct impact op de privacy policies in een identiteitsfederatie.

◊

De contractuele kant verder professionaliseren. Contractuele relaties zijn een drempel in het schaalbaar maken van de federatie. Vele factoren waarover overeenstemming bereikt moet worden spelen hierbij een rol: o

Technische federatiestandaarden: communicatiebeveiliging, certificatie, authenticatiemiddelen die gebruikt worden, en de identiteitsattributen;

o

Policy management;

o

Audit requirements;

o

Privacy policies (zie punt hierboven over privacy policies);

o

Afhandeling van fouten;

o

Beveiligingseisen;

o

Risico’s en aansprakelijkheden;

o

Beschikbaarheid;

o

Contract management.

Schaalt dat?

49

Partijen in de federatie zullen verschillende overeenkomsten met elkaar aangaan in een federatie. Deze verschillen hangen af van de rol die een partij speelt in de federatie, welke data er gecommuniceerd wordt en voor welk doel. Het adresseren van de wie, wat en waarvoor vragen zijn een eerste essentiële stap in het opstellen van een contractueel raamwerk voor een identiteitsfederatie. Dientengevolge dienen deelnemers aan een identiteitsfederatie aan te geven welke types data zij verwerken (consumeren, uitdelen), welke rol zij vervullen met betrekking tot deze data en de verplichtingen of beperkingen die hierbij gepaard gaan. Hoewel bijna al deze punten al in meer of mindere mate aan bod komen in de huidige contracten van de SURFfederatie is het verstandig deze nog eens kritisch te bekijken en waar nodig aan te passen zodat volledig helder is wat de rechten en plicten zijn van de verschillende (typen) deelnemers aan de SURFfederatie. ◊

Heldere aansluitvoorwaarden. Geef helderheid voor wat betreft de aansluitvoorwaarden van de SURFfederatie. Waaraan moet een IdP of SP voldoen voordat hij toe mag treden tot de federatie. De SURFfederatie biedt het gemak voor een SP om de authenticatie voor zijn systemen uit te besteden aan een onderwijsinstelling. De SP vertrouwt erop dat het authenticatiesysteem van de andere deelnemers, waar hij geen zicht op heeft, in orde is. Voor een betrouwbare federatie is het uiteindelijk vereist te kunnen bouwen op een betrouwbare infrastructuur van alle aangesloten partijen. Om deze te realiseren zullen alle aangesloten partijen hun beveiliging op orde moeten houden. Hierbij is een rol weggelegd voor SURFnet en de informatiebeveiligingsfunctionarissen. Heldere afspraken geven duidelijkheid en daarmee vertrouwen. Een lokale audit zou een onderdeel kunnen zijn van de aansluitvoorwaarden tot de SURFfederatie. Partijen kunnen dan ook aangesproken worden op het correct naleven van de aansluitvoorwaarden.

◊

User-centric identity. Geef de eindgebruiker meer verantwoordelijkheden: introduceer user-centric identiteitsmanagement. De noodzaak tot federeren neemt hiermee af en dus ook het regelen van het vertrouwen. De eindgebruiker krijgt de mogelijkheid om zelf te bepalen welke persoonlijke informatie hij/zij wil delen met de SP en kan kiezen welke IdP dit aanlevert. Zorg er wel voor dat de eindgebruiker dit op een intuïtieve en begrijpelijke manier kan doen om te voorkomen dat hij/zij door de bomen het bos niet meer kan zien en het vertrouwen in de federatie verliest. Voor meer details over user-centric identiteitsmanagement verwijzen we naar de User Centric Privacy activiteit binnen het SURFfederatie PoCs project.

◊

Efficiënt metadata management. Laat de hub metadata aggregeren en dynamisch communiceren naar de SPs. Incorporeer certificaten en tags in de metadata zodat alle partijen veilig met elkaar kunnen communiceren. Trusted directory services zoals DNSSEC kunnen gebruikt worden voor het veilig distribueren van de metadata.

◊

Meer aandacht voor confederatie. Het federeren van federaties tot een confederatie is een aantrekkelijke manier om op te schalen. Ook hier speelt metadata een belangrijke rol, maar dan op federatieniveau. In een confederatie is de afstemming van federatiemetadata uitermate belangrijk voor opschaling. Alle federaties moeten op een betrouwbare manier metadata kunnen uploaden, veranderen en downloaden zodanig dat SPs, IdPs en eventuele hubs ermee overweg kunnen. Daarnaast zal afstemming van privacy policies nodig zijn voor een succesvolle opschaling van de confederatie. Aandacht hiervoor wordt gevoed door de activiteiten binnen eduGAIN.

50


Tot slot merken we op dat veel van de bovenstaande aanbevelingen indirect zijn gerelateerd aan interoperabiliteit (afstemmen policies, standaardisatie) en discovery (van metadata en IdPs). Beide aspecten dragen zonder meer bij tot een betere opschaling van een federatie. En, hoewel ze los staan van vertrouwen, dienen ze in ogenschouw genomen te worden bij een verdere opschaling van de SURFfederatie. Een andere manier voor het uitwisselen van informatie is het aanbieden van diensten die de partners in de federatie op de hoogte houden van wie er in de federatie zit en welke identiteitsgegevens er wanneer uitgewisseld zijn. Het aanbieden van een dashboard dat dit soort informatie levert is hiervoor een goede oplossing. Het dashboard levert de federatiedeelnemer de juiste informatie, controle en transparantie die hem het vertrouwen geven identiteitstransacties aan te gaan met andere deelnemers in de federatie. Het federeren van federaties tot een zogenaamde confederatie is een interessant model voor het schaalbaar maken van vertrouwen. In plaats van te streven naar één grote federatie lijkt confedereren stukken beter op te schalen. Ook hier speelt federatiemetadata een belangrijke rol. Uit de eduGAIN proof of concept blijkt dat het relatief eenvoudig is om op een betrouwbare manier de eigen federatiemetadata te uploaden en van andere federaties te kunnen downloaden en gebruiken. Echter, een centrale metadatadienst vereist onderhoud en moet worden aangeboden door een betrouwbare partij en dat is nu juist iets dat ontbreekt in eduGAIN. Het DNS en haar security extensies bieden potentiëel een uitstekende alternatieve oplossing voor het op decentrale wijze en op een robuuste en schaalbare manier managen van federatiemetadata. In een vervolgonderzoek zal hier daarom in meer detail naar gekeken worden. Veel inlevingsvermogen wordt vereist van de eindgebruiker die actief is in een confederatie; deze moet immers aangeven in welke identiteitsfederatie hij/zij zich bevindt en welke IDP hem/haar het beste kan authenticeren. De vraag is of hierdoor het vertrouwen van de eindgebruiker in de dienst juist niet afneemt doordat hij/zij het niet begrijpt. En daar draait het natuurlijk ook om in de SURFfederatie: zonder gebruikers is de dienst gedoemd te mislukken. User-centric identiteitsmanagement kan helpen de eindgebruiker de controle te geven over welke data hij of zij binnen de federatie aan welke service provider uitgeeft. Dit gevoel van controle is een manier om een positieve experience voor de eindgebruiker te creëren en hem of haar voldoende vertrouwen te geven in het gebruik van de SURFfederatie. In de User Centric Privacy activiteit van het SURFfederatie PoCs project wordt hier verder onderzoek naar verricht. Vanuit het perspectief van de SPs is het ook nog maar de vraag of zij op confederaties zitten te wachten. Het grotere commerciële afzetgebied dat een confederatie biedt lijkt aantrekkelijk maar veel SPs in de huidige SURFfederatie zijn vooral gericht op het bedienen van het nationale hoger onderwijs (SURFspot, eduPoort, SURFmailfilter, etc.). Als op een heldere manier aan SPs kan worden uitgelegd wat voor hun de (commerciële) voordelen zijn zou dit voor SPs reden kunnen zijn om de vertrouwenslat wat lager te leggen, de eventuele risico’s voor lief te nemen en toe te treden tot de SURFfederatie.

Schaalt dat?

51

Het centrale hub model van de SURFfederatie leent zich goed voor een efficiënte opschaling van de federatie en zelfs tot confederatie. In de automotive sector toont Covisint aan dat op deze manier een zeer grote succesvolle federatie kan ontstaan. Toch zien we dat op dit moment in het hoger onderwijs praktisch alle federatieve koppelingen op bilaterale wijze tot stand komen, een op zijn zachtst gezegd weinig schaalbare aanpak. Dan rijst de vraag tot hoe ver een identiteitsfederatie in het hoger onderwijs moet schalen: verwachten we dat enkele tientallen of enkele duizenden SPs een federatieve koppeling met een IdP gaan hebben? Momenteel zijn het vooral kleinschalige federaties waarbij het nog redelijk overzichtelijk is om vertrouwen te managen. Bij veel grootschaligere implementaties belanden we vermoedelijk in een iets andere wereld van user-centric (InfoCards, OpenID, self-asserted) aanpak waarbij het vertrouwen waarschijnlijk ook wordt afgebouwd. Met andere woorden het lijkt een trade-off: hoe groter de federatie des te lastiger is het om vertrouwen te creëren en vice versa. En dan is de uitspraak van Lao Tse (“Wie geen vertrouwen stelt in anderen zal ook nimmer het vertrouwen van anderen winnen”) misschien wel het beste antwoord op de vraagstellende titel van dit document.

52


Referenties [1]

John Linn et el., OASIS Trust Models Guidelines, sstc-saml-trustmodels-2.0-draft-01, 2004, zie http://www.oasis-open.org/committees/download.php/6158/sstc-samltrustmodels-2.0-draft-01.pdf.

[2]

SURFfederatie voor het Nederlandse hoger onderwijs, zie http://www.surfnet.nl/nl/Thema/SURFfederatie/Pages/Default.aspx.

[3]

Feide federatie voor het Noorse onderwijs, zie http://feide.no/.

[4]

Feide’s OpenIdP, zie https://rnd.feide.no/content/releasing-feide-rnd-openidp.

[5]

Kalmar Union website: www.kalmar2.org.

[6]

Kalmar Union Memorandum of Understanding and Charter, zie http://docs.feide.no/form-0012-1.1-en.pdf.

[7]

M. Linden, D. Simonsen, A. Åkre Solberg, I. Melve & W.M. Tveter, Kalmar Union, a confederation of Nordic identity federations, TNC2009, Malaga, Spanje, zie http://tnc2009.terena.org/schedule/presentations/show.php?pres_id=28.

[8]

S. Cantor et al., Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0, OASIS Standard, maart 2005, document ID saml-metadata-2.0-os, zie http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf.

[9]

InCommon federatie voor het hoger ondewijs in de U.S., zie http://www.incommonfederation.org/.

[10]

Shibboleth, zie http://shibboleth.internet2.edu/.

[11]

Covisint, zie http://www.covisint.com/.

[12]

Covisint Trusted Identity Broker whitepaper, zie http://covisent.com/res/whitePapers/covisint_tib_wp.pdf.

[13]

EU STORK eID Interoperability project, zie http://www.eid-stork.eu/.

[14]

Euro Grid Policy and Management Authority, zie http://www.eugridpma.org/.

[15]

International Grid Trust Federation, zie http://www.igtf.net/.

[16]

eduGAIN, zie www.edugain.org.

[17]

T. Lenggenhager et al., GÉANT2 Deliverable DJ5.4.1.2, Advanced Technologies Overview, Second Edition, februari 2009.

[18]

GN2-08-130: DJ5.2.3.3 - Best Practice Guide - AAI Cookbook - Third Edition, zie http://www.geant2.net/upload/pdf/GN2-08-130-DJ5-2-3-3_eduGAIN_AAI_CookBook1.pdf.

[19]

G. Lopez et al, Extending the Common Services of eduGAIN with a Credential Conversion Service, ESORICS 2007, J. Biskup en J. Lopez Eds., LNCS 4734, pp. 501-514, 2007.

[20]

Josh Howlett, Reflections on eduGAIN and a proposal, JANET(UK), 24 november, 2008.

[21]

Microsoft Windows CardSpace, zie http://www.microsoft.com/windows/products/winfamily/cardspace/default.mspx.

Schaalt dat?

53

[22]

Higgins Open Source Identity Framework, zie http://www.eclipse.org/higgins/.

[23]

Higgins relationship card, r-Card, zie http://wiki.eclipse.org/R-Card.

[24]

Presentatie van Gerry Gebel (Burton Group) over de “Current State of Federated Identity” tijdens het OASIS Open Standards Forum, 3 oktober 2008, zie http://events.oasis-open.org/home/sites/events.oasis-open.org.home/files/Gebel.ppt.

[25]

Vendor Relationship Management (VRM), zie http://en.wikipedia.org/wiki/Vendor_Relationship_Management.

[26]

Project VRM, zie http://cyber.law.harvard.edu/projectvrm/Main_Page.

[27]

ProtectServe, zie de blog van Eve Maler: http://www.xmlgrrl.com/blog/archives/2009/04/02/protectserve-draft-protocolflows/.

[28]

OAuth, open authenticatie protocol, zie http://oauth.net/.

[29]

Representational State Transfer (REST), zie http://en.wikipedia.org/wiki/Representational_State_Transfer.

[30]

Washington Post, zie http://www.washingtonpost.com/wpdyn/content/article/2007/07/01/AR2007070101355.html?hpid=artslot.

[31]

G. Lenzini, N. Sahli en H. Eertink, Agents selecting trustworthy recommenders in mobile virtual communities, in R. Falcone, S. Barber, J. Sabater-Mir en M. Singh, editors, TRUST 2008, volume 5396 van LNCS/LNAI, pagina’s 182-204, Springer-Verlag Berlin Heidelberg, 2008.

[32]

N. Sahli, G. Lenzini, en H. Eertink, Trustworthy agent-based recommender system in a mobile p2p environment, in de Proceedings of the 7th International Workshop on Agents and Peer-to-Peer Computing (AP2PC08), gehouden tijdens de Autonomous Agents & Multi-Agents Systems Conference, AAMAS 2008, Estoril, Portugal, 12-13 mei, 2008.

[33]

N. Zhang, E-Infrastructure Security: An Investigation of Authentication Levels of Assurance(LoAs), Open Grid Forum 2007, zie http://www.ogf.org/OGF19/materials/561/OGFLoABoF.pdf.

[34]

IAAC Position Paper over “Identity Assurance (IdA): Towards a Policy Framework for Electronic Identity, 18 oktober 2005, zie http://www.iaac.org.uk/Portals/0/identity_management_paper_v1-7.pdf.

[35]

Liberty Alliance Identity Assurance Expert Group (IAEG), zie http://www.projectliberty.org/strategic_initiatives/identity_assurance.

[36]

Peter Alterman et al., Liberty Identity Assurance Framework – Read Me First, version 1.0, zie http://www.projectliberty.org/liberty/content/download/4546/31057/file/libertyidentity-assurance-.

[37]

William E. Burr, Donna F. Dodson en W. Timothy Polk, NIST Special Publication 800-63, Version 1.0.2, Electronic Authentication Guideline - Recommendations of the National Institute of Standards and Technology, april 2006, zie http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf.

[38]

Ning Zhang et al., E-infrastructure Security: Levels of Assurance, JISC project, oktober 2007, zie http://www.jisc.ac.uk/media/documents/programmes/einfrastructure/finalreport.pdf

54


[39]

Autralische Access Federatie (AAF) LoA raamwerk, zie http://www.aaf.edu.au/docs/AAF_LoA_Proposal_v1-2.pdf.

[40]

InCommon Identity Assurance Profiles, zie https://spaces.internet2.edu/display/InCCollaborate/InCommon+Identity+Assurance.

[41]

Zwitserse SWITCHaai LoA pilot, zie https://aaiwiki.switch.ch/bin/view/AAIHomeOrgs/AssuranceLevels.

[42]

MyID.is Certified, zie http://dev.myid.is/.

[43]

Liberty Alliance Identity Governance Framework, zie http://www.projectliberty.org/liberty/resource_center/specifications/igf_1_0_spec.

[44]

Phillip Hunt & Prateek Mishra, Identity Governance Framework, Oracle whitepaper, november 2006, zie http://www.oracle.com/technology/tech/standards/idm/igf/pdf/IGF-Overview-02.pdf.

[45]

Phil Hunt, Prateek Mishra en Mark Wilcox, Client Attribute Requirements Markup Language (CARML) Specification, working draft 03, 24 november 2006, document identifier: IGF-CARML-spec-03, zie http://www.oracle.com/technology/tech/standards/idm/igf/pdf/IGF-CARML-spec03.pdf.

[46]

Prateek Mishra, Phil Hunt en Rich Levinson, AAPML: Attribute Authority Policy Markup Language, Working Draft 08, november 28 2006, document identifier: IGF-AAPML-spec08, zie http://www.oracle.com/technology/tech/standards/idm/igf/pdf/IGF-AAPMLspec-08.pdf.

[47]

Tom Scavo en Scott Cantor, Metadata Extension for SAML V2.0 and V1.x Query Requesters, OASIS Standard, 1 november 2007, zie http://docs.oasisopen.org/security/saml/Post2.0/sstc-saml-metadata-ext-query-os.html.

[48]

OASIS Security Services (SAML) TC, zie http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=security.

[49]

M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams, X.509 Public Key Infrastructure: Online Certificate Status Protocol - OCSP, RFC 2560, The Internet Engineering Task Force, juni 1999, zie http://tools.ietf.org/html/rfc2560.

[50]

M. Mealling, Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS, RFC 3401, IETF, 2002.

[51]

P. Harding, L. Johansson en N. Klingenstein, Dynamic Security Assertion Markup Language: Simplifying Single Sign-On, IEEE Security & Privacy, Volume 6, uitgave 2, maart-april 2008, pagina’s 83-85.

[52]

Adding trust to dynamic saml, zie https://rnd.feide.no/content/explaining-delegatedmetadata.

[53]

SAML V2.0 Metadata Extension for Entity Attributes, november 2008, zie http://wiki.oasis-open.org/security/SAML2MetadataAttr.

[54]

Leif Johansson, Licensing Federation Metadata, Oktober 2007, zie http://blogs.su.se/leifj/Identity/leifj-ujLNyYVg.

Schaalt dat?

55

[55]

J.F. Zandbelt , R.J. Hulsebosch , M.S. Bargh en R. Arends, Trusted Directory Services for Secure Internet Connectivity, Electronic Notes in Theoretical Computer Science (ENTCS), v.197 n.2, pagina’s 91-103, februari 2008.

[56]

R.J. Hulsebosch, M.S. Bargh, P.H. Fennema, J.F. Zandbelt, M. Snijders en E.H. Eertink, Using Identity Management and Secure DNS for Effective and Trusted User Controlled Light-Path Establishment, in de Proceedings of the international Conference on Networking and Services , juli 16 - 18, 2006.

[57]

S. Chokhani et al., Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, Request for Comments 3647, november 2003, zie http://www.ietf.org/rfc/rfc3647.txt.

[58]

Exostar Federated IdM Policy and Practice Statements (FIdPPS) raamwerk, zie www.exostar.com.

[59]

Rodney McDuff en Viviani Paz, SAML Metadata Signing Policy and Aggregation Practice Statement Draft Framework, gepresenteerd tijdens REFEDS, 5 december, 2008, zie http://www.terena.org/activities/refeds/meetings/dec08/slides/SAML-MetadataAggregation-Practice-Statement.pdf.

[60]

Extended Validation (EV) Certificaat, zie http://en.wikipedia.org/wiki/Extended_Validation_Certificate.

[61]

Microsoft Security Intelligence Report, volume 6, juli - december 2008, zie http://www.microsoft.com/downloads/details.aspx?FamilyID=aa6e0660-dc24-4930affd-e33572ccb91f&displaylang=en.

56


Vertrouwen in de SURFfederatie: schaalt dat?

Recommend Documents