User controlled privacy voor de SURFfederatie

Transcriptie

1 User controlled privacy voor de SURFfederatie Project : SURFworks SURFfederatie PoCs Projectjaar : 2009 Projectmanager : Remco Poortinga-Van Wijnen, Roland van Rijswijk Auteur(s) : Maarten Wegdam & Bob Hulsebosch (Novay) Opleverdatum : 25 augustus 2009 Versie : 1.1 Synopsis In dit rapport wordt geanalyseerd hoe user controlled privacy functionaliteit aan de SURFfederatie kan worden toegevoegd. Specifiek wordt bekeken hoe dit gedaan zou kunnen worden door het gebruik van InfoCards, dan wel door user controlled privacy functionaliteit toe te voegen aan het SAML WebSSO profiel. Voor deze publicatie geldt de Creative Commons Licentie Attribution- Noncommercial- Share Alike 3.0 Netherlands. Meer informatie over deze licentie is te vinden op nc- sa/3.0/nl/

2

3 Colofon Programmalijn Onderdeel Activiteit Deliverable Toegangsrechten Externe partij : SURFworks : SURFfederatie PoCs : User controlled privacy : Rapport User controlled privacy voor de SURFfederatie : publiek : Novay 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 (

4 Context 5 dingen die je moet weten over User Controlled Privacy in de SURFfederatie Er wordt steeds meer informatie over mensen opgeslagen in (gekoppelde) computersystemen; dit heeft een grote impact op de privacy. SURFnet heeft in dit kader ook een verantwoordelijkheid tegenover de eindgebruikers van de SURFfederatie Wat is het? De kerngedachte achter User Controlled Privacy is om de gebruiker in staat te stellen beslissingen te nemen met betrekking tot de gegevens die over hem of haar gedeeld worden. In de huidige opzet van de SURFfederatie ligt de controle hierover bij de instelling van de eindgebruiker Voor wie is het? Alle op de SURFfederatie aangesloten instellingen en hun eindgebruikers Hoe werkt het? Er zijn twee manieren om de gebruiker meer controle te geven: User Centric Identity hierbij wordt de gebruiker centraal gesteld en loopt alle gegevensuitwisseling expliciet via de gebruiker User Controlled Privacy hierbij wordt de gegevensuitwisselingen door derden uitgevoerd maar alleen met expliciete toestemming (consent) van de gebruiker Wat kan je ermee? Als gebruiker bepalen welke informatie over je gedeeld wordt via de SURFfederatie 4

5 Management Samenvatting De huidige SURFfederatie biedt gebruikers weinig actieve controle over hun privacy. Privacy is op dit moment een hot issue zowel in de media als op het internet (denk aan: EPD, biometrisch paspoort, kinddossier). Daarnaast zijn er op het internet sterk opkomende user centric identity benaderingen zoals OpenID en Information Cards (InfoCards), die gebruikers wel controle geven over hun privacy. Zowel om de gebruikersacceptatie vast te houden en te vergroten als vanwege ethische en juridische redenen is het toevoegen van user controlled privacy functionaliteit aan de SURFfederatie zeer wenselijk. In dit rapport wordt geanalyseerd hoe dit gedaan kan worden. De twee meest voor de hand liggende manieren om dit te doen zijn: het gaan ondersteunen van de user-centric identity standaard InfoCards het toevoegen van user controlled privacy als een additionele functionaliteit aan de huidige, vooral SAML (WebSSO profiel) gebaseerde, SURFfederatie. Het toevoegen van InfoCards biedt een deeloplossing. Het werkt namelijk alleen voor service providers die InfoCards ondersteunen. InfoCards heeft als nadelen dat gebruikers client software moeten installeren en dat de architecturele inpassing in de SURFfederatie complex is. Daarnaast heeft InfoCards zich in de praktijk nog nauwelijks bewezen. Het toevoegen van user controlled privacy aan SAML WebSSO zou op vergelijkbare wijze werken als dit gebeurt bij de in opkomst zijnde OpenID identity specificatie. Dit is eenvoudiger en kan op kortere termijn gerealiseerd worden dan InfoCards toevoegen aan de SURFfederatie. Het kan namelijk als functionaliteit aan de SURFfederatie hub worden toegevoegd zonder dat identity providers, service providers of eindgebruikers software hoeven te installeren of aan te passen. De gebruiker zal dan tijdens het inloggen door de hub om consent gevraagd worden over welke attributen uitgewisseld mogen worden. Er zijn veel mogelijkheden en dus ook keuzes die gemaakt moeten worden over de precieze invulling van gebruikerscontrole. In dit rapport wordt op basis van academische literatuur op het gebied van controle over privacy en de state-of-the-art in OpenID en SAML WebSSO een concreet voorstel gedaan voor een set van richtlijnen ( 4.1) om deze keuzes te sturen: Richtlijn 0: Consent - Altijd consent vragen voordat er informatie gedeeld wordt, en de gebruikers laten bepalen voor welke attributen zij wel of geen consent geven. Richtlijn 1: Inzicht Zorg ervoor dat de gebruikers goed begrijpen welke consent zij (niet) geven, en wat de gevolgen zijn. Richtlijn 2: Automatiseren Reduceer de intrusiveness door het mogelijk te maken consent te geven voor informatie uitwisseling bij toekomstige logins, binnen een beperkte periode. Richtlijn 3: Notificatie Informeer de gebruiker welke informatie uitgewisseld wordt op het moment dat het gebeurt, ook als consent in verleden al gegeven is. Richtlijn 4: Revocatie Geeft inzicht in verleende consent en maak het makkelijk om deze in te trekken. Als vervolg op dit project zal een kwalitatieve gebruikersstudie worden uitgevoerd om te bepalen of gebruikers van de SURFfederatie de voorkeur geven aan de huidige situatie zonder gebruikerscontrole, of aan controle over hun privacy d.m.v. InfoCards of d.m.v toevoegen van user controlled privacy aan SAML WebSSO. SURFWORKS UCP IN DE SURFFEDERATIE 5

6 Inhoudsopgave 1 Inleiding Achtergrond & probleemstelling Analyse & doelstelling Scoping & terminology Leeswijzer 9 2 Overzicht van de oplossingen InfoCards OpenID User control in SAML (en Liberty Alliance) SUN applet demo SAML Enhanced Client or Proxy ID-WSF Liberty Advanced Client Technologies LA Interaction Service Consent module van SimpleSAMLphp (WAYF, Feide) uapprove voor Shibboleth (SWITCH) OAuth Vendor Relationship Management en ProtectServe protocol Conclusies 24 3 Toevoegen van InfoCards aan de SURFfederatie Geschakelde STS-es en de IdP als uitgever van InfoCards Geschakelde STS-es en de SURFfederatie als uitgever van InfoCards De hub als uitgever en als enige met een STS Meerdere hubs Samenvatting 32 4 Toevoegen van user-control aan SAML WebSSO Hoog niveau ontwerp richtlijnen Uitwerking ontwerp richtlijnen Gebruikersinteractie mock-ups Architecturele inpassing in SURFfederatie Samenvatting 39 5 Privacy en juridische verantwoordelijkheid 40 6 Conclusies 43 Referenties 46 6 NOVAY

7 1 Inleiding De SURFfederatie stelt studenten en werknemers in het hoger onderwijs in staat om op een betrekkelijk eenvoudige en gebruiksvriendelijke manier toegang te krijgen tot online diensten. In een federatieve identiteitsmanagement infrastructuur logt een gebruiker met één gebruikersnaam/wachtwoord combinatie in (Single Logon) en hoeft een gebruiker zich meestal slechts één keer te authenticeren (Single Sign-on) om vervolgens toegang te krijgen tot meerdere diensten. De identiteitsmanagement infrastructuur zorgt ervoor dat identiteitsgegevens op de juiste manier tussen de betrokken partijen worden gecommuniceerd. De betrokken partijen zijn: Identiteitsproviders (IdPs) de aangesloten instellingen (universiteiten, etc.), deze hebben gebruikers; Service providers (SPs) 1 de aanbieders van online diensten, bijvoorbeeld een uitgever van online studiemateriaal; Gebruikers werknemers en studenten van de aangesloten instellingen; SURFnet als federatie operator. De SURFfederatie heeft een zogenaamde hub-architectuur, waarbij SURFnet centrale componenten aanbiedt om het aansluiten op de SURFfederatie te vergemakkelijken. Ook verloopt de communicatie van alle identiteitsgevens via de hub. Voor meer informatie over de SURFfederatie, zie Achtergrond & probleemstelling In de SURFfederatie wordt privacy gevoelige informatie over gebruikers uitgewisseld en opgeslagen, zoals naam, studie, adres en welke online diensten worden gebruikt. Er zijn ethische, juridische en gebruiksacceptatie redenen om de gebruiker controle te geven over deze privacy gevoelige data. Dit kan in de vorm van toestemming ofwel consent van de gebruiker. Voor veel internetdiensten komt consent vaak neer op een onbegrijpelijk takeall/leave-all vinkje of impliciete consent met een link ergens onderaan een pagina. Het uitgangspunt van dit rapport is om te onderzoeken hoe gebruikers daadwerkelijke informed consent geboden kan worden; met andere woorden: hoe user controlled privacy als functionaliteit aangeboden zou kunnen worden in de SURFfederatie. Er is een trend in de identity community om voor internetdiensten naar zogenaamde user centric identity oplossingen te gaan, met OpenID en InfoCards als concrete specificaties hiervoor. Deze specificaties zijn gemaakt vanuit de gedachte dat de gebruiker controle moet hebben over zijn of haar privacy. Dit in tegenstelling tot zogenaamde IdP centric standaarden, zoals bijvoorbeeld SAML, waar de SURFfederatie op is gebaseerd. SAML, en de meeste implementaties van SAML, bieden geen of erg beperkte controle door de gebruiker over zijn of haar privacy. 1.2 Analyse & doelstelling Zoals al gesuggereerd wordt in de vaak gebruikte term informed consent, is het nodig dat de gebruiker begrijpt (informed) waar hij consent voor geeft. Anders gesteld, om gebruikers controle te kunnen geven over hun eigen privacy moeten zij eerst begrijpen welke data er potentieel en daadwerkelijk 1 Een andere term voor Service Provider is Relying Party (RP). SURFWORKS UCP IN DE SURFFEDERATIE 7

8 over hen uitgewisseld wordt. Het voor gebruikers begrijpelijk maken welke controle ze (kunnen) hebben is een hele grote zo niet de grootste uitdaging bij het realiseren van user controlled privacy. Door in een identiteitsfederatie (online) ondersteuning hiervoor te bieden kan dit begrip toenemen. Dit betekent typisch dat, op het moment dat er identiteitsgegevens worden uitgewisseld tijdens het gebruik van online diensten, de gebruiker hier inzicht in krijgt. Naast inzicht op moment van uitwisselen, is het wenselijk achteraf inzicht te geven over de uitgewisselde data. Dit inzicht achteraf vereist logging 2. De praktijk van een single sign-on (SSO) gebruikerservaring voor IdP centric 3 identity benaderingen, zoals in SAML Web Browser SSO Profile (WebSSO ), is meestal dat een gebruiker eenmalig inlogt, waarna het inlogproces volledig onzichtbaar is voor de gebruiker. Bij het verkrijgen van toegang tot andere websites (of diensten), kan het heel goed dat de gebruiker niet eens beseft dat hij opnieuw inlogt, laat staan met welke identiteit dit gebeurt en welke data er uitgewisseld wordt. Hoewel zeker gebruiksvriendelijk en non-intrusive, draagt dit niet bij aan het begrip bij de gebruiker, en is er eigenlijk geen sprake van user controlled privacy. InfoCards is een user centric identity benadering die een kaart model heeft geadopteerd in een poging om de begrijpelijkheid van wat er gebeurt te verhogen. InfoCards geeft de gebruiker inzicht in de uitgewisselde informatie, en vraagt expliciet om consent. Enigszins afhankelijk van de implementatie, is het dan ook geen pure SSO. Bijvoorbeeld: in Microsoft s CardSpace implementatie moet de gebruiker bij elke login opnieuw zijn kaartje 4 selecteren. InfoCards is wel SSO in die zin dat de gebruiker in de meeste gevallen niet telkens opnieuw een gebruikersnaam/wachtwoord hoeft in te geven. OpenID is een user centric identity benadering die net als SAML WebSSO werkt met redirects tussen SP en IdP. OpenID wordt tot de user centric identity benaderingen gerekend onder andere vanwege de in implementaties gebruikelijke gebruikerscontrole over welke informatie wordt uitgewisseld. Een belangrijk verschil met SAML WebSSO ligt op het vlak van het trustmodel: in tegenstelling tot wat gebruikelijk is bij SAML (circle of trust) gaat OpenID er niet vanuit dat er een vertrouwensrelatie is tussen de IdP en de SP. De doelstelling van dit rapport is te analyseren hoe user controlled privacy functionaliteit aan de SURFfederatie toegevoegd zou kunnen worden. 1.3 Scoping & terminology De focus ligt in dit rapport op uitwisseling van persoonlijke data, niet op bijvoorbeeld controle op de opslag of het gebruik van deze persoonlijke data. In dit rapport worde drie wat overlappende termen gebruikt: consent, user controlled privacy en user centric identity. Consent refereert naar de toestemming van een gebruiker om privacy gevoelige informatie te delen of op te slaan, en is ook een term die in juridische kringen gebruikt wordt. Dit rapport heeft een sterke gebruikersinsteek, en onderzoekt hoe gebruikers een fijnmazige controle gegeven kan worden over hun online privacy Wat overigens zelf weer privacy aspecten met zich meebrengt omdat dit het bewaren van log data vereist (dit wordt behandeld in hoofdstuk 5). SAML Web Browser SSO profile wordt afgekort tot SAML WebSSO in dit rapport. In de beta van de nieuwere Microsoft InfoCard client Geneva zijn wel opties zijn om dit automatisch te doen voor specifieke sites. 8 NOVAY

9 Consent wordt soms geassocieerd met de op internet gebruikelijke takeall/leave-all checkboxes onder een pagina met vaak onbegrijpelijke gebruiksen privacy voorwaarden, danwel met offline consents. Om deze reden wordt in dit rapport vaak de voorkeur gegeven aan de term user controlled privacy. Het is echter een vrij willekeurige keuze; daarom wordt de term consent ook zo nu en dan gebruikt. De derde gerelateerde term is user centric identity, wat refereert naar een identity oplossing die de gebruiker in plaats van de IdP centraal stelt. Dit impliceert natuurlijk een vorm van user controlled privacy. Hoewel dit rapport in het Nederlands is opgesteld, is er bewust voor gekozen Engelse vaktermen, zoals bijvoorbeeld Identity Provider, assertions en Service Provider niet te vertalen. 1.4 Leeswijzer De structuur van dit rapport is als volgt: het hierna volgende hoofdstuk 2 geeft een overzicht van verschillende oplossingen voor het creëren van user controlled privacy en beschrijft de toepasbaarheid hiervan voor de SURFfederatie. Hoofdstuk 3 analyseert in meer technisch detail de mogelijkheden van het introduceren van InfoCards in de SURFfederatie. Hoofdstuk 4 gaat verder in op de mogelijkheid voor het toevoegen van user control aan IdP centric oplossingen als SAML. Aan de hand van onder andere gebruikersinteractie mock-ups wordt geïllustreerd hoe dit zou kunnen uitpakken. De juridische kant van user controlled privacy wordt behandeld in hoofdstuk 5. Tot slot worden in hoofdstuk 6 de conclusies van het onderzoek gepresenteerd. De auteurs van dit rapport danken Hans Zandbelt, Roland van Rijswijk, Remco Poortinga-Van Wijnen en Robert de Groote voor hun input en feedback. SURFWORKS UCP IN DE SURFFEDERATIE 9

10 2 Overzicht van de oplossingen Het doel van dit hoofdstuk is om op een hoog niveau te beschrijven wat de huidige state-of-the-art is ten aanzien van user controlled privacy in identiteitsfederaties, en hieruit bruikbare oplossingsrichtingen te selecteren voor de SURFfederatie. Specifiek wordt beschreven hoe gebruikers controle hebben over hun privacy in de drie bekendste federatiespecificaties: InfoCards, OpenID en SAML. Daarnaast worden gerelateerde ontwikkelingen beschreven zoals OAuth, Vendor Relationship Management en ProtectServe. Dit is ongetwijfeld geen compleet overzicht, maar bevat wel de voornaamste oplossingen in termen van bekendheid en impact. 2.1 InfoCards Een Information Card ofwel InfoCard is een visuele representatie van een digitaal identiteitsbewijs. Om het voor gebruikers duidelijk te maken hoe digitale identiteitsbewijzen gebruikt kunnen worden, is ervoor gekozen de metafoor van het visitekaartje (of de creditcard) in een portefeuille te gebruiken. De visuele weergave van het digitale identiteitsbewijs lijkt dan ook sterk op die van een fysiek kaartje. Figuur 1 geeft een voorbeeld van een Identity Selector (de component die op het client device draait en de gebruikersinterface vormt de portefeuille) en de InfoCards daarin. Figuur 1 Screendump CardSpace implementatie van de Identity Selector Een InfoCard kan door iemand worden gebruikt om zich aan te melden op een website, zonder een gebruikersnaam of een wachtwoord dat specifiek is voor die website op te hoeven geven. Hoewel het lijkt op single sign-on (SSO) is dit het strikt genomen niet. In de huidige implementaties zal de gebruiker voor iedere nieuwe dienst opnieuw een InfoCard moeten selecteren. Ook moet de gebruiker zich authenticeren tegenover de IdP die de InfoCard heeft uitgegeven, wat afhankelijk van het door de IdP gekozen authenticatiemiddel een gebruikersnaam/wachtwoord van de gebruiker kan vragen. Alle persoonsgegevens lopen via de Identity Selector, die de gebruiker notificeert en faciliteert in het verlenen van toestemming. Er bestaan twee soorten kaarten: 10 NOVAY

11 De managed card, dit is een InfoCard die wordt uitgegeven door een externe Identity Provider (IdP). Hierbij is er een directe link tussen de Identity Selector en de IdP, waardoor ten opzichte van de typische gebruikersnaam/wachtwoord authenticatie bij WebSSO identiteitsfederatie oplossingen phishing veel lastiger is. Dit komt doordat tijdens het aanmaken van de managed card er sleutels uitgewisseld kunnen worden tussen de IdP en de Identity Selector die ervoor zorgen dat beide partijen zeker weten met wie ze praten. De self-issued card, een kaart die een gebruiker zelf kan creëren. De gebruiker is als het ware zijn eigen IdP. Dit wordt typisch gebruikt als een SP geen claims nodig heeft van een vertrouwde IdP, maar wel een gepersonaliseerde dienstverlening heeft waarvoor het nodig is de gebruiker te herkennen. Naast de identificerende gegevens (zoals een gebruikersnaam), kan een InfoCard ook aanvullende gegevens bevatten. Deze gegevens of attributen worden in de vorm van claims opgenomen in het digitale identiteitsbewijs. Let wel, in het geval van een managed card staan de gegevens zelf niet in de InfoCard maar worden na het selecteren van de kaart door een Secure Token Service (STS) van de IdP in een token gezet dat doorgegeven wordt aan de SP. De gebruikelijke berichtenuitwisseling tussen de verschillende InfoCards componenten is als volgt: 1. De eindgebruiker gaat naar een SP toe. 2. SP heeft een policy die aangeeft wat nodig is om toegang te krijgen tot de dienst (welke attributen, welke IdPs deze kunnen aanleveren, etc.). 3. De Identity Selector selecteert de InfoCard(s) die voldoen aan de policy. 4. De gebruiker selecteert het gewenste kaartje. 5. De STS van de IdP achter de InfoCard krijgt het verzoek een token te genereren. 6. De inhoud van het token wordt getoond aan de gebruiker en er wordt gevraagd of het token doorgestuurd mag worden naar de SP. 7. Het token wordt doorgestuurd naar de SP en de gebruiker krijgt toegang tot de aangeboden dienst. Dit is grafisch weergegeven in Figuur 2. SP Policy IdP STS Browser ID Selector User Figuur 2 InfoCard berichtenuitwisseling SURFWORKS UCP IN DE SURFFEDERATIE 11

12 De gebruiker bevindt zich dus continu in het communicatiepad tussen de SP en de IdP. De Identity Selector geeft hem steeds de controle over de uitgewisselde informatie en dus in zekere zin over zijn privacy. Er zijn inmiddels Identity Selectors voor de meest gebruikte computersystemen: CardSpace - De Identity Selector van Microsoft Windows Vista en Windows XP (met Service Pack 3) heet CardSpace. DigitalMe - Voor Apple's Mac OS is DigitalMe ontwikkeld door Novell, waarvan inmiddels ook versies voor diverse Linux distributies beschikbaar zijn. Higgins - Novell en andere partijen hebben het Higgins raamwerk ontwikkeld, dat ook de InfoCards specificatie implementeert. Azigo Deze implementatie is op Higgins gebaseerd [1], en werkt op Windows (Internet Explorer en Firefox) en Mac OS X (Firefox). OSIS is een open source Identity Selector. De InfoCards Identity Selector specificatie is recent (juli 2009) een formele OASIS standaard geworden [2]. Inherent aan de kaartjes is dat deze ergens bewaard moeten worden. De meeste Identity Selector implementaties doen dat lokaal op het systeem van de gebruiker. Dit is lastig als een gebruiker over meerdere apparaten beschikt, bijvoorbeeld een PC en een laptop of meerdere PCs. De Azigo implementatie vormt hierop een uitzondering, hier worden de kaartjes op een 5 server bij Azigo opgeslagen. 2.2 OpenID Ook OpenID is een oplossing voor het gebruik van dezelfde digitale identiteit voor vele websites. Het elimineert de noodzaak van meerder gebruikersnamen en wachtwoorden voor verschillende websites, en heeft mogelijkheden voor het uitwisselen van attributen. OpenID is een open specificatie en wordt samen met InfoCards vaak onder user centric identity geschaard. Momenteel is versie 2 beschikbaar. De laatste jaren is OpenID aan een grote opmars bezig. Steeds meer grote partijen ondersteunen het nu, en zijn OpenID identity provider geworden (bijvoorbeeld Google, Yahoo en Hyves). Aan de accepterende, Service Provider (of Relying Party in OpenID terminologie), kant gaat de ondersteuning langzamer. OpenID werkt op basis van URLs of XRIs voor het identificeren van de gebruiker en maakt hierbij gebruik van redirects tussen de SP en de IdP. De berichtenstroom is als volgt: 1. De gebruiker voert een OpenID URL in bij de SP om het inlogproces te starten. 2. De SP leidt uit de URL af wat de IdP van de gebruiker is en creëert een geheim met deze IdP. Deze stap is optioneel. 3. De SP stuurt de gebruiker door naar de gevonden IdP middels een redirect. 5 We konden geen informatie op de Azigo website vinden die bevestigt dat de kaartjes op de server worden opgeslagen, maar een voorbeeld van een blog die beweert dat Azigo dit doet is 12 NOVAY

13 4. De IdP verzoekt de gebruiker zichzelf te authenticeren. Het resultaat wordt, eventueel aangevuld met attributen, weer teruggestuurd naar de gebruiker via opnieuw een redirect. 5. De gebruikersgegevens worden teruggestuurd naar de browser. 6. En via een redirect doorgestuurd naar de SP waarop de gebruiker toegang krijgt tot de dienst. Figuur 3 illustreert de OpenID berichtenuitwisseling. SP IdP Browser 4 1 User Figuur 3 OpenID berichtenuitwisseling Als de gebruiker naar een andere dienst gaat die OpenID ondersteunt hoeft hij zich niet opnieuw te authenticeren. De redirects gebeuren dan als een pure SSO zonder dat de gebruiker iets hoeft te doen. Afhankelijk van de implementatie moet de gebruiker wel telkens consent geven. Over de betrouwbaarheid van OpenID zijn nog wel wat twijfels. OpenID is door zijn redirect mechanisme kwetsbaar voor phishing. Deze kwetsbaarheid is op te lossen door in plaats van de gebruikelijke gebruikersnaam en wachtwoord combinatie een phishing proof authenticatie middel te gebruiken, zoals een InfoCard. Ook het ontbreken van out-of-band geregelde trust tussen SP en IdP maakt dat de betrouwbaarheid minder goed geregeld kan worden. Hoewel OpenID als een user-centric benadering wordt gezien, zegt de specificatie niks over het user consent model, dit is aan de implementatie. De meeste zo niet alle implementaties bieden echter wel een vorm van consent. De gebruiker kan dan beslissen of de informatie wel of niet doorgestuurd zal worden. In sommige implementaties kan de gebruiker zelf attributen aan of uitvinken. De meeste implementaties geven ook de mogelijkheid om aan te geven dat consent always geldt, dus ook voor toekomstige bezoeken op die specifieke website. Een uitzondering lijkt te zijn de VeriSign Labs OpenID IdP implementatie (pip.verisignlabs.com) die het mogelijk maakt een verloopdatum op te geven voor de consent (naast never expire en expire after signing in ), en een log kan laten zien op welke sites in het verleden is ingelogd. Hieronder geeft Figuur 4 een voorbeeld van consent bij Google (met een popup en zonder mogelijkheid tot uitvinken van attributen) en Figuur 5 bij Hyves (zonder popup, met mogelijkheid tot uitvinken van attributen). SURFWORKS UCP IN DE SURFFEDERATIE 13

14 Figuur 4 Voorbeeld OpenID user consent bij Google Figuur 5 Voorbeeld OpenID user consent bij Hyves Een implementatie die op een heel andere manier de gebruikersinteractie vormgeeft is de Higgins cloud selector [3], die een OpenID IdP implementeert die een gebruikersinterface biedt die lijkt op een InfoCard selector ( Figuur 6). De kaartjes komen hierbij overeen met InfoCard kaartjes, waarbij de attributen uit het InfoCard token worden gehaald en via de OpenID protocollen worden doorgegeven. Als toekomstige functionaliteit wordt genoemd dat de originele InfoCard tokens ook 14 NOVAY

15 doorgegeven kunnen worden aan de RP/SP, maar dat zou wel aanpassingen aan de OpenID software van de RP/SP vereisen. Figuur 6 Higgins Card Selector OpenID IdP user control interface 2.3 User control in SAML (en Liberty Alliance) De SAML protocollen beschrijven de manier waarop assertions worden uitgewisseld. Hoe hier echter consent voor wordt verleend ligt buiten de scope van SAML 6. Ook over notificatie zegt SAML niks. SAML is in de meeste gevallen geïmplementeerd via de HTTP redirect/post binding. In dit profiel wordt de gebruiker van de SP naar IdP geredirect en, indien al ingelogd, vaak terug geredirect zonder een vorm van gebruikers notificatie of interactie. Hoewel het zeker bijdraagt aan een naadloze SSO, zorgt dit er voor dat de gebruiker niet weet dat privacy gevoelige data wordt uitgewisseld, of anders gesteld, er is geen sprake van een notificatie. In diverse Liberty Alliance (LA) whitepapers en presentaties wordt overigens wel gesproken over consent, maar meer in termen dat dit aangeboden zou moeten worden. Er is geen daadwerkelijk consent specificatie. Het is wel mogelijk om binnen de SAML specificatie consent aan te bieden, en er zijn LA specificaties die mogelijkheden bieden om consent te implementeren. De volgende vier mogelijkheden worden kort in deze sectie besproken: SUN applet demo; SAML Enhanced Client or Proxy; ID-WSF Liberty Advanced Client Technologies; LA Interaction Service. 6 Er is in SAMLv2 alleen een optionele consent identifier die aangeeft of er consent is. SURFWORKS UCP IN DE SURFFEDERATIE 15

16 In de twee secties daarna worden vanwege de relevantie voor dit rapport twee redirect gebaseerde implementaties gedetailleerder besproken SUN applet demo Dit is een demo die consent, notificatie en attribuutprovider selectie combineert [ 4]. In de demo laadt de SP een ondertekende applet van de IdP. De gebruiker logt via deze applet in. Hiervoor wordt de LA Authentication Service gebruikt (SASL protocol). Na authenticatie kan de gebruiker kiezen tussen verschillende attribuutproviders om te selecteren of en zo ja welke attributen en attribuutprovider gebruikt wordt. Het voordeel van deze applet benadering is dat aangezien de applet van de IdP is de IdP daar op een SAML/LA compliant manier een gebruiksvriendelijke notificatie en consent interface kan bieden. Een groot security probleem van deze applet benadering is dat het waarschijnlijk erg onduidelijk zal zijn voor de gebruiker dat deze applet van de IdP is, hij is zelfs ingebed binnen de webpagina van de SP. Theoretisch zou de gebruiker de signature op de applet kunnen controleren, maar dat dit gebeurt is erg onwaarschijnlijk, en in tegenstelling tot normale web redirects is de URL niet zichtbaar voor de gebruiker. Dit maakt deze oplossing erg kwetsbaar voor phishing. SAML Enhanced Client or Proxy Het Enhanced Client or Proxy SAML profiel kan gebruikt worden om controle te geven aan de gebruiker, in plaats van onzichtbare redirects. Het SAML ECP profiel is onderdeel van de SAML 2.0 specificatie en is feitelijk een doorontwikkeling van het door Liberty Alliance gespecificeerde Liberty-enabled client or proxy profile. SAML ECP kan geïmplementeerd worden als een browser plug-in en kan dan authenticatieverzoeken afhandelen. Een SP kan hierdoor op een verzoek van de gebruiker gewoon antwoorden met een authenticatieverzoek. Een redirect is dus niet meer nodig. De berichtenstroom is weergegeven in Figuur NOVAY

17 Figuur 7 SAML ECP berichtenstroom SAML en Liberty Alliance voorstanders beweren dat een uitgebreide SAML ECP implementatie eenvoudig gebruikt kan worden voor vergelijkbare functionaliteiten als een InfoCards Identity Selector biedt. Dat zou dan moeten gebeuren bij stap 3 in de bovenstaande figuur, bijvoorbeeld in de vorm van een Higgins s-card 7. Er zijn weinig indicaties dat SAML ECP in de praktijk inderdaad gebruikt gaat worden om gebruikers controle te geven over hun privacy. Er zijn weinig browsers die een SAML ECP implementatie bieden; Firefox is een van de weinige browsers waarvoor een SAML ECP plugin beschikbaar is [ 5]. SAML ECP kan ook gebruikt worden in combinatie met Web Services, zie [6] ID-WSF Liberty Advanced Client Technologies Liberty s Advanced Client Technologies is een doorontwikkeling van SAML ECP. De Advanced Client maakt gebruik van zogenaamde Trusted Modules (TMs) die een verlengstuk vormen van de IdP [ 7]. Zelfs als de IdP offline is kan er met de TM identiteitsinformatie uitgewisseld worden. Een typisch voorbeeld van een TM is de SIM kaart in een mobiele telefoon. De Advanced Client is hierdoor ook geschikt om user consent functionaliteit te bieden. Helaas zijn er nog geen implementaties van de Advanced Client, laat staan een die de gebruiker betrekt in de communicatieflow. 7 Een Higgens s-card is een SAML information card, zie org.eclipse.higgins.doc/higgins-overview-2009.pdf. SURFWORKS UCP IN DE SURFFEDERATIE 17

18 2.3.4 LA Interaction Service De Interaction Service is onderdeel van de Liberty Alliance Web Services Framework (WSF, [ 8]). De motivatie voor het specificeren van de Interaction Service komt voort uit scenario s waarin webservices onder water allerlei persoonlijke informatie uitwisselen om te komen tot een gepersonaliseerde dienstverlening. De Interaction Service kan gebruikt worden om de gebruiker meer inzicht en controle te geven in dit proces. Dit is weergegeven in Figuur 8 waarin een web service consumer (WSC) names gebruiker 1 (linker user agent) een andere web service provider (WSP) om privacy gevoelige informatie van gebruiker 2 (rechter user agent) vraagt. De WSP informeert de Interaction Service (IS) hiervan, die op zijn beurt weer gebruiker 2 via de user agent om consent vraagt. De IdP kan in dit proces de rol van WSP op zich nemen, de SP is dan de WSC. Figuur 8 Liberty Alliance Interaction Service (IS) Op zichzelf lijkt de Interaction Service geschikt voor het realiseren van usercontrolled privacy. Echter, de Interaction Service specificatie beperkt zich tot de interface tussen de web service en de Interaction Service, en specificeert niet hoe de interactie werkt tussen Interaction Service en een user device of agent. Dit vereist dus gebruik van generieke interactiemogelijkheden zoals SMS of of een proprietary client. Daarnaast is er vanuit de webservice een erg beperkte controle over de user interface, en hoe deze op het user device (webpagina, mobiele telefoon, etc.) zichtbaar gemaakt wordt. Hierdoor is de bruikbaarheid van de Interaction Service in de praktijk erg beperkt [9]. 2.4 Consent module van SimpleSAMLphp (WAYF, Feide) Zoals ook in de vorige sectie beschreven, is de meest gebruikte binding in SAML de HTTP redirect/post binding 8 (WebSSO profiel), en wordt deze typisch geïmplementeerd op een manier dat de gebruiker hier niet mee lastig gevallen wordt. Deze manier van implementeren leidt tot een naadloze SSO gebruikerservaring, maar zorgt er ook voor dat de gebruiker niet begrijpt wat er gebeurt Er zijn subtiele verschillen tussen http redirect en POST, maar binnen de context van dit rapport zijn deze niet relevant, en verwijzen we voor het gemak vaak naar beiden als redirect. Zie ook Kim Cameron s mening hierover in zijn blog entry op 23 juni 2007: 18 NOVAY

19 Vergelijkbaar met hoe veel OpenID implementaties controle geven aan de gebruiker over welke data er gedeeld wordt, kan dit ook gedaan worden in SAML, namelijk als onderdeel van de redirect. We hebben twee implementaties gevonden die dit ook daadwerkelijk doen: SimpleSAMLphp en uapprove. Deze beschrijven we respectievelijk in deze en de volgende sectie. De consent module van SimpleSAMLphp SAMLv2 biedt user controlled privacy. Deze module is ontwikkeld door WAYF [10, 11], de Deense identiteitsfederatie voor het hoger onderwijs en onderzoek. Hij wordt gebruikt door WAYF en door de Noorse NREN Feide. Indien zo geconfigureerd, krijgt de gebruiker de eerste keer dat hij inlogt op een nieuwe service de lijst met attributen te zien die uitgewisseld zullen gaan worden. De gebruiker moet dan expliciet consent geven of deze lijst met attributen naar de SP mag worden gestuurd (zie Figuur 9). De gebruiker kan ervoor kiezen de consent te laten onthouden, en kan de consent eventueel later ook weer intrekken door gebruik te maken van de Consent Administration service. Figuur 9 Screendump van consent in SimpleSAMLphd Feide heeft een centralistische aanpak waarbij de consent dus ook bij Feide zelf wordt geïmplementeerd. WAYF heeft een meer hybride centraledecentrale aanpak die lijkt op de hub architectuur van de SURFfederatie. Consent is hier geïmplementeerd in de centrale component van WAYF zelf, en niet door de instellingen/idps, zie [12]. Hieronder staan nog twee screendumps om meer inzicht te geven hoe de consent module van SimpleSAMLphp werkt. Figuur 10 De interface om gegeven consent in te trekken SURFWORKS UCP IN DE SURFFEDERATIE 19

20 Figuur 11 Inzage in de persoonlijke informatie die is opgeslagen bij de IdP 2.5 uapprove voor Shibboleth (SWITCH) De Zwitserse NREN SWITCH heeft een consent module ontwikkeld genaamd uapprove voor Shibboleth [13, 14]. Het aanbieden van consent was een eis van verschillende Zwitserse universiteiten voordat ze zich aansloten bij de SWITCH identiteitsfederatie [14]. uapprove is sinds 2008 beschikbaar als open source project (en heeft een voorganger genaamd ArpViewer, gemaakt in 2007). uapprove biedt vergelijkbare notificatie en consent functionaliteit als de consent module van SimpleSAMLphp. In Figuur 12 is een screendump van het belangrijkste scherm te zien. 20 NOVAY