indi-2009-07-026 Cross Layer Identity Project: SURFworks Projectjaar : 2009 Projectmanager : Remco Poortinga van Wijnen Auteur(s) : Erik Sneep en Peter Clijsters (Everett) Opleverdatum : 27-07-2009 Versie : 1.0 Samenvatting Bij het gebruik van digitale diensten wordt geregeld geauthenticeerd voor het gebruik van bronnen in verschillende (OSI) lagen. Vaak vereisen die stappen het (herhaaldelijk) gebruik van credentials, vaak zelfs dezelfde credentials. In een ideaal gebruikersvriendelijk scenario zou authenticatie voor de verschillende lagen slechts eenmaal plaatsvinden en wordt een succesvolle authenticatie hergebruikt voor andere lagen en diensten, het zogenaamde unified Single Sign-On (usso). Dit rapport beschrijft de verschillende vormen van usso en de voor SURFnet meest relevante use case, namelijk usso tussen eduroam en de SURFfederatie. Voor deze use case worden vier verschillende technieken die als oplossing kunnen dienen beschreven (SAML, certificaten, Info Cards en Kerberos), samen met de voor- en nadelen van een oplossing met deze technieken. Na een samenvatting van de verschillende opties wordt uiteindelijk aanbevolen om een Proof of Concept (PoC) met Kerberos uit te voeren en wordt de technische opzet van de PoC beschreven. Voor deze publicatie geldt de Creative Commons Licentie Attribution-Noncommercial- 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 : SURFworks Onderdeel : SURFfederatie PoCs Activiteit : Cross Layer Identity Deliverable : Toegangsrechten : Publiek Externe partij : Everett 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). 2
Scenario 4 dingen die je moet weten over Cross Layer Identity Met één login gebruik kunnen maken van diensten verspreid over verschillende netwerk lagen, zodat unified Single Sign On (usso) mogelijk wordt. Wat is het? Mechanisme wat de klassieke, web gebaseerde SSO uitbreidt naar andere netwerk lagen. Voor wie is het? Voornamelijk eduroam aangesloten instellingen en SURFfederatie dienstenontwikkelaars en -aanbieders. Hoe werkt het? De login context van je instelling uitbreiden zodat deze geschikt wordt om bij eduroam en de SURFfederatie te gebruiken en mogelijk bij andere diensten. Wat kan je ermee? Geeft een (mobiele) eindgebruiker de mogelijkheid na de eduroam netwerk login naadloos toegang te krijgen tot een reeks diensten zonder opnieuw in te hoeven loggen. Extra (Bijlagen, Thema, Gerelateerde thema s) Geen 3
Inhoudsopgave 1 Inleiding...5 1.1 Achtergrond...5 1.2 Opdracht...5 1.3 Werkwijze...5 1.4 Scope...5 1.5 Leeswijzer...6 2 Cross Layer Identity in het algemeen...7 2.1 OSI Model...7 2.2 Unified SSO...8 2.3 Huidige situatie...8 2.4 SURFnet use case...8 3 Integratie SURFfederatie en eduroam...10 3.1 SAML...10 3.1.1 Bootstrapping SAML met eduroam...10 3.1.2 Voor- en nadelen...12 3.2 Certificaten...12 3.2.1 Certificaten voor eduroam en SURFfederatie login...12 3.2.2 Voor- en nadelen...13 3.3 Information Cards...14 3.3.1 Information Cards in het algemeen...14 3.3.2 Bootstrapping Information Card met eduroam...17 3.3.3 EAP-Infocard...19 3.3.4 Voor- en nadelen...20 3.4 Kerberos...21 3.4.1 Kerberos in het algemeen...21 3.4.2 Bootstrapping Kerberos met eduroam...23 3.4.3 Voor- en nadelen...24 4 Conclusie en aanbeveling...26 5 Proof Of Concept...28 4
1 Inleiding 1.1 Achtergrond Bij het gebruik van digitale diensten wordt geregeld op verschillende lagen van het OSI model (bijvoorbeeld netwerk, sessie, applicatie) geauthenticeerd voor het gebruik van bronnen in de desbetreffende laag. Vaak vereisen die stappen het (herhaaldelijk) gebruik van credentials, vaak zelfs dezelfde credentials. Denk bijvoorbeeld aan het gebruik van eduroam credentials voor wireless netwerk authenticatie en het authenticeren met een federatieve identiteit voor het gebruik van webgebaseerde diensten in bijvoorbeeld de SURFfederatie. In een ideaal gebruikersvriendelijk scenario zou authenticatie voor de verschillende lagen slechts eenmaal plaatsvinden en wordt een succesvolle authenticatie hergebruikt voor andere lagen en diensten. Waar de SURFfederatie in zijn huidige vorm Single Sign-On (SSO) biedt tussen webgebaseerde diensten (als het ware horizontaal ) wordt in dit project voorzien dat de federatieve identiteit over de verschillende netwerk lagen (MAC, IP, http) wordt hergebruikt (als het ware verticaal ), de zogenaamde unified Single Sign-On (usso). Daarnaast is het wenselijk dat dezelfde identiteit hergebruikt wordt voor niet webgebaseerde diensten zoals VOIP, IMAP mail en computing resources in het algemeen 1.2 Opdracht Om de mogelijkheden van unified SSO te verkennen heeft SURFnet aan Everett de opdracht gegeven een technologieverkenning omtrent dit onderwerp uit te voeren. Deze verkenning moet in ieder geval een overzicht geven van het krachtenveld rondom Cross Layer Identity en van de mogelijkheden om usso te implementeren in combinatie met de SURFfederatie. De technologieverkenning bestaat uit twee delen; een rapport en een Proof Of Concept (POC). Dit document bevat het rapport. De technologieverkenning als geheel moet genoeg informatie opleveren zodat SURFnet een beslissing kan nemen over het doorgaan met verdere dienstontwikkeling omtrent Cross Layer Identity. 1.3 Werkwijze Dit technologieverkenning rapport is geschreven vanuit de bij Everett aanwezige kennis over authenticatie methoden en middels onderzoek op internet. Daarnaast is regelmatig overleg geweest met de opdrachtgever en de verantwoordelijken voor de SURFfederatie en eduroam bij SURFnet. Hierbij ging het over de gewenste use cases, de mogelijke invulling ervan en de betekenis voor de SURFfederatie. 1.4 Scope De scope van de verkenning beperkt zich tot SURFnet en de aangesloten instellingen of leveranciers. Onderzoek naar Cross Layer Identity zal zich zoveel mogelijk richten op Open Standaarden. In een van de eerste overleggen met SURFnet over de scope van de opdracht is besloten het onderzoek in eerste instantie te beperken tot SSO tussen de SURFfederatie en eduroam. Binnen SURFnet en aangesloten instellingen is deze use case het meest relevant en het eerste waar mensen aan denken als gesproken wordt over usso. In tweede instantie zal gekeken worden naar de integratie met overige internet gebaseerde diensten zoals IMAP, VOIP, SSH, enz.
1.5 Leeswijzer Hoofdstuk 2 geeft een algemeen inzicht in wat met Cross Layer Identity en unified Single Sign-On (usso) wordt bedoeld en geeft de specifieke SURFnet use case die met dit rapport is onderzocht. Hoofdstuk 3 bevat een beschrijving van de vier onderzochte technieken om de use case mee in te vullen. Hier wordt verondersteld dat de lezer redelijk op de hoogte is van de werking van eduroam en de SURFfederatie. Hoofdstuk 4 bevat de conclusies en aanbevelingen naar aanleiding van de onderzochte technieken en hoofdstuk 5 bevat een voorstel voor de PoC opzet.
2 Cross Layer Identity in het algemeen Als er gesproken wordt over Cross Layer Identity moet er eerst duidelijk gemaakt worden wat hiermee precies wordt bedoeld en hoe dit mogelijk past binnen het SURFnet landschap. 2.1 OSI Model Als eerste zal duidelijk moeten zijn over welke lagen we het hebben. In dit onderzoek is uitgegaan van de OSI Model 1, welke uit zeven lagen bestaat (zie tabel 1). Dit model is een abstracte weergave voor gelaagde communicatie en computer netwerk ontwerp. Een bepaalde laag levert diensten aan bovenliggende lagen en neemt diensten af van onderliggende lagen. De idee is dat communicatie tussen dezelfde laag van verschillende computer systemen altijd door onderliggende lagen gaat. Zo zullen bijvoorbeeld twee applicaties die met elkaar communiceren in laag 7 (applicatie laag) gebruik maken van de onderliggende lagen zoals de transport, network, data link en fysieke laag. Merk op dat niet iedere laag altijd gebruikt hoeft te worden. Tabel 1 OSI Model Data unit Layer Function Examples 7. Application Network process to NNTP, SIP, DNS, application FTP, HTTP, NTP, SMTP, SNMP, Data Radius Host Layers Media Layers Segment Packet Frame Bit 6. Presentation Data representation and encryption MIME, XDR, SSL, TLS 5. Session Interhost communication Named Pipes, NetBIOS, SAP 4. Transport End-to-end TCP, UDP, PPTP, connections and L2TP, TLS reliability 3. Network Path determination IP, ICMP, IPsec, and logical IGMP addressing 2. Data Link Physical addressing ARP, CSLIP, SLIP, Frame Relay, EAP 1. Physical Media, signal and binary transmission 802.3 Ethernet, 10BASE-T, 100BASE-TX, POTS, DSL, 802.11a/b/g/n Veel eindgebruikers zullen gebruik maken van toepassingen die zich in de applicatie laag bevinden. Deze toepassingen maken op hun beurt vaak weer gebruik van de protocollen uit diezelfde laag die vervolgens weer leunen op protocollen uit onderliggende lagen. Applicaties die in een bepaalde laag zitten (vooral die in laag 7) kunnen authenticatie en/of autorisatie nodig hebben. De mechanismen verschillen, maar over het algemeen is toegang tot een account database nodig met bijbehorende account management faciliteiten zoals aanmaken, verwijderen en muteren van accounts. 1 OSI Model, http://en.wikipedia.org/wiki/osi_model
2.2 Unified SSO Veel applicaties worden gebruikt door dezelfde gebruikers zodat ook vaak dezelfde accounts en mogelijk hetzelfde account management systeem door meerdere toepassingen gebruikt kan worden. Daarnaast zijn specifieke technieken beschikbaar die voor een groep van hetzelfde type applicaties authenticatie en SSO kan leveren. Hierbij hoeven de gebruikers accounts dan niet direct beschikbaar gesteld te worden aan applicaties, maar kan op basis van vertrouwen de authenticatie door een andere partij uitgevoerd worden. Een goed voorbeeld hiervan is federatieve authenticatie zoals met de SURFfederatie is gerealiseerd voor web gebaseerde applicaties. Een ander voorbeeld is eduroam waarbij netwerk toegang verkregen kan worden op basis van accounts die op een andere locatie en door een andere organisatie worden geadministreerd. Meestal beperken deze federatieve technieken zich echter tot een bepaald type applicaties en bijna altijd tot een bepaalde laag in het OSI model. De uitdaging van dit onderzoek is nu om de mogelijkheden te onderzoeken van het hergebruik van een authenticatie voor de ene laag of applicatie type in een andere. Het ideale beeld hierbij is dat een gebruiker maar één keer hoeft in te loggen, waarna deze login wordt hergebruikt door alle applicaties. Zo zou de gebruikers login hergebruikt kunnen worden door de email voorziening (IMAP of SMTP), de kalender (ical), VOIP (SIP), het draadloos netwerk zoals eduroam (802.1x), file shares (SMB), de SURFfederatie (HTTP), Grid toegang (X.509) enz. Dit wordt unified Single Sign-On (usso) genoemd en is een uitbreiding van de klassieke SSO. Indien over SSO wordt gesproken wordt vaak SSO tussen websites bedoeld. Unified SSO verbreedt dit tot andere soorten toepassingen die zich soms ook nog in andere OSI lagen bevinden. Door deze eigenschappen van usso wordt dit ook wel een Cross Layer Identity genoemd. 2.3 Huidige situatie In de huidige situatie binnen de aangesloten instellingen van SURFnet, maar ook elders op het internet, moeten gebruikers apart inloggen voor verschillende diensten en federaties (zoals eduroam en SURFfederatie). De gebruikte credentials moeten hierbij opnieuw ingevoerd worden, maar vanwege cache features van de gebruikte client software (bv supplicant of browser) is de overlast daarvan beperkt. Wel speelt er duidelijk een security risico, de credentials staan immers op de harddisk van de gebruikers PC en de gebruiker moet meerdere credentials onthouden waardoor sommigen ervoor kiezen deze ergens te noteren. Door nu usso toe te passen wordt er op twee vlakken verbetering gerealiseerd: het security risico wordt uitgebannen en de gebruikerservaring wordt geoptimaliseerd. 2.4 SURFnet use case SURFnet houdt zich bezig met het ontwikkelen en ondersteunen van diensten die voor meerdere instellingen en tussen instellingen gebruikt kunnen worden. Een dienst die specifiek is voor één instelling en alleen door die instelling wordt gebruikt valt niet onder het doelgebied van SURFnet, tenzij de betreffende technologie breder ingezet kan worden. In het geval van usso zou dit betekenen dat authenticatie voor instellingsoverstijgende toepassingen gecombineerd worden. Mogelijk kan deze authenticatie vervolgens voor een instellingsspecifieke toepassing hergebruikt worden. Na overleg met SURFnet en gezien de beschikbare tijd voor het onderzoek is de use case die primair in dit onderzoek aan bod komt het hergebruiken van een login tussen de SURFfederatie en eduroam. Beide zijn bestaande, instellingsoverstijgende authenticatie diensten (federaties) die zich op verschillende lagen van het OSI model bevinden. Bij deze use case zal een eduroam authenticatie over het algemeen als eerste worden uitgevoerd aangezien netwerk toegang nodig is voordat diensten binnen de
SURFfederatie aangesproken kunnen worden. Deze use case wordt in onderstaande figuur weergegeven. Gast instelling 1 eduroam Gebruiker AP Radius Radius user/pwd store 2 WAYF 3 4 Authenticeren IdP SURFfederatie SP Website SP SURFfederatie Figuur 1 SURFnet usso use case Thuis instelling / SURFfederatie IdP user/pwd store 1. Een mobiele gebruiker bij een gast instelling logt in op het lokale draadloze netwerk middels eduroam. De authenticatie wordt uitgevoerd door de thuis instelling van de gebruiker. 2. De gebruiker opent een website die voor authenticatie aangesloten is op de SURFfederatie. Aangezien de gebruiker nog onbekend is voor deze website zal hij doorverwezen worden naar de SURFfederatie. 3. De SURFfederatie zal de gebruiker vragen wat zijn thuis instelling is en zal hem doorsturen naar de gekozen Identity Provider. 4. De Identity Provider zal de gebruiker moeten authenticeren. Hoogstwaarschijnlijk zal op dit punt de eerdere eduroam login hergebruikt kunnen worden zodat de gebruiker direct is ingelogd op de SURFfederatie en zonder login terug gestuurd kan worden naar de geopende website. Mogelijk dat de login van de gebruiker nog voor andere diensten gebruikt kan worden. Denk hierbij aan de email of kalender voorziening van zijn thuis instelling. Bij de onderzochte usso methoden wordt dit echter als een nice-to-have gezien.
3 Integratie SURFfederatie en eduroam Na een verkenning van de mogelijkheden en gesprekken met betrokkenen is gekomen tot vier mogelijke technieken om de SURFfederatie en eduroam login te integreren. Deze technieken zijn SAML, X.509 certificaten, Information Cards en Kerberos en worden in onderstaande paragrafen beschreven. 3.1 SAML Een SAML assertion kan gebruikt worden als security token welke na een eduroam login wordt gegenereerd en later gebruikt kan worden om te authenticeren voor een SURFfederatie login. In het algemeen wordt voor deze methode vaak de term Bootstrapping 2 gebruikt. In de ICT wereld betekent deze term dat het ene proces een ander proces activeert. In dit scenario betekent wordt het SAML authenticatie proces geactiveerd of mogelijk gemaakt door het eduroam login proces. 3.1.1 Bootstrapping SAML met eduroam Deze methode komt voor een deel overeen met de unified Single Sign On (usso) zoals gedefinieerd door het DAMe 3 sub-project van Géant2. Hierbij wordt usso tussen edugain en eduroam gecreëerd waarbij ook gekeken is naar de mogelijkheid om de eduroam gast instelling autorisatie van netwerktoegang uit te laten uitvoeren. Daarnaast gebruikt het DAMe project niet een SAML token maar een zelf gedefinieerd edutoken om de authenticatie van eduroam over te brengen op de edugain federatie. Figuur 2 geeft schematisch de werking van het bootstrappen van een SAML assertion met behulp van een eduroam login, waarna deze assertion wordt gebruikt om toegang te krijgen tot de SURFfederatie. Gast instelling EAP Tunnel 1 eduroam 3 Gebruiker AP Radius 4 SAML token Radius 2 Authenticeren Get SAML Token 5 WAYF 6 7 Authenticeren Validate SAML token 8 SURFfederatie SP Website SP SURFfederatie IdP Thuis instelling / SURFfederatie IdP Figuur 2 eduroam SURFfederatie SSO middels SAML user/pwd store 2 http://en.wikipedia.org/wiki/bootstrapping_(computing) 3 DAMe Project, http://dame.inf.um.es/
1. eduroam communicatie tussen gast en thuis instelling wordt zoals gebruikelijk opgezet met een EAP tunnel tussen de gebruiker en de Radius server van de thuis instelling 2. eduroam authenticatie van de eindgebruiker gaat middels gebruikersnaam / wachtwoord (of ander reguliere eduroam authenticatie) welke door de Radius server van de thuis instelling bij een Identity Provider (IdP) wordt gevalideerd 3. Na authenticatie vraagt de Radius server van de thuis instelling middels een SAML AuthnRequest een SAML assertion bij de IdP uit naam van de gebruiker. Deze SAML assertion zal later (stap 8) voor authenticatie van de gebruiker bij de IdP worden gebruikt. Dit betekent dat deze SAML assertion een <SubjectConfirmation> element moet bevatten die refereert aan de IdP. 4. De SAML assertion wordt in de Radius response van stap 1 meegegeven in het TLV veld en komt zodoende aan bij de supplicant. De assertion wordt door de supplicant opgeslagen voor later gebruik (stap 7). Er zal een actief proces moeten draaien op de eindgebruikers laptop die deze assertion later beschikbaar kan stellen voor gebruik. Dit zou de supplicant zelf kunnen zijn indien deze actief blijft of een separaat achtergrond proces. 5. De gebruiker opent nu op enig moment een website die voor authenticatie aangesloten is bij de SURFfederatie (de website is een Service Provider, SP). De website zal in eerste instantie de gebruiker niet kunnen verifiëren en deze doorsturen naar de SURFfederatie voor authenticatie. 6. De SURFfederatie zal de gebruiker vragen naar zijn thuis instelling voor authenticatie ( Where Are You From?, WAYF). Na het selecteren van zijn thuis instelling wordt de gebruiker geredirect naar de instellings SURFfederatie IdP. Merk op dat aangezien de thuis instelling van de gebruiker in principe bekend is door de eduroam authenticatie het wellicht mogelijk is om deze stap over te slaan en de gebruiker direct van de SP naar de IdP te sturen. 7. Login bij de IdP gaat nu niet middels gebruikersnaam / wachtwoord, maar met het eerder verkregen SAML assertion. De IdP heeft op de loginpagina een gesigneerde Java applet die ervoor zorgt dat de assertion van de gebruikers supplicant gelezen kan worden. 8. De IdP valideert het SAML assertion en zal een geslaagde authenticatie terug geven aan de SURFfederatie. De gebruiker heeft nu toegang tot de website van de SP. Indien de validatie van de SAML token niet lukt, kan de loginpagina als alternatief het reguliere gebruikersnaam/wachtwoord loginscherm tonen. Mogelijke varianten: A) Andere mogelijkheid om transfer naar browser te maken in stap 4: In de Radius response van stap 1 wordt een URL (one-time time limited) naar een gegenereerde pagina meegestuurd (ook in EAP-TLV). Deze URL wordt door de gebruiker (supplicant) geopend en zal verschijnen in een browser. Deze URL zorgt ervoor dat de gebruiker bij de IdP uitkomt met de gegenereerde SAML assertion. De IdP valideert de assertion en zet een browser cookie (implementatie specifiek). Dit cookie zal ervoor zorgen dat als de gebruiker een SP van de SURFfederatie benadert, en uiteindelijk wordt doorverwezen naar de IdP, hij automatisch door de IdP wordt ingelogd. B) Mogelijk kan in stap 6 (WAYF) de Java applet al door de SURFfederatie gebruikt worden om de opgeslagen SAML assertion te lezen en te valideren. Een extra gang naar de IdP is dan niet nodig. Eventuele attributen die normaal door de IdP worden geleverd kunnen dan echter niet meer worden toegevoegd aan de SURFfederatie SAML assertion. Gezien toekomstige ontwikkelingen zou echter SURFnet zelf in deze gebruikers attributen kunnen voorzien.
C) In aanvulling op bovenstaande stap zou het wellicht mogelijk zijn de initiële SAML assertion in stap 3 niet door de IdP te laten genereren, maar door de SURFfederatie. D) In plaats van een SAML token te gebruiken, kan een zelf gedefinieerd token worden ingezet met eenvoudigere vormgeving en minder elementen. De werking van het scenario blijft precies hetzelfde, alleen het token is anders. Het DAMe project heeft bijvoorbeeld gekozen voor een zelf vormgegeven edutoken. Opmerkingen: Principe is in DAMe al aangetoond, echter met een paar verschillen; DAMe gebruikt het Bridging Element (BE) van edugain welke niet aanwezig is in de SURFfederatie. Daarnaast gebruikt DAMe een eigen proprietary token (edutoken) voor het usso proces. Wijziging in SURFfederatie IdP is eigenlijk dat er onder water een andere authenticatie module ondersteund moet worden (ipv de gebruikersnaam/wachtwoord variant); een module die het token kan valideren. 3.1.2 Voor- en nadelen Voordelen van dit scenario: De werking van delen van dit scenario is al door het DAMe project aangetoond. Het gebruik van SAML technologie sluit goed aan bij de gebruikte SURFfederatie technologie. Nadelen van dit scenario: Er is een Java applet (of vergelijkbare client logica in de browser) nodig. Dit kan browser stabiliteit en/of security issues verookzaken. Werkt alleen voor de beschreven SURFnet use case en zal niet voor niet-browser gebaseerde applicaties kunnen worden ingezet. 3.2 Certificaten 3.2.1 Certificaten voor eduroam en SURFfederatie login Een mogelijk scenario voor het bereiken van Single Sign On tussen eduroam en de SURFfederatie op basis van Certificaten wordt hieronder beschreven.
Figuur 3 eduroam SURFfederatie SSO middels certificaten De thuisinstelling richt een Certificate Server in. Deze fungeert als Certificate Authority en reikt gebruikers certificaten (client certificates) uit en trekt ze weer in (middels een revocation list) en voorziet in Identity Mapping (username-certificate mapping). 1. Met behulp van het certificaat van de gebruiker wordt middels EAP-TLS de eduroam verbinding tot stand gebracht. 2. De Radius Server van de thuisinstelling valideert het client certificaat bij de Certificate Server. 3. De gebruiker opent nu op enig moment een website die voor authenticatie aangesloten is bij de SURFfederatie. De website zal in eerste instantie de gebruiker niet kunnen verifiëren en deze doorsturen naar de SURFfederatie voor authenticatie. 4. De SURFfederatie zal de gebruiker vragen naar zijn thuis instelling voor authenticatie ( Where Are You From?, WAYF). Na het selecteren van zijn thuis instelling wordt de gebruiker geredirect naar de instellings SURFfederatie IdP. Merk op dat aangezien de thuis instelling van de gebruiker in principe bekend is (door de eduroam authenticatie, client certificate informatie) het wellicht mogelijk is om deze stap over te slaan en de gebruiker direct van de SP naar de IdP te sturen. 5. Met behulp van het client certificaat wordt een SURFfederatie sessie verkregen. 6. De IdP valideert het client certificaat bij de Certificate Server. Een uitwerking van dit scenario is al beschikbaar bij SURFnet intern. 3.2.2 Voor- en nadelen Voordelen van dit scenario: Werking van het scenario is aangetoond binnen SURFnet.
Gebruikte technologie heeft zichzelf bewezen in de praktijk. Het gebruik van certificaten biedt ook mogelijkheden voor SSO naar niet-web gerelateerde applicaties. Nadelen van dit scenario: Het scenario introduceert een deployment probleem. De uitgifte en intrekking van certificaten voor eindgebruikers brengt behoorlijk wat administratie met zich mee. Dit scenario legt de authenticatie methode vast, m.a.w. dit werkt alleen als certificaten worden gebruikt om in te loggen, terwijl de andere scenario s - met uitzondering van Information Cards (zie 3.3) - de (eerste) authenticatie methode vrij laten. Een certificaat is betrekkelijk eenvoudig te verplaatsen naar andere systemen (internet cafe). Vergeet men om vervolgens daar het certificaat te verwijderen dan kan een ander persoon zich hiermee toegang verschaffen. Er wordt eigenlijk geen échte SSO gerealiseerd; dezelfde credentials (het certificaat) wordt voor alle diensten gebruikt. Indien het certificaat met een wachtwoord is beveiligd zal dit bij ieder gebruik gegeven moeten worden (mogelijk kan dit wachtwoord wel onthouden worden op de client). 3.3 Information Cards Aangezien Information Cards voor veel lezers nog niet even bekend is als andere technieken wordt eerst een algemene beschrijving van Information Cards gegeven waarna de toepassing op de SURFnet use case wordt besproken. 3.3.1 Information Cards in het algemeen 3.3.1.1 Introductie Het concept van Information Cards is bedacht door Kim Cameron en zijn team bij Microsoft en is als Cardspace onderdeel van de Microsoft software stack. Information Cards (ook wel Infocard of I-Card genoemd) zijn het digitale equivalent van kaarten die mensen fysiek bij zich kunnen dragen in hun portemonnee of portefeuille. Denk daarbij aan een paspoort, rijbewijs, creditcard, toegangspas voor het werk, lidmaatschapskaart van de sportclub, OV-studentenkaart of OV-chipkaart, Airmiles pas, enz. Al deze kaarten hebben zo hun eigen toepassing, bevatten verschillende identiteit informatie en zijn verschillend in de mate van betrouwbaarheid (vergelijk een paspoort met een AHbonuskaart). De technische standaard voor Information Cards wordt vormgegeven door het OASIS Identity Metasystem Interoperability (IMI) Technical Committee 4 : The purpose of the Identity Metasystem Interoperability (IMI) Technical Committee (TC) is to increase the quality and number of interoperable implementations of Information Cards and associated identity system components to enable the Identity Metasystem. 4 OASIS Identity Metasystem Interoperability (IMI) TC, http://www.oasisopen.org/committees/tc_home.php?wg_abbrev=imi
Hoewel de naam anders suggereert, gaat het bij het OASIS IMI TC om het specificeren van het Information Card Model 5. De IMI 1.0 specificatie is op dit moment een Committee Specification en er wordt verwacht dat deze in juni 2009 een officiele OASIS Standaard wordt 6. Het Information Card model gebruikt elementen uit verschillende andere standaarden zoals WS-Security, WS-Trust, WS-MetadataExchange en WS-SecurityPolicy. 3.3.1.2 Werking De essentie van de werking van Information Cards is dat wanneer een gebruiker moet inloggen op een website, hij een Information Card selecteert die aan de eisen van de website voldoet. Figuur 4 geeft de architectuur componenten weer die een rol spelen in het Information Card Model. Identity Provider Gebruiker Relying Party Identity Provider Identity Selector Website Figuur 4 Information Card Model componenten Identity Selector: Om een Information Card te kunnen selecteren moet er op het gebruikers apparaat een Identity Selector aanwezig zijn. Dit is een stuk software die de Cards beheert en een user-interface voor eindgebruikers biedt. Bij een website login laat de Selector ook alleen de Cards zien die voldoen aan de eisen van de website. Relying Party: Meestal een website waar de gebruiker wil inloggen. De website stelt hiertoe eisen aan de Information Card, bijvoorbeeld over welke gebruikersgegevens de Card moet bevatten. Identity Provider: Een partij die instaat voor de juistheid van bepaalde gegevens (claims) van een specifieke Information Card die door deze provider wordt verstrekt. Op basis van deze Cards geeft de Identity Provider een security token uit. Een belangrijke realisatie bij het begrijpen van het Information Card model is dat een Information Card zelf géén security token (zoals een SAML assertion) is. Een Information Card is een beschrijving van de relatie tussen de gebruiker en de Identity Provider. Deze Card wordt gebruikt om bij de Identity Provider een daadwerkelijk security token te krijgen die de nodige claims voor de Relying Party bevat. 3.3.1.3 Gedetailleerde flow 7 Een gedetailleerde uitleg van de communicatie tussen de verschillende componenten in het Information Card model wordt weergegeven in onderstaande figuur en vervolgens puntsgewijs uitgelegd. 5 OASIS Identity Metasystem Interoperability (IMI) TC Public documents, http://www.oasis-open.org/committees/documents.php?wg_abbrev=imi 6 http://informationcard.net/faqs/technical 7 Uit: An Implementer s Guide to the Identity Selector Interoperability Profile V1.5, Microsoft, July 2008 (link)
Identity Provider Gebruiker Relying Party Self-issued IdP Security Token Service Managed IdP Security Token Service 3 5 3 5 Applicatie client 1 2 6 Identity Selector 4 7 Applicatie service Managed IdP 3 5 Security Token Service Figuur 5 Gedetailleerde Information Card flow De gebruiker heeft eerder een Information Card verkregen van een Identity Provider. 1. Nadat de applicatie client aangeeft in te willen loggen mbv een Information Card, zal de Relying Parties applicatie service zijn security policy aan de client verstrekken. Deze security policy communiceert de benodigde claims voor toegang, maar ook het verwachte security token type van een specifieke Identity Provider voor toegang tot de service. Hiertoe wordt WS-SecurityPolicy gebruikt. Als het een webservice applicatie betreft zullen deze WS-SecurityPolicy elementen middels WS-MetadataExchange worden gecommuniceerd, indien het een web applicatie betreft zullen deze elementen in de HTML code (OBJECT of XHTML tags) van de betreffende pagina worden opgenomen. 2. De applicatie client vraagt aan de Identity Selector voor een security token die voldoet aan de eisen van de Relying Party. De Identity Selector laat de Information Cards die voldoen aan deze eisen zien, waarna de gebruiker er een selecteert. 3. De Identity Selector vraagt de security policy van de Identity Provider die overeenkomt met de geselecteerde Information Card. Deze security policy wordt middels metadata (WS-SecurityPolicy over WS-MetadataExchange) uitgewisseld waarna de Identity Selector weet hoe (bijvoorbeeld met welke binding) de Identity Provider kan worden aangesproken. 4. De geselecteerde Information Card bevat authenticatie informatie, zoals de door de Identity Provider gewenste authenticatie methode (een X.509 certificaat, username/password, Kerberos of een self-issued Information Card). De Identity Selector zorgt voor het verkrijgen van de juiste credentials van de gebruiker. 5. De Identity Selector authenticeert de gebruiker nu bij de Security Token Service (STS) van de Identity Provider. Deze STS genereert een security token op basis van de claims uit de Relying Parties security policy en geeft dit security token terug aan de Identity Selector. Deze communicatie gaat middels het WS-Trust protocol. 6. De Identity Selector geeft het security token aan de applicatie client. 7. De applicatie client geeft het security token aan de applicatie service en verkrijgt zo toegang tot de service. In een browser based scenario wordt op dit moment meestal een browser cookie gezet zodat volgende requests niet geauthenticeerd hoeven te worden.
Zoals te zien is in bovenstaande flow bestaan er twee 8 soorten Information Cards, afhankelijk van de gebruikte soort Identity Provider. een self-issued of persoonlijke Card waarbij twee partijen betrokken zijn (de gebruiker en de Relying Party) een managed Card waarbij drie partijen betrokken zijn (de gebruiker, de Relying Party en een Identity Provider). 3.3.2 Bootstrapping Information Card met eduroam Een mogelijkheid om middels een Information Card SSO mogelijk te maken tussen eduroam en de SURFfederatie wordt hier beschreven. Dit scenario komt erop neer dat na een reguliere eduroam login een Information Card aan de gebruiker wordt gegeven die vervolgens gebruikt kan worden voor een SURFfederatie login (het bootstrappen, zie paragraaf 3.1 voor een uitleg). Onderstaande figuur met bijbehorende uitleg geeft een gedetailleerd beeld van dit scenario. Dit principe komt deels overeen met onderzoek dat gedaan is aan de Universiteit van Alcala (Spanje) en is gepresenteerd op TNC2009 9. Gast instelling EAP Tunnel 1 eduroam Gebruiker AP Radius 4 Infocard Radius 3 Get Infocard 2 Authenticeren 5 WAYF 6 8 Exchange Infocard 7 9 Authenticeren Infocard STS SURFfederatie SP Website SP SURFfederatie IdP Thuis instelling / SURFfederatie IdP Figuur 6 eduroam SURFfederatie SSO middels Information Cards user/pwd store 1. eduroam communicatie tussen gast en thuis instelling wordt zoals gebruikelijk opgezet met een EAP tunnel tussen de gebruiker en de Radius server van de thuis instelling 2. eduroam authenticatie van de eindgebruiker gaat middels gebruikersnaam / wachtwoord (of ander reguliere eduroam authenticatie) welke door de Radius server van de thuis instelling bij een Identity Provider (IdP) wordt gevalideerd. In dit proces moet de supplicant ook gegevens van een self-issued infocard 8 Soms wordt ook nog een Action Card, een Password Card en een Relationship Card onderscheiden, maar dat is hier niet van belang 9 An Infocard-based proposal for unified single sing on, presentation by Enrique de la Hoz, http://tnc2009.terena.org/schedule/presentations/show.php?pres_id=44
meesturen die de gebruiker al heeft. Deze self-issued Infocard dient later (stap 8) als authenticatie middel voor de managed Infocard. 3. Na authenticatie vraagt de Radius server van de thuis instelling een managed Infocard bij de Infocard STS op. Hierbij worden de gegevens van de self-issued Infocard meegestuurd zodat de STS dit later als authenticatie van de managed card kan gebruiken. 4. De Infocard wordt aan de gebruiker gegeven. Grofweg zijn hier twee mogelijkheden voor: a. De Infocard wordt in de Radius response van stap 1 meegegeven in het TLV veld. De supplicant op de gebruikers computer moet de verkregen Infocard in de Information Card store importeren b. In de Radius response van stap 1 wordt een URL (one-time, time limited) naar de Infocard meegestuurd (ook in EAP-TLV). De gebruiker (supplicant) zal deze link openen met de browser waarna de Infocard door de browser wordt opgehaald en in de Identity Selector wordt geïmporteerd. 5. De gebruiker opent nu op enig moment een website die voor authenticatie aangesloten is bij de SURFfederatie (de website is een Service Provider, SP). De website zal in eerste instantie de gebruiker niet kunnen verifiëren en deze doorsturen naar de SURFfederatie voor authenticatie. 6. De SURFfederatie zal de gebruiker vragen naar zijn thuis instelling voor authenticatie ( Where Are You From?, WAYF). Na het selecteren van zijn thuis instelling wordt de gebruiker geredirect naar de instellings SURFfederatie IdP. Merk op dat aangezien de thuis instelling van de gebruiker in principe bekend is door de eduroam authenticatie het wellicht mogelijk is om deze stap over te slaan en de gebruiker direct van de SP naar de IdP te sturen. 7. Authenticeren bij de IdP gaat nu niet middels gebruikersnaam / wachtwoord, maar met de eerder verkregen managed Infocard. Hier is de SURFfederatie IdP de Relying Party (RP) in een Infocard scenario. De gebruiker moet op de SURFfederatie IdP login pagina het Infocard logo selecteren waarna de Identity Selector op de gebruikers laptop wordt geactiveerd. De gebruiker selecteert de managed Infocard en staat toe dat deze voor een login bij de SURFfederatie wordt gebruikt. 8. De managed Infocard wordt nu door de Identity Selector bij de Infocard STS gevalideerd en ingewisseld tegen een security token wat in de volgende stap als authenticatie dienst doet bij de SURFfederatie IdP. De authenticatie van de managed Infocard gebeurt door de self-issued Infocard die door de Identity Selector automatisch in de communicatie met de STS wordt toegevoegd. 9. Het security token wordt door de SURFfederatie IdP gevalideerd op basis van het vertrouwen in de Infocard STS. Hierna zal de IdP een SURFfederatie SAML token aan de eindgebruiker verlenen. De rest van de flow om toegang te krijgen tot de website is vergelijkbaar met de reguliere SURFfederatie authenticatie. Mogelijke varianten: A) Wellicht dat in stap 6 de SURFfederatie als onderdeel van de lijst met instellingen eduroam Infocard als optie weergeeft. De SURFfederatie zou dan de door de gebruiker geselecteerde Infocard kunnen valideren bij de Infocard STS van de thuis instelling. De Infocard moet dan wel de URL van deze STS bevatten (of op een andere manier deze STS kunnen vinden). Effectief wordt hierdoor stap 7 overgeslagen wat de impact van dit scenario op de IdP van de thuis instelling beperkt. B) In plaats van de thuis instelling een Information Card te laten genereren, zou de Radius server van de thuis instelling dit aan de SURFfederatie kunnen overlaten. Zodoende zou een gebruiker de beschikking krijgen over een SURFfederatie Information
Card. Met deze Card kan de gebruiker zich vervolgens authenticeren bij de SURFfederatie (in stap 6) in plaats van bij de IdP van de thuis instelling (stap 7 en 8 worden hierdoor overbodig). Het voordeel van deze aanpak is dat de thuis instelling geen aanpassingen aan de IdP hoeft door te voeren en ook geen Infocard STS hoeft in te richten. Nadeel is dat een SURFfederatie authenticatie wordt uitgevoerd door de SURFfederatie zelf waardoor mogelijk niet alle gebruikers attributen voor de federatie beschikbaar zijn. Deze attributen zouden mogelijk wel uit de SURFnet offline attribute store gehaald kunnen worden. C) In plaats van het bootstrappen van een Infocard vanuit een EAP challenge, zou het wellicht ook mogelijk kunnen zijn een EAP-Infocard te gebruiken. Een out-of-band verkregen Infocard zou dan gebruikt kunnen worden om zowel bij eduroam als bij de SURFfederatie te authenticeren. Zie voor meer informatie paragraaf 3.3.3 waarin dit nader is uitgewerkt. Opmerkingen: Een managed Infocard kan alleen gebruikt worden met een bijbehorend wachtwoord; er is dus geen échte SSO (om de eduroam Infocard te kunnen gebruiken moet toch weer een wachtwoord ingevoerd worden). Om dit te vermijden zou een client X.509 certificaat gebruikt kunnen worden of een self-issued Infocard. Indien self-issued Infocard gebruikt wordt zal bij de eduroam authenticatie alvast de cardid van deze self-issued card meegestuurd moeten worden. De eduroam Infocard kan dan alleen gebruikt worden in combinatie met de self-issued card. Invalidatie van de eduroam Infocard is wenselijk na een bepaalde tijd of nadat de connectie met eduroam is getermineerd. 3.3.3 EAP-Infocard In discussies binnen het projectteam is geopperd te onderzoeken in hoeverre EAP- Infocard mogelijk is als methode voor een eduroam met SURFfederatie koppeling. Met EAP-Infocard wordt bedoeld het gebruiken van een Information Card voor het authenticeren van een EAP verbinding. Bij een dergelijke opzet zou een Information Card gebruikt kunnen worden voor zowel eduroam als SURFfederatie authenticatie. Vóór gebruik zou deze kaart dan eerst eenmalig verkregen moeten zijn. Deze paragraaf onderzoekt de mogelijkheden en zal kort aangeven wat hiervoor nodig zou zijn. Allereerst is een onderzoek gedaan op internet naar de mogelijkheden en vooruitzichten van EAP-Infocard. Hieruit is gebleken dat hier geen initiatieven voor bestaan. Bij zoekacties kwam meestal het onderzoek van Géant mbt het bootstrappen van een Information Card middels EAP als eerste resultaat naar boven. Dit is echter niet hetzelfde als beoogd wordt met EAP-Infocard. Figuur 7 geeft een overzicht van de componenten uit het Information Card model toegepast in een EAP scenario. De volgende opmerkingen zijn hierbij van belang: De Applicatie Client uit Figuur 5 is nu de supplicant De Applicatie Service uit Figuur 5 is nu de Radius Server en bevindt zich in de thuis organisatie De Identity Provider bevindt zich eveneens in de thuis organisatie en is een Managed IdP De Identity Selector zal nog steeds gebruikt moeten worden om de gebruiker de juiste Information Card te kunnen laten selecteren Alle communicatie buiten de client om, zoals weergegeven in Figuur 5 (nummers 1, 3, 5 en 7) moeten over de EAP tunnel uitgevoerd worden.
Relying Party / Identity Provider Gebruiker EAP Tunnel Radius Server Security Token Service 1 3 7 5 Supplicant 2 6 Identity Selector 4 Managed IdP Security Token Service Figuur 7 EAP-Infocard Bij het maken van een EAP-Infocard zullen de volgende zaken moeten worden gerealiseerd en overwogen: In het Information Card model gaat alle communicatie over HTTP. Met EAP-Infocard zal alle informatie in EAP pakketten getransporteerd moeten worden. Dit maakt dat de Supplicant en Radius server aangepast moeten worden. De Radius server, waar het eindpunt van de EAP Tunnel zich bevindt, moet dienen als Relying Party maar ook als Identity Provider. Mogelijk moet de Radius server de communicatie naar de Identity Provider proxy-en. De communicatie vanuit de Identity Selector naar de Identity Server zal via de Supplicant moeten lopen, en niet rechtstreeks zoals gebruikelijk. Dit vereist een aanpassing van de Identity Selector. Aangezien de Identity Selector ook voor normale Information Card scenario s ingezet wordt, zal er een manier gevonden moeten worden om de Identity Selector aan te geven dat zijn communicatie in dit geval via de Supplicant moet laten lopen. Wellicht is het meest eenvoudige om van het Information Card model de webservices interacties en bijbehorende berichten te gebruiken als basis voor EAP- Infocard. Merk op dat het Information Card model het mogelijk maakt dat een Relying Party ook een STS heeft. Dit zou idealiter ook door EAP-Infocard ondersteund moeten worden. 3.3.4 Voor- en nadelen Scenario Bootstrapping Information Card met eduroam Voordelen van dit scenario: Er is al door medewerkers van de Universiteit van Alcala aangetoond dat dit scenario kan werken. Dit scenario maakt gebruik van bestaande client software (de Identity Selector) waardoor extra client aanpassingen beperkt blijven. Vanwege de architectuur van het Information Card model (voornamelijk door de Identity Selector) kan een Information Card ook voor toepassingen op andere OSI lagen gebruikt gaan worden. Nadelen van dit scenario: