indi-2009-07-026
Cross Layer Identity Project: SURFworks Projectjaar Projectmanager Auteur(s) Opleverdatum Versie
: : : : :
2009 Remco Poortinga – van Wijnen Erik Sneep en Peter Clijsters (Everett) 27-07-2009 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-NoncommercialShare 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 Cross Layer Identity Publiek 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
4 dingen die je moet weten over Cross Layer Identity Scenario
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 Model1, 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 7. Application
Function Network process to application
6. Presentation
Data representation and encryption Interhost communication End-to-end connections and reliability Path determination and logical addressing Physical addressing
Data Host Layers
5. Session 4. Transport Segment 3. Network Packet 2. Data Link
Media Layers
Frame 1. Physical
Media, signal and binary transmission
Bit
Examples NNTP, SIP, DNS, FTP, HTTP, NTP, SMTP, SNMP, Radius MIME, XDR, SSL, TLS Named Pipes, NetBIOS, SAP TCP, UDP, PPTP, L2TP, TLS IP, ICMP, IPsec, IGMP ARP, CSLIP, SLIP, Frame Relay, EAP 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
2
user/pwd store
Radius
Radius 4
WAYF
3
Authenticeren
IdP user/pwd store
SURFfederatie Website SURFfederatie SP
SP
Thuis instelling / SURFfederatie IdP
Figuur 1 SURFnet uSSO use case 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 DAMe3 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 3
eduroam
AP
Gebruiker
Radius
Radius 4
5
2
Get SAML Token
SAML token Authenticeren
7
WAYF
Authenticeren
6
Validate SAML token
8
IdP user/pwd store
SURFfederatie Website SURFfederatie SP
SP
Thuis instelling / SURFfederatie IdP
Figuur 2 eduroam – SURFfederatie SSO middels SAML
2 3
http://en.wikipedia.org/wiki/Bootstrapping_(computing) 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 Committee4: “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 Model5. 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 wordt6. 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 flow7
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)
Gebruiker
Identity Provider
Relying Party
Self-issued IdP Security Token Service
3 5
Managed IdP Security Token Service
Managed IdP
3
5
3 5
Applicatie client
2
6
1
7
Applicatie service
Identity Selector
4
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 twee8 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 TNC20099.
Gast instelling
EAP Tunnel
1
eduroam
3
Gebruiker
AP
2
Radius
Radius 4
5
Get Infocard
Infocard
8
WAYF
6
Authenticeren
Exchange Infocard
7
Infocard STS
9 Authenticeren
SURFfederatie Website SURFfederatie SP
SP
IdP
user/pwd store
Thuis instelling / SURFfederatie IdP
Figuur 6 eduroam – SURFfederatie SSO middels Information Cards
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 EAPInfocard 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 Security Token Service Server
1
7
3 5
2 Supplicant
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 EAPInfocard.
•
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:
•
Information Cards moeten bij gebruik ook weer geauthenticeerd worden. Dit maakt het scenario extra ingewikkeld en minder gebruiksvriendelijk.
•
Information Cards worden nog beperkt gebruikt en zal zich nog voor een groot deel moeten bewijzen.
Scenario “EAP-Infocard” Voordelen van dit scenario: •
Zowel voor eduroam als voor de SURFfederatie wordt nu met hetzelfde Information Card ingelogd.
•
De Information Card kan mogelijk ook voor andere toepassingen gebruikt gaan worden
Nadelen van dit scenario: •
Naar verwachting vereist dit scenario een grote en zeer specialistische inspanning. Dit wordt voornamelijk veroorzaakt door het “verpakken” van Information Card HTTP verzoeken in het EAP protocol en bijbehorende aanpassingen aan de supplicant en Radius server.
•
Zoals met andere EAP-* protocollen zal ook EAP-Infocard een standaardisatie proces moeten afleggen.
•
De eindgebruiker moet, voordat het scenario start, een Information Card van zijn instelling hebben verkregen. Dit creëert dus een zelfde deployment/beheer probleem als bij certificaten.
•
Analoog aan gebruik van certificaten wordt het gebruik van Information Cards de enige mogelijke authenticatie methode.
3.4 Kerberos Een mogelijk scenario voor het bereiken van Single Sign On op basis van Kerberos wordt hieronder -na een beknopte beschrijving van Kerberos- uiteen gezet.
3.4.1
Kerberos in het algemeen
Kerberos is een computer netwerk authenticatie protocol dat partijen in staat stelt elkaars identiteit te bewijzen in een onveilige netwerkomgeving op een veilige manier. De huidige versie van het protocol: 5, is beschreven in RFC 4120. Een uitgebreide uitleg is te vinden op http://www.kerberos.org/software/tutorial.html. Het protocol voorziet in wederzijdse authenticatie. Zowel de gebruiker als de applicatie server verifieert elkanders identiteit. Kerberos is opgebouwd rondom symmetrische sleutel cryptografie (Symmetric Key Cryptography) en kan niet zonder een vertrouwde derde partij (Trusted third party) de zg Key Distribution Center (KDC). De KDC bestaat uit twee logische componenten: de Authenticatie Server (AS) en de Ticket Granting Server (TGS). Onderstaand figuur geeft Kerberos authenticatie in het algemeen weer.
Figuur 8 Kerberos authenticatie
3.4.1.1
Protocol beschrijving
De volgende afkortingen worden gebruikt: KDC AS TGS TGT RTGT SSR ST
= = = = = = =
Key Distribution Center Authentication Server Ticket Granting Server Ticket Granting Ticket Remote Ticket Granting Ticket Service Server (Application Server in het diagram) Service Ticket
In het kort verloopt het authenticatie proces als volgt. De KDC genereert een Session Key waarmee de berichten tussen de entiteiten versleuteld kunnen worden. De client voert eenmalig authenticatie uit bij de AS waarbij een gedeeld geheim (shared secret, bijvoorbeeld password) wordt gebruikt en verkrijgt bij succes een TGT van de AS. In een later stadium wanneer de client contact zoekt met een SSR kan de TGT -opnieuwgebruikt worden om een additioneel ticket voor die SSR te verkrijgen. Het verkregen Service Ticket kan nu worden gebruikt om authenticatie te bewijzen aan de SSR.
3.4.1.2
Aanvulling
Cross authentication: Gebruikers in bepaald domein (Realm) toch toegang verschaffen tot services in een ander domein. Dit kan bewerkstelligd worden door trust relaties (trust relationships) aan te brengen tussen de KDC’s in de verschillende domeinen (Realms). Dit kunnen zowel eenrichtings- als tweerichtingsrelaties zijn. De trust relaties worden
middels zogenaamde remote TGT’s geverifieerd. Een RTGT kan bij de ‘gast’ KDC worden verkregen nadat eerst een TGT bij de eigen KDC is verkregen. Er zijn drie typen van trust relaties te onderscheiden: • • •
Directe trust relaties Transitieve trust relaties Hiërarchische trust relaties
Het verschil tussen de typen zit voornamelijk in de manier waarop het authenticatie-pad wordt bepaald. Bij een groot aantal van KDC’s is het hiërarchische type de aanbevolen manier om trust relaties vast te leggen.
3.4.2
Bootstrapping Kerberos met eduroam
In het volgende diagram is een theoretisch scenario geschetst van de toepassing van Kerberos voor het bewerkstelligen van Cross Layer Single Sign On tussen eduroam en bij de SURFfederatie aangesloten webdiensten. Bij het bootstrappen (voor een uitleg van deze term, zie paragraaf 3.1) van Kerberos met EAP scenario wordt een veld (TLV) binnen een bestaande EAP variant gebruikt om Kerberos data te transporteren. Men zou ook kunnen denken aan het ontwikkelen van een nieuwe EAP-Kerberos variant zoals beschreven in paragraaf 3.3.3 voor EAP-Infocard. Hier wordt in dit scenario niet van uit gegaan. Verscheidene initiatieven voor het ontwikkelen van de EAP-Kerberos variant lijken vooralsnog gestrand te zijn10.
Figuur 9 eduroam – SURFfederatie SSO middels Kerberos
10
Een teken van leven op het vlak van Kerberos en Web Identity is te vinden in een redelijk recent uitgegeven document: http://www.kerberos.org/software/kerbweb.pdf
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, dit zou eventueel Kerberos kunnen zijn, er is bijvoorbeeld een module voor freeradius om Kerberos authenticatie te doen) 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 voor de client een Ticket Granting Ticket (TGT) bij het Kerberos Key Distribution Center (KDC) op. De TGT wordt naar de gebruiker getransporteerd door gebruik te maken van het EAP TLV veld. De supplicant op de gebruikers computer moet de verkregen TGT aan de Kerberos Client software bekend maken. 4. 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. 5. 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 dan wel Kerberos authenticatie) het wellicht mogelijk is om deze stap over te slaan en de gebruiker direct van de SP naar de IdP te sturen. 6. Bij het KDC wordt met behulp van de TGT nu een Session Ticket voor de IdP verkregen. 7. Als succesvol een ST is verkregen voor de IdP wordt door de IdP een SAML token aan de eindgebruiker verleend. Hier is de IdP de Relying Party (RP) in het Kerberos scenario. De rest van de flow om toegang te krijgen tot de website is vergelijkbaar met de reguliere SURFfederatie authenticatie.
Mogelijke variant: Een uitbreiding op het bovenstaande scenario gaat uit van de implementatie van een (‘soort’) Kerberos Federatie. Tussen de KDC’s (Kerberos Realms) van de gast en thuis instelling wordt een (hiërarchische) ‘cross authentication’ trust relatie gedefinieerd. Een groot voordeel hiervan is dat dan ook Single Sign On voor non-web applicaties bij de gast instelling realiseerbaar is. 1. Een (gast) gebruiker meld zich aan bij eduroam volgens het hierboven beschreven scenario. 2. Met behulp van de TGT kan een remote TGT (RTGT) verkregen worden voor de gast instelling. 3. De gebruiker verkrijgt met het verkregen RTGT toegang tot non-web applicaties die gebruik maken van Kerberos authenticatie bij de gast instelling.
3.4.3
Voor- en nadelen
Voordelen van dit scenario: •
Kerberos is technologie die zich in de praktijk heeft bewezen en een grote installed base heeft. Nagenoeg voor ieder OS is een Kerberos client beschikbaar en veel
server applicaties kennen de mogelijkheid om authenticatie door Kerberos (vaak middels een plugin) te laten uitvoeren. •
De beschreven variant biedt ook mogelijkheden voor SSO naar niet-web gerelateerde applicaties.
•
Met de remote TGT variant wordt SSO voor gastgebruik van non-web applicaties mogelijk.
Nadelen van dit scenario: •
Er is geen standaard administratie protocol tussen de verschillende implementaties (MIT en Heimdal) van Kerberos.
•
Er zijn naast verschillende implementaties ook verschillende versies (Kerberos 4 en 5) in omloop.
•
Alle secret keys staan in één database. Indien de database gecompromitteerd wordt is de identiteit (secret key) van een ieder in die database gecompromitteerd.
•
Als de client wordt gecompromitteerd dan is het wachtwoord van de gebruiker dat ook.
•
Als voor de variant met remote TGT wordt gekozen (voor SSO bij non-web applicaties bij de gast instelling) introduceert dit wel een derde ‘federatie’ (naast eduroam en SURFfederatie). Uiteraard gaat dit nadeel niet op als niet voor deze variant wordt gekozen.
4 Conclusie en aanbeveling Er zijn vier technieken gepresenteerd om de SURFnet uSSO use case in te vullen. De conclusie naar aanleiding van dit onderzoek en discussies met betrokken bij SURFnet is dat uSSO tussen eduroam en de SURFfederatie mogelijk is voor alle onderzochte technieken. De ene techniek is echter beter geschikt dan een andere. SAML Zo komt het gebruik van SAML neer op het gebruik van een security token om bij de SURFfederatie IdP aan te geven dat er een succesvolle eduroam login door deze gebruiker is uitgevoerd. Er zou ook een willekeurig ander token gebruikt kunnen worden om dit aan te geven. Zo gebruikt het DAMe project van Géant2 een eigen gedefinieerd eduToken. Deze oplossing zou dan specifiek zijn voor uSSO met de SURFfederatie waarvoor een extra stuk client software nodig is om het token beschikbaar te maken. Een login met dit security token voor andere diensten zoals IMAP is niet mogelijk. Certificaten Het gebruik van X.509 certificaten voor authenticatie bestaat al geruime tijd en wordt ook voor diverse toepassingen ondersteund. Zo is de beschreven use case al mogelijk met deze certificaten en wordt ook al gebruikt door medewerkers van SURFnet zelf. Zij loggen in bij eduroam met een persoonlijk certificaat en kunnen met ditzelfde certificaat inloggen bij de SURFfederatie. Probleem bij het grootschalig gebruik van certificaten is voornamelijk het beheer ervan en natuurlijk dat er ‘verplicht’ met certificaten moet worden ingelogd, andere scenario’s laten de (eerste) inlogmethode vrij. Information Card Het verkrijgen van een Information Card bij een eduroam login en deze vervolgens voor authenticatie bij een website gebruiken is aangetoond door onderzoekers van de universiteit van Alcala en is op TNC2009 gepresenteerd. Dit is op zich een goede methode welke ervoor zorgt dat de gebruiker een Information Card krijgt die mogelijk voor meer diensten gebruikt kan worden. Door het gebruik van een standaard stuk client software (de Identity Selector) zijn Information Cards ook geschikt voor gebruik binnen web services en potentieel ook voor andere protocollen zoals IMAP en VOIP, mits dat wordt ondersteund. Op dit gebied is echter nog geen beweging waar te nemen en dit zal mogelijk nog enige tijd op zich laten wachten. Een andere mogelijkheid dan het bootstrappen van een Information Card met eduroam is het realiseren van een EAP-Infocard protocol. Hoewel dit een elegante mogelijkheid is om met dezelfde Information Card zowel toegang tot eduroam als de SURFfederatie te hebben, zou dit echter een substantiële en complexe ontwikkel inspanning vereisen. Bovendien kleven hieraan dezelfde nadelen als voor certificaten (deployment probleem en ‘verplichte’ authenticatie methode d.m.v. Information Cards). Bij eventueel succes zou dit moeten eindigen in het schrijven van een EAP-Infocard RFC. Kerberos Kerberos is een relatief oude authenticatie methode die vooral veel 'onder de motorkap' in de MS Windows wereld wordt gebruikt. Voor zeer veel andere operating systemen, applicaties en protocollen bestaat eveneens de mogelijkheid authenticatie op basis van Kerberos uit te voeren, met andere woorden: er is al een grote ( ‘hidden’) installed base voor Kerberos. Eigenlijk kan gezegd worden dat de benodigde software componenten voor uSSO met behulp van Kerberos al bestaat, maar nauwelijks in combinatie wordt gebruikt. Door nu middels een eduroam authenticatie een Kerberos TGT aan de gebruiker te geven wordt het mogelijk Kerberos authenticatie bij veel applicaties en diensten uit te voeren, zonder dat de gebruiker hier expliciet moet inloggen. Door toevoegen van een
remote TGT optie (‘cross-realm Kerberos’) wordt lokaal SSO gastgebruik van non-web applicaties mogelijk gemaakt. Samenvattend kan gesteld worden dat SAML alleen uSSO tussen eduroam en de SURFfederatie mogelijk maakt, maar niet geschikt is voor andere diensten zoals IMAP. Information Cards zijn wat dat betreft potentieel wel geschikt voor andere diensten, maar de daadwerkelijke ondersteuning hiervoor is er (nog) niet of nog niet voldoende. Het scenario met certificaten wordt wel breder ondersteund, maar er wordt eigenlijk geen échte SSO gerealiseerd; dezelfde credentials (het certificaat) wordt voor alle diensten gebruikt. Bovendien wordt hiermee dus de vrijheid van authenticatiemethode (anders dan bij SAML en Kerberos) vastgelegd. Deze laatste twee bezwaren gelden ook voor het “EAP-Infocard” scenario. Het Kerberos scenario heeft deze nadelen niet en heeft als voordeel dat er al veel programma’s en diensten zijn die Kerberos ‘onder de motorkap’ ondersteunen. Met de (optionele) toevoeging van ‘cross-realm Kerberos’ wordt ook lokaal SSO gastgebruik van non-web applicaties mogelijk gemaakt. Voor de Proof of Concept (PoC) wordt dan ook aanbevolen een test met Kerberos uit te voeren, omdat deze het meest veelbelovend lijkt en qua mogelijkheden potentieel meer heeft te bieden dan de andere opties, vooral wat betreft ondersteuning in programma’s en diensten anders dan WebSSO. Wat verder pleit voor een PoC met Kerberos is dat voor de andere opties, zoals eerder aangegeven11,12, al in meer of mindere mate experimenten met betrekking tot uSSO zijn uitgevoerd. Een PoC met Kerberos vormt hierop een goede aanvulling en zal daarmee een beter beeld opleveren van alle oplossingsrichtingen op het gebied van uSSO en de samenhangende voor- en nadelen. Daarmee is een PoC op het gebied van Kerberos ook direct een waardevolle input voor Europese projecten en andere WebSSO federaties.
11
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 12 DAMe Project, http://dame.inf.um.es/
5 Proof Of Concept Met de PoC zal getracht worden het Kerberos over EAP scenario aan te tonen. Een viertal van - deels te ontwikkelen - componenten vormt hierbij de kern van de PoC: • Een KDC • Een aangepaste supplicant • Een Radius module • Een Kerberos enabled IdP Voor verschillende componenten kan er mogelijk gebruik gemaakt worden van hooks die ook al door het eduroam - Infocard project van de universiteit van Alcala zijn gebruikt (zie paragraaf 3.3.2). Schematisch ziet de proefopstelling er als volgt uit:
eduroam laag Voor de proefopstelling wordt uitgegaan van een Linux client. De veelgebruikte open source WPA-supplicant zal worden aangepast zodanig dat deze de Kerberos data uit het TLV veld kan afleiden. Hiermee kan de Kerberos initialisatie op de client worden uitgevoerd. Indien de tijd het toelaat zal gekeken worden naar een Windows client, en dan met name naar SecureW2. Voor de Radius server zal de Radiator implementatie worden gebruikt. Een module zal worden ontwikkeld om voor de client de authenticatie af te handelen en de verkregen TGT informatie middels EAP naar de client te transporteren. SURFfederatie laag Cross layer Single Sign-On wordt aangetoond als de webclient - middels de door de IETF gestandaardiseerde GSSAPI13 - de TGT kan verkrijgen van de Kerberos client software en met behulp van dit TGT een login kan uitvoeren bij de IdP. Een Kerberos enabled IdP zal hiervoor geïmplementeerd worden. Als basis hiervoor kan mogelijk Webauth van Stanford University (http://webauth.stanford.edu) worden gebruikt. Met deze verschillende onderdelen zal dan moeten worden aangetoond dat de use case zoals beschreven in sectie 2.4 kan worden gerealiseerd. 13
Generic Security Services Application Program Interface version 2 update 1, RFC2743
Alhoewel het technisch zeker mogelijk is het scenario te realiseren zitten er nog onzekerheden in de hoeveelheid werk die aanpassing van de verschillende onderdelen vergt (vandaar ook het voorbehoud voor de Windows client). Met het kiezen voor onderdelen die voor andere scenario’s zijn gebruikt (zie paragraaf 3.3.2) wordt dit zoveel mogelijk ondervangen. Na afloop van de PoC zal deze Kerberos aanpak worden geëvalueerd en vergeleken met de informatie die bekend is van de andere scenario’s om te komen tot een aanbeveling voor verdere dienstontwikkeling.
