indi-2009-06-012
Webservices en SURFfederatie Project Projectjaar Projectmanager Auteur(s) Opleverdatum Versie
: : : : : :
SURFworks 2009 Remco Poortinga – van Wijnen Peter Clijsters (Everett) 28-05-2009 1.0
Samenvatting
Dit rapport geeft een beschrijving van de mogelijkheden om webservices authenticatie te integreren met de SURFfederatie. Hierbij kunnen webservices aangeroepen worden en kan de SURFfederatie authenticatie van de eindgebruiker worden hergebruikt. Enige bekendheid met webservices en federatief identity management standaarden wordt verondersteld. Er wordt bekeken hoe deze use case met SOAP webservices security kan worden ingevuld, en dan specifiek met de WS-Trust standaard. Hierbij kan SURFnet een Security Token Service (STS) inrichten die grofweg dezelfde functie heeft voor webservices als de SURFfederatie voor interactieve websites. Er wordt voorgesteld deze architectuur in een Proof Of Concept te toetsen middels het product PingFederate van PingIdentity.
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 Web Services Onderzoek naar standaarden voor federatieve webservices 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
5 dingen die je moet weten over Webservices en SURFfederatie Scenario
Faciliteren van webservices verkeer tussen instellingen onderling en met andere informatie aanbieders en afnemers.
Wat is het?
Uitbreiding van de SURFfederatie met webservices in plaats van alleen web/browser gebaseerde interactie.
Voor wie is het?
Voornamelijk dienstenontwikkelaars en -aanbieders binnen de SURFfederatie.
Hoe werkt het?
Toevoegen van een extra component die het mogelijk maakt de vertrouwensrol van SURFnet binnen de SURFfederatie uit te breiden naar webservices.
Wat kan je ermee?
Mogelijk maken van aanbieden van diensten met behulp van webservices en/of diensten aan ‘de achterkant’ webservices te laten gebruiken ‘in naam van’ de gebruiker.
3
Inhoudsopgave 1
Inleiding ........................................................................................................ 5 1.1 Achtergrond ............................................................................................ 5 1.2 Opdracht................................................................................................. 5 1.3 Werkwijze ............................................................................................... 5 1.4 Scope ..................................................................................................... 5 1.5 Leeswijzer............................................................................................... 5 2 Webservices................................................................................................... 6 2.1 Algemeen................................................................................................ 6 2.2 SOAP webservices .................................................................................... 6 2.2.1 Overzicht .......................................................................................... 6 2.2.2 WS-Security ...................................................................................... 8 2.2.3 WS-Trust .......................................................................................... 9 2.2.4 WS-Federation................................................................................. 10 2.2.5 ID-WSF .......................................................................................... 11 2.3 RESTful webservices ............................................................................... 12 2.3.1 Overzicht ........................................................................................ 12 2.3.2 Authenticatie ................................................................................... 13 3 Webservices, SURFnet en de SURFfederatie...................................................... 18 3.1 Beschrijving use cases ............................................................................ 18 3.1.1 Use case 1 ...................................................................................... 18 3.1.2 Use case 2 ...................................................................................... 19 3.2 Toepassing webservice technieken op use cases ......................................... 19 3.2.1 WS-Trust ........................................................................................ 20 3.2.2 SAML ECP profile.............................................................................. 24 3.3 Conclusie en aanbeveling ........................................................................ 28 4 Proof Of Concept .......................................................................................... 29 5 Referenties .................................................................................................. 30
4
1 Inleiding 1.1 Achtergrond De focus van de SURFfederatie ligt momenteel op Identity Management (IdM) en Single Sign-On (SSO) voor interactieve, webgebaseerde diensten. In de toekomst zal echter federatieve identiteit veel breder worden gebruikt. De belangrijkste uitbreiding zal zijn naar het gebruik voor webservices (zoals SOAP en REST), zodat de identiteit in een Service Oriented Architecture (SOA) omgeving kan worden hergebruikt. Op deze manier kunnen systemen onderling informatie uitwisselen namens de gebruiker, zonder dat services misbruik kunnen maken van die rechten. De SURFfederatie zou in de toekomst voorzieningen kunnen bieden die het mogelijk maken om identiteitsgegevens voor webservices uit te wisselen.
1.2 Opdracht Om de mogelijkheden van de SURFfederatie uit te breiden met identiteitsgegevens voor webservices 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 webservices in het algemeen, de mogelijke beveiliging van webservices en hoe SURFnet, en specifiek de SURFfederatie, hierin een rol kan spelen. 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 webservices voor de SURFfederatie.
1.3 Werkwijze Dit technologieverkenning rapport is geschreven vanuit de bij Everett aanwezige kennis over webservices beveiliging en middels onderzoek op internet. Daarnaast is regelmatig overleg geweest met de opdrachtgever en de verantwoordelijke voor de SURFfederatie bij SURFnet 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 webservices en bijbehorende beveiliging zal zich vooral richten op Open Standaarden.
1.5 Leeswijzer Het rapport bestaat uit grofweg drie onderdelen. Het eerste onderdeel (hoofdstuk 2) bevat een algemene beschrijving van webservices, de verschillende typen webservices die zijn te onderscheiden en de beveiligingsmogelijkheden hiervan. Dit hoofdstuk is goed te gebruiken om een overzicht te krijgen van webservices zonder al te diepgaande technische kennis op dit gebied. In het tweede onderdeel (hoofdstuk 3) wordt bekeken welke webservices use cases SURFnet wil ondersteunen en hoe deze ingevuld kunnen worden met bestaande technieken en standaarden. In dit hoofdstuk wordt ook al een aanbeveling gedaan over de meest geschikte webservices architectuur voor SURFnet. Voor dit hoofdstuk wordt verondersteld dat de lezer redelijk bekend is met de SURFfederatie, federatief identity management en gerelateerde standaarden. Het derde onderdeel (hoofdstuk 4) bevat een voorstel voor de POC opzet.
5
2 Webservices 2.1 Algemeen De term “webservice” wordt in het algemeen gebruikt voor machine naar machine communicatie over een netwerk. Hierbij zijn de machines te verdelen in twee rollen; een client machine (de webservice client, WSC of WS Client) en een server machine (de webservice provider, WSP of WS Provider). De WSP stelt de webservice ter beschikking op een vooraf gedefinieerde locatie (een URL) en interface. Deze interface definitie geeft aan welke operaties ondersteund worden en hoe deze aangeroepen moeten worden. De WSC kan vervolgens de webservice aanroepen, bijvoorbeeld om informatie op te halen of om wijzigingen door te geven. Deze aanroep wordt direct beantwoord wat de webservices interactie synchroon maakt. Met “webservice” wordt hier dus niet een webapplicatie bedoeld zoals webmail of Google Maps waarbij de gebruiker een dienst benadert met zijn of haar web browser.
Figuur 1 Webservices communicatie Webservices kunnen op twee manieren geïmplementeerd worden, namelijk met SOAP en REST. SOAP webservices gebruiken standaard vormgegeven XML berichten volgens de SOAP standaard waarbij de aangeboden webservice middels een WSDL (Web Service Description Language) document is vastgelegd. SOAP webservices wordt veel binnen bedrijven gebruikt en wordt ondersteund door de meeste producten van grote software leveranciers. REST staat voor “REpresentational State Transfer”, ook wel aangeduid als RESTful in het geval het gaat over een service. REST is meer een architectuur principe dan een echte standaard. RESTful webservices zijn dan ook niet gestandaardiseerd, maar zijn wel eenvoudiger van opzet dan SOAP webservices met minder verwerkings overhead. Dit type webservices wordt vooral veel gebruikt op het internet en in Web 2.0 toepassingen (Facebook, Flickr, Amazon).
2.2 SOAP webservices 2.2.1
Overzicht
Het SOAP webservices framework is gedefinieerd door een reeks werkgroepen, aanbevelingen en documenten van het W3C [8]. De documenten die daar het beste overzicht geven is het zijn de SOAP primer [9] en de webservices architectuur [2]. In SOAP webservices worden SOAP berichten uitgewisseld over HTTP of HTTPS1. Een SOAP bericht is een met XML vormgegeven document waarin de envelop, de headers en de body zijn te onderscheiden. Figuur 2 geeft de structuur van een SOAP bericht weer.
1
Hoewel SOAP berichten over meerdere transport protocollen getransporteerd kunnen worden beperken we ons hier tot de zogenaamde “HTTP binding” aangezien deze voor webservices relevant is. 6
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> information about the request/response <env:Body> content of request/response
Figuur 2 Structuur van een SOAP bericht SOAP headers worden gebruikt om gegevens met het bericht mee te transporteren die niet tot de inhoud (payload) van het bericht zelf behoren. Hierbij valt te denken aan metagegevens of context relevante zaken (zoals we later zullen zien valt hier ook security informatie onder). De SOAP body bevat de hoofdgegevens die met het bericht getransporteerd wordt waarbij de body niet alleen uit tekst hoeft te bestaan, maar ook bijvoorbeeld binaire bijlagen kan bevatten. Merk op dat de SOAP standaard zelf niets zegt over welke gegevens in de header of body getransporteerd worden of welke XML tags hiervoor gebruikt moeten worden. Binnen de vastgestelde structuur zoals weergegeven in figuur 2 mag in principe alles. Om de webservice client en provider middels SOAP met elkaar te kunnen laten praten, moet de client weten hoe de berichten vormgegeven moeten worden. Hiervoor is de Web Services Definition Language (WSDL) standaard ontworpen [10]. De WSP kan een WSDL document publiceren welke aangeeft welke XML elementen gebruikt kunnen worden door de client met daarbij de onderlinge afhankelijkheden, hoe deze aangeroepen moeten worden en welke datatypen ondersteund worden. Daarnaast geeft het WSDL document de client hetzelfde inzicht maar dan voor het antwoord dat gegeven wordt door de provider. SOAP webservices worden veel gebruikt voor complexe interacties tussen systemen binnen bedrijven maar ook tussen bedrijven over het internet (denk bijvoorbeeld aan hotel reserveringssystemen en beurs informatiesystemen). Het SOAP berichtenverkeer voor dit soort toepassingen moet goed beveiligd kunnen worden. Hiervoor zijn een aantal uitbreidingen ontwikkeld op de standaard SOAP webservices. Deze uitbreidingen zijn op hun beurt weer vastgelegd als standaarden. Deze zijn:
WS-Security WS-Trust WS-Federation
Een niet direct aan beveiliging maar aan identity management en identiteit gebaseerde web services gerelateerde standaard is ID-WSF. In de volgende paragrafen worden deze standaarden besproken.
7
2.2.2
WS-Security
WS-Security (laatste versie is 1.1) is een OASIS standaard [11] en levert end-to-end message level security voor webservices (in tegenstelling tot point-to-point security waarbij vaak op transport protocol zoals HTTPS wordt beveiligd). WS-Security is zo opgezet dat applicaties, WSCs en WSPs geen kennis van security nodig hebben. Zij kunnen zich volledig richten op de inhoud (payload) van de berichten. WS-Security voegt zijn gegevens toe aan de SOAP headers van de berichten waardoor een aantal beveiligingsaspecten geregeld worden: Vertrouwelijkheid (confidentiality/encryption); berichten kunnen (deels) versleuteld worden zodat deze niet leesbaar zijn voor derden. Hiervoor wordt de XML Encryption (W3C) specificatie geïmplementeerd. Integriteit (message integrity); berichten kunnen digitaal ondertekend worden zodat beide partijen ervan zijn verzekerd dat de inhoud niet door derden is gewijzigd. Hiervoor wordt de XML Signature specificatie (W3C en IETF) geïmplementeerd. Authenticatie en autorisatie; in de headers kunnen verschillende soorten authenticatie schema’s gebruikt worden (zogenaamde “security tokens”), zoals gebruikersnaam/wachtwoord, X.509 certificaat, Kerberos token, SAML assertion. Na authenticatie kan de WSP autorisatie beslissingen nemen. WS-Security kent diverse profielen die het gebruik van verschillende tokens beschrijven en bijvoorbeeld bepalen hoe de tokens in de SOAP headers geplaatst moeten worden. Deze profielen zijn Username, X.509 Certificate, SAML, Kerberos and REL Token Profiles.
WSS
WSS
De security wordt afgehandeld door code-libraries of agents aan de WSC en WSP kant (agents worden voor webservices soms ook wel “interceptors” genoemd). In het geval een library gebruikt wordt, zal de WSC en WSP zodanig geprogrammeerd moeten zijn dat de WS-Security library de security gerelateerde zaken kan toevoegen en valideren. In het geval gebruik gemaakt wordt van agents hoeft de WSC en WSP meestal niet aangepast te worden voor security; dit wordt door de agents toegevoegd.
Figuur 3 Webservices en WS-Security (WSS) In figuur 3 wordt schematisch weergegeven hoe WS-Security samenwerkt met webservices. Standaard werkt WS-Security zo dat de code-library of agent aan de WSC kant encryptie, digitale handtekening en een security token toevoegt aan het bericht. De code-library of agent aan de WSP kant voert vervolgens de decryptie, handtekening en security token validatie uit. Veel producten ondersteunen tegenwoordig WS-Security. Een aantal code-libraries en agent georiënteerde producten zijn hieronder weergegeven. Code-libraries2:
Apache WSS4J
Apache Rampart - Axis2 Security Module (maakt deels gebruik van WSS4J)
2
Dit is geen uitputtende lijst van producten en code libraries 8
Sun Project Metro - XWS-Security
Microsoft Web Services Enhancements (WSE)
Agent georiënteerde producten2:
Sun OpenSSO
Oracle Web Services Manager
2.2.3
WS-Trust
WS-Trust (laatste versie is 1.4) is eveneens een OASIS standaard [15] en definieert uitbreidingen op WS-Security voor het verkrijgen en valideren van security tokens en voor het vormgeven van trust relaties. De reden voor het bestaan van WS-Trust is dat WS-Security alleen niet goed schaalt in een complexe omgeving. Indien er meerdere WS Clients en WS Providers bestaan, verdeeld over verschillende security domeinen zal het steeds moeilijker worden om security tokens op de juiste manier te verkrijgen en te valideren. Een populaire WS Provider zou bijvoorbeeld in staat moeten zijn om username/passwords, X.509 certificaten of Kerberos tokens vanuit verschillende domeinen te valideren. Anderzijds zou een WS Provider kunnen verlangen dat alle WS Clients die van zijn diensten gebruik maken één soort token gebruiken. Dit legt echter de complexiteit van het verkrijgen van een token bij de WS Clients. En wat als een WS Client tientallen webservices aanroept? WS-Trust voorziet in een ontkoppelpunt voor het valideren van tokens en het uitgeven of transformeren van deze tokens in een andere vorm (bijvoorbeeld een Kerberos token transformeren in een SAML token of een SAML token uit het ene domein transformeren in een SAML token uit een ander domein). Dit ontkoppelpunt heet “Security Token Service” (STS). Een STS ondersteunt vier message flows die ook wel “bindings” genoemd worden. Deze bindings zijn:
Issuance binding; hiermee kan een token verkregen worden
Renewal binding; een eerder uitgedeeld token is verlopen en kan vernieuwd worden
Cancel binding; een eerder uitgedeeld token wordt ingetrokken
Validation binding; een token wordt gevalideerd
De issuance binding is de meest relevante functie waarbij de WSC middels een “Request Security Token” (RST) bericht een token van een specifiek type opvraagt bij een STS. Hierbij zal de WSC zich bij de STS moeten authenticeren met behulp van een token dat de WSC eerder heeft verkregen3. De STS zal het token valideren en geeft vervolgens het gevraagde token terug aan de WSC middels een “Request Security Token Response” (RSTR) bericht. Bij het creëren van het gevraagde token kan de STS een aantal gegevens toevoegen zoals “identity mapping” (het vertalen van de identiteit uit het token in een andere die bijvoorbeeld door de WSP wordt begrepen) en extra gebruikersgegevens. Nadat de WSC het juiste type token heeft verkregen kan de
3
Merk op dat een STS ook anoniem tokens kan uitdelen, afhankelijk van de gewenste security policies 9
WST
WST
webservice worden benaderd. De issuance binding, de opvolgende webservice aanroep en vervolgens de validatie door de WSP is weergegeven in figuur 4.
Figuur 4 Webservices en WS-Trust STS-en kunnen onderling een vertrouwensrelatie aangaan waardoor de ene STS tokens vertrouwt die door een andere STS zijn uitgegeven. Een meer geavanceerd scenario is wanneer er gebruik gemaakt wordt van een trust hiërarchie waarbij validatie tegen een hele trust chain gedaan wordt. Er zijn verschillende producten die een STS component aanbieden en er zijn verschillende code-libraries om ontwikkelen van WS Clients en WS Providers voor WS-Trust te vereenvoudigen. Producten met een WS-Trust STS2:
Sun OpenSSO
Microsoft Geneva Server
PingIdentity PingFederate
Vordel XML Gateway
Code libraries2:
Apache Rampart - Axis2 Security Module
Sun Project Metro - WSIT
Microsoft Web Services Enhancements (WSE)
PingIdentity PingFederate
2.2.4
WS-Federation
De WS-Federation specificatie (tot en met versie 1.1) is oorspronkelijk ontwikkeld door een aantal leveranciers4 en is later voorgelegd aan OASIS om gestandaardiseerd te worden. De OASIS WSFED Technical Committee is nog niet klaar met het definiëren van WS-Federation als standaard. Op dit moment ligt er een “Committee Specification” versie van WS-Federation, versie 1.2 [16]. WS-Federation is een uitbreiding op WS-Trust; het gebruikt de basis van WS-Trust en specificeert een reeks protocol toevoegingen en extra services. WS-Federation heeft de volgende eigenschappen t.o.v. WS-Trust (zie ook [17]):
Methode om metadata tussen verschillende federatie deelnemers uit te wisselen
4
BEA Systems, BMC Software, CA, Inc., IBM, Layer 7 Technologies, Microsoft, Novell, VeriSign 10
Single logout mechanisme
Attribute service om extra gegevens van een client op te vragen
Pseudonym service om een alternatieve identiteit (identity mapping) van een client op te vragen met eventueel bijbehorende alternatieve security tokens
Autorisatie service als speciale variant van een STS die een token kan genereren voor de WS Provider waarin aangegeven wordt wat de autorisaties (claims) van de client zijn.
Web (Passive) Requestor protocol; definieert de mechanismen voor het aanvragen, inwisselen en uitgeven van security tokens voor web clients zoals browsers.
Mechanisme om middels extra security policy eisen van de WS Provider een WS Client een webservice verzoek nogmaals uit te laten voeren
Mogelijkheid om privacy eigenschappen van gegevens in berichten tussen een WS Client en een STS of WS Provider op te nemen.
WS-Federation, en dan specifiek het Web (Passive) Requestor protocol, wordt voornamelijk door Microsoft producten ondersteund. Active Directory Federation Services (ADFS) is hier volledig op gebaseerd. Producten van andere leveranciers ondersteunen dan ook vaak het WS-Federation Web (Passive) Requestor protocol om compatibel te zijn met de Microsoft productlijn. Dit Web (Passive) Requestor protocol is het transport van WS-Trust berichten over HTTP (GET, POST, redirects en cookies) en is dus web browser gebaseerde communicatie, net zoals bij de SURFfederatie. Het Web (Passive) Requestor protocol wordt dan ook door de SURFfederatie ondersteund en maakt het mogelijk voor instellingen om (als IdP) met de SURFfederatie te koppelen op basis van de AD(FS) producten van Microsoft, wat vooral handig is voor instellingen die toch al gebruik maken van Active Directory voor hun interne infrastructuur.
2.2.5
ID-WSF
Liberty Web Services bestaat uit Identity Web Services Framework (ID-WSF) en Identity Service Interface Specifications (ID-SIS), waarbij deze laatste gebruik maakt van IDWSF (zie [19] voor een introductie tot ID-WSF). ID-WSF is een framework die aanroepen van identiteit gebaseerde webservices mogelijk maakt. Dit framework maakt het bijvoorbeeld mogelijk om deze services te vinden en geeft een model om ze aan te roepen. Hierbij is het uitgangspunt altijd de identiteit van de gebruiker; een service gebaseerd op ID-WSF levert gegevens gerelateerd aan een bepaalde gebruiker. ID-SIS bestaat uit een aantal basis services zoals Personal Profile en Geo-location, die middels het ID-WSF framework zijn gedefinieerd. ID-WSF gebruikt SOAP voor de webservices en SAML voor de identiteiten en definieert hiermee een aantal services die gebruikt kunnen worden:
Discovery Service: maakt het mogelijk voor een WSC om de WSP van een bepaalde gebruikers identiteit te vinden
Identity Mapping Service: service om user ID’s van één identity provider om te zetten naar user ID’s die bekend zijn bij een andere identity provider
Interaction Service: maakt communicatie mogelijk tussen een gebruiker en de identity provider met betrekking tot consent of gebruikers attributen
People Service: hiermee kan een gebruiker zijn relaties met andere gebruikers beheren, zoals groepen en gebruikers’ rollen 11
Authentication Service: speciale clients (niet web browsers) kunnen deze service gebruiken voor authenticatie bij een identity provider
Single Sign On Service: deze service helpt speciale clients (niet web browsers) met SSO tussen SP’s. Hiervoor wordt het ID-WSF ECP Profile (zie ook paragraaf 3.2.2) gebruikt.
Het ID-WSF framework wordt door een aantal producten ondersteund:
Novell Access Manager
Sun OpenSSO
Symlabs Federated Identity Suite
Client libraries worden onder andere door openLiberty.org ontwikkeld.
2.3 RESTful webservices 2.3.1
Overzicht
REST is meer een architectuur stijl dan een standaard of specificatie. Als zodanig zijn er een aantal eigenschappen van REST te definiëren: Resource georiënteerd; een resource is een benoembaar stuk informatie zoals documenten, foto’s, personen, webpagina’s, enz. en bevindt zich in een bepaalde staat (“state”). Elke resource is adresseerbaar via een URL Elke resource heeft een uniforme interface Een (representatie van) een resource kan opgevraagd en opgestuurd worden Interacties zijn “stateless”; ieder verzoek is onafhankelijk van eerdere verzoeken wat maakt dat de verzonden berichten volledig op zichzelf moeten staan (zelfbeschrijvend). Een ontvangen bericht kan linken naar andere resources (Hypermedia as the engine of state) Het meest bekende voorbeeld van REST is het WWW. Het (enige) standaard protocol wat REST implementeert is HTTP. RESTful webservices zijn webservices die aan bovenstaande eigenschappen voldoen. Hierbij wordt altijd gebruik gemaakt van HTTP als applicatie protocol waarbij de HTTP Methods (POST, GET, PUT, DELETE) de interface acties zijn voor de resource. Onderstaande tabel geeft van iedere HTTP Method de resource acties weer. HTTP Method POST GET PUT5 DELETE5
Resource Action CREATE RETRIEVE UPDATE DELETE
Description Create new resource Retrieve the resource Update resource Delete resource
Analoog aan WSDL voor SOAP gebaseerde webservices bestaat er voor de beschrijving van RESTful webservices WADL (Web Application Description Language). Hoewel het dezelfde soort functie als WSDL vervuld is WADL zeer verschillend. WADL is de meest 5
Merk op dat de HTTP Methoden PUT en DELETE niet veel ondersteund worden. Vaak wordt de bijbehorende acties (UPDATE en DELETE) dan ook uitgevoerd door een POST. 12
populaire RESTful webservices beschrijving en kan gebruikt worden voor code generatie, client/server configuratie of binnen ondersteunende tools. Het gebruik van WADL is optioneel en er is discussie over de toegevoegde waarde ervan. De beste manier om te verduidelijken wat een RESTful webservice precies inhoud is het behandelen van een voorbeeld. Hiervoor nemen we de studentenadministratie van de Academia Universiteit (de AU) waarbij een resource een student weergeeft. Een student wordt door een unieke identifier gerepresenteerd. De URI voor de webservice is: http://www.au.nl/students Een typische RESTful interface voor dit voorbeeld ziet er als volgt uit: Collectie URI: http://www.au.nl/students Member URI: http://www.au.nl/students/s0028199 HTTP Method POST
GET
PUT DELETE
2.3.2
Collectie URI:
Member URI:
http://www.au.nl/students
http://www.au.nl/students/s0028199
Maak een nieuwe member (een nieuwe student). Het antwoord bevat meestal het nieuw gegenereerde ID. Genereer een lijst met members van de collectie; een lijst van alle studenten Vervang de hele collectie; wordt meestal niet gebruikt Verwijder de hele collectie; wordt meestal niet gebruikt
Wordt niet gebruikt
Vraag de gegevens van de member op Wijzig de gegevens van de member Verwijder de member uit de collectie
Authenticatie
Zoals in de vorige paragraaf is beschreven zijn RESTful webservices gebaseerd op het HTTP protocol. Daarbij is voor de inhoud van de berichten geen standaard of framework beschikbaar. Dit maakt dat authenticatie van RESTful webservices alleen vormgegeven kan worden middels bekende methoden die meestal ook bij reguliere websites worden toegepast. Samenvattend zijn de mogelijkheden:
HTTP authenticatie zoals Basic en Digest TLS (Transport Layer Security) Web Access Management product Programmatisch
Deze authenticatie methoden worden in de volgende paragrafen behandeld.
2.3.2.1
HTTP authenticatie
HTTP authenticatie is een onderdeel van het standaard HTTP protocol en wordt veel gebruikt voor websites (RFC2617, zie [3]). Alle HTTP servers ondersteunen deze methode hoewel soms extra (niet standaard aanwezige) plugins nodig zijn. 13
Er bestaan twee authenticatie schema’s in het HTTP protocol; “basic” en “digest”. Bij basic stuurt de client de loginnaam en wachtwoord met het request mee waarna deze geverifieerd worden op de server. Een belangrijk probleem met het basic authenticatie schema is dat het wachtwoord zonder encryptie (in cleartext) wordt verzonden. Het digest schema biedt hiervoor een oplossing waarbij het wachtwoord versleuteld wordt op de client voordat deze verstuurd wordt naar de server. Hoewel dit niet voorgeschreven is wordt hiervoor meestal het MD5 algoritme gebruikt. Er zijn verschillende problemen met het gebruik van HTTP authenticatie: Het basic schema verstuurt het wachtwoord onbeschermd over het fysieke netwerk. Om dit te voorkomen wordt basic authenticatie meestal gecombineerd met SSL. De standaard versleuteling voor het digest schema is niet erg sterk (128 bit MD5) en er zijn verschillende methoden bekend waarmee deze gecompromitteerd kan worden. De HTTP server moet de beschikking hebben over de loginnaam/wachtwoord combinaties van alle gebruikers (bij basic kunnen de wachtwoorden versleuteld opgeslagen zijn, bij gebruik van digest moeten de wachtwoorden als plain text opgeslagen zijn). Ieder request moet geauthenticeerd worden wat nogal wat performance kost Integriteit en confidentialiteit van berichten wordt niet gegarandeerd Voor RESTful webservices wordt veel gebruik gemaakt van HTTP basic authenticatie over SSL.
2.3.2.2
TLS
TLS (Transport Layer Security, RFC5246, zie [4]) is de opvolger van SSL en wordt veel gebruikt om het afluisteren en ongeoorloofd wijzigen van verzonden berichten te voorkomen. TLS gebruikt hiervoor authenticatie en het versleutelen van de berichten waarbij gebruik gemaakt wordt van certificaten gebaseerd op de X.509 standaard (RFC5280, zie [5]). Op het internet wordt veel gebruik gemaakt van TLS door HTTPS websites. Vaak wordt hierbij aan eenzijdige authenticatie gedaan waarbij alleen de identiteit van de HTTP server wordt gevalideerd, niet de identiteit van de client. Het door de HTTP server gepresenteerde server certificaat wordt door de client geverifieerd door na te gaan of het door een vertrouwde Certificate Authority (CA) is getekend. Zodoende weet de gebruiker bijvoorbeeld dat hij verbinding heeft met de website van zijn bank en dat hij zijn gegevens niet aan een onvertrouwde partij verstrekt. Met TLS is het echter ook mogelijk dat de client of gebruiker zich authenticeert bij de HTTP server. De client moet in een dergelijk geval ook beschikken over een certificaat van een door de server vertrouwde CA waarbij de server de mogelijkheid heeft dit certificaat te valideren. Voor meer informatie over de precieze werking van TLS, zie [6] Om TLS te gebruiken voor authenticatie van RESTful webservices moet er middels HTTP over TLS (HTTPS) gecommuniceerd worden tussen de client en de server waarbij beiden worden geauthenticeerd. Merk op dat hierbij de HTTP requests en responses niet aangepast worden aangezien TLS authenticatie op het niveau van het transport protocol wordt gedaan. Overwegingen bij het gebruik van TLS voor client authenticatie: De client moet de beschikking hebben over een client certificaat. Dit certificaat moet getekend zijn door een CA die door de server vertrouwd wordt. Voor de 14
uitgifte en beheer van client certificaten zal een PKI infrastructuur opgebouwd moeten worden. Beveiliging middels TLS is op transport niveau en daarmee point-to-point. Mogelijk wordt TLS in de DMZ van een organisatie getermineerd waardoor de ontvangende applicatie, die zich in een achterliggende netwerklaag bevindt, niet de mogelijkheid heeft om de client authenticatie uit te voeren of de identiteit te bepalen.
2.3.2.3
Web Access Management product
Bij het gebruik van een Web Access Management (WAM) product wordt de authenticatie buiten de website en webserver zelf gelegd; er wordt als het ware een authenticatie laag voor de website gelegd. Hoewel er diverse WAM producten (zoals OpenSSO en Oracle Access Manager) op de markt zijn is de werkwijze over het algemeen hetzelfde. De webserver waarop de RESTful webservice draait bevat een WAM plugin6 die zodanig is geconfigureerd dat de inkomende requests geauthenticeerd moeten zijn. Als dat niet het geval is wordt de gebruiker ge-redirect naar een login pagina van het WAM product. Nadat de client zich daar heeft geauthenticeerd wordt hij weer terug gestuurd naar de oorspronkelijke RESTful webservice URL met een authenticatie token (meestal in de vorm van een cookie). De WAM plugin controleert het token en geeft toegang tot de gevraagde URL. Aandachtspunten bij het inzetten van een WAM product voor authenticatie bij RESTful webservices: Het principe dat REST interacties stateless moeten zijn wordt bij het gebruik van WAM producten niet gehandhaafd; er wordt gebruik gemaakt van tokens om de authenticatie context tussen verschillende requests te handhaven. De REST client zal zo vormgegeven moeten zijn dat bij het openen van de login pagina de juiste credentials in de juiste vorm aangeboden worden aan het WAM product. Dit vereist enige extra intelligentie en aanpassingen aan de client.
2.3.2.4
Programmatisch
Authenticatie van RESTful webservices kan ingebouwd worden in de end-points; de client en server programmatuur die de requests en responses genereert en verwerkt. Zo kan bijvoorbeeld een op Java gebaseerde client custom HTTP headers gebruiken die door een op PHP gebaseerde RESTful webservice applicatie worden geverifieerd. Het is mogelijk zelf een programmatisch authenticatie mechanisme te bedenken, maar er zijn al een aantal (potentiële) standaarden en frameworks beschikbaar: Amazon S3 (Simple Storage Service) Dit is een online opslag webservice die door Amazon Web Services (AWS) wordt geleverd en volledig middels een RESTful webservice door de gebruiker aangestuurd kan worden. De aanroep van de AWS webservice moet in veel gevallen geauthenticeerd worden waarvoor een proprietary methode is gecreëerd (zie voor details ref[7]). Als een gebruiker zich aanmeldt voor een AWS account wordt een AWS Access Key ID (vergelijkbaar met een loginnaam) en een Secret Access Key verstrekt. Bij een aanroep van de webservice maakt de client het request. Dit request wordt samengevoegd met de Secret Access Key en hier wordt een hash (signature) van gemaakt. Het request samen met de signature wordt naar de Amazon S3 webservice gestuurd. De webservice 6
Sommige WAM producten zoals Novell Access Manager gebruiken geen webserver plugin maar werken als een soort authenticatie proxy of gateway waar al het geauthenticeerde HTTP verkeer doorheen moet en indien nodig authenticatie plaats vindt 15
valideert dat de signature een valide hash is van het request en de Secret Access Key en verwerkt vervolgens het request. De interactie hergebruikt de standaard Authorization HTTP header om de AWS Access Key ID en de signature in het request te plaatsen. Daarnaast is het mogelijk de signature in query-string parameters te zetten waardoor URL’s naar geauthenticeerde content aan derden gegeven kan worden. Er zijn verschillende libraries en tool-kits beschikbaar om communicatie met de REST interface van Amazon S3 mogelijk te maken. Overwegingen met betrekking tot de Amazon S3 REST authenticatie: Geeft message-level integriteit aangezien het request zelf onderdeel is van de signature Ieder request naar de webservice moet van een signature voorzien zijn. Het genereren hiervan kan een performance impact hebben op de client en server SSL zal gebruikt moeten worden om het afluisteren van berichten tegen te gaan (merk op dat dit niet vereist wordt bij Amazon S3). Er moet vooraf een sleutel (de Secret Access Key) afgesproken zijn tussen de client en de server. Om alle requests te kunnen valideren moet de webservice toegang hebben tot alle Access Key ID’s en Secret Access Key combinaties. OAuth OAuth is een open protocol dat eind 2007 in versie 1.0 is gepubliceerd [20]. Om officiële standaardisatie te realiseren is eind 2008 een IETF werkgroep [21] samengesteld. OAuth maakt het mogelijk voor een eindgebruiker om zijn gehoste gegevens beschikbaar te stellen aan andere websites, zonder dat daarbij zijn credentials worden gedeeld.
Figuur 5 OAuth use case De OAuth use case is weergegeven in figuur 5. Een eindgebruiker gebruikt een webapplicatie bij de Consumer waarbij de Consumer op een gegeven moment gegevens of data van de eindgebruiker nodig heeft die door de Service Provider (SP) worden gehost. Om deze gegevens bij de Service Provider te kunnen opvragen moet het volgende authenticatie proces doorlopen worden: 1. De Consumer vraagt een Request Token aan de SP 2. De Consumer geeft dit Request Token aan de eindgebruiker 3. De eindgebruiker autoriseert het Request Token door zichzelf te authenticeren bij de SP. Na authenticatie moet de gebruiker de SP toestemming geven dat de Consumer de benodigde gebruikersgegevens mag opvragen bij de SP. Optioneel is dat de gebruiker voorwaarden kan stellen aan de toegang van de Consumer tot de SP (bijvoorbeeld welke gegevens de Consumer precies mag zien en voor welke tijdsperiode de toegang geldt) 16
4. De eindgebruiker geeft het geautoriseerde Request Token aan de Consumer 5. De Consumer wisselt het geautoriseerde Request Token in bij de SP voor een Access Token 6. Met dit Access Token kan de Consumer toegang krijgen tot de eindgebruikers gegevens die gehost worden bij de SP. Bij OAuth wordt alle communicatie over HTTP(S) gedaan en worden de OAuth specifieke parameters middels HTTP headers en URL parameters gecommuniceerd. Een voorbeeld van een OAuth use case is een gebruiker die via de website van het Kruidvat foto’s wil laten afdrukken, waarbij de af te drukken foto’s bij Flickr zijn ondergebracht. OAuth is een goede oplossing voor authenticatie van RESTful webservices communicatie tussen de Consumer en de Service Provider. OAuth wordt dan ook gebruikt voor veel Google diensten zodat andere websites deze diensten met bijbehorende gebruikersdata kunnen gebruiken uit naam van de gebruiker.
17
3 Webservices, SURFnet en de SURFfederatie Welke rol SURFnet kan spelen in het faciliteren van webservices verkeer tussen instellingen (in hun rol als IdP of SP) onderling en met andere informatie aanbieders en afnemers wordt in dit hoofdstuk onderzocht. Aan de hand van use cases wordt bekeken welke interacties SURFnet wil ondersteunen en aan welke voorwaarden deze moeten voldoen. Vervolgens zal nagegaan worden hoe deze use cases ondersteund kunnen worden en welke functionaliteiten SURFnet op het gebied van webservices toe zou kunnen voegen aan de SURFfederatie. Hierbij zal met nadruk gekeken worden naar de beveiliging en hoe een combinatie van webservices met de SURFfederatie hierin kan voorzien.
3.1 Beschrijving use cases Use cases voor het gebruik van webservices door de SURFnet doelgroep moeten aan een aantal randvoorwaarden voldoen willen ze interessant zijn voor SURFnet:
De aanroep van de web service moet worden geauthenticeerd. Aangezien de webservice aanroep meestal het gevolg zal zijn van een eindgebruikers actie op een website, is er de voorkeur om de authenticatie van de eind gebruiker te hergebruiken. Merk op dat het NIET gaat om het doorgeven van de eindgebruikers identiteit. Indien een webservice de eindgebruikers identiteit nodig heeft voor de verwerking moet dit in de webservice definitie zijn opgenomen.
De webservices communicatie moet minimaal één organisatiegrens overstijgen; dus de web service consumer en provider moeten zich in verschillende organisaties bevinden. Hierbij kan een organisatie een aangesloten instelling of een andere informatie aanbieder of afnemer zijn zoals Elsevier. Webservices die alleen binnen één instelling worden gebruikt zullen de authenticatie voorzieningen van die instelling kunnen hergebruiken (buiten de SURFfederatie dus) en worden derhalve buiten beschouwing gelaten.
Met bovenstaande in gedachte kan voor de SURFnet doelgroep twee belangrijke use cases worden gemaakt die in de volgende paragrafen worden besproken.
3.1.1
Use case 1
Use case 1 gaat uit van twee instellingen; instelling 1 is hierbij de webservice client en instelling 2 is de webservice provider. Er is een eindgebruiker van instelling 1 die een webapplicatie bij zijn eigen instelling gebruikt (A). De eindgebruiker is hierbij met zijn instellingsgegevens ingelogd op de webapplicatie. Deze authenticatie zal meestal door de access management voorziening van de instelling zijn afgehandeld en niet door de SURFfederatie. Dat is in dit geval ook niet wenselijk aangezien het een gebruiker van de eigen instelling betreft en authenticatie via de SURFfederatie dan een onnodige omweg is. Op enig moment heeft deze webapplicatie een dienst nodig die bij instelling 2 wordt aangeboden. De webapplicatie gebruikt daartoe de WS Client om de WS Provider van instelling 2 aan te roepen (B). Voordat de WS Provider het verzoek verwerkt zal het verzoek moeten worden geauthenticeerd en geautoriseerd op basis van de eindgebruikers gegevens. Indien akkoord zal de WS Provider het verzoek doorgeven aan de onderliggende (legacy) applicatie. Deze zal het verzoek verwerken, een antwoord formuleren en dit middels dezelfde weg terug sturen.
18
Instelling 1
Instelling 2
Eindgebruiker
A WS Provider
Web applicatie
B
(Legacy) applicatie
WS Client
Figuur 6 Use case 1
3.1.2
Use case 2
De eindgebruiker bevindt zich nu niet meer in dezelfde instelling als de web applicatie, maar in instelling 3. De gebruiker zal voor de toegang tot de web applicatie van instelling 1 inloggen middels de SURFfederatie (B), waarbij instelling 3 optreedt als IdP en instelling 1 als SP. Dit gedeelte van de use case is dus het reguliere SURFfederatie scenario. Merk op dat binnen de SURFfederatie en deze use case de rol van SP (Instelling 1)en WS Provider (Instelling 2) ook door andere organisaties dan de aangesloten instellingen ingevuld kan worden; zoals door uitgevers (bijvoorbeeld Elsevier). De overige stappen van use case 2 zijn gelijk aan use case 1. Ook hier zal de WS Provider het web service verzoek moeten authenticeren op basis van de eindgebruikers identiteit.
Instelling 3
SURFnet
B
SURFfederatie
Eindgebruiker
Instelling 1
A
Instelling 2
Web applicatie WS Client
WS Provider
C
(Legacy) applicatie
Figuur 7 Use case 2
3.2 Toepassing webservice technieken op use cases De hiervoor beschreven use cases geven aan welke webservices interacties SURFnet zou moeten ondersteunen, namelijk B uit use case 1 en C uit use case 2. In deze paragraaf wordt nagegaan met welke webservices technieken en standaarden deze use cases ingevuld kunnen worden en welke rol SURFnet en de SURFfederatie hierin hebben. Hierbij hebben de volgende overwegingen een rol gespeeld: 19
Er zal voornamelijk ingegaan worden op use case 2. De reden hiervoor is dat gezien het gebruik van de SURFfederatie dit voor SURFnet de meest relevante use case is. Daarbij is deze case een extensie van use case 1 waardoor een invulling van use case 2 ook een oplossing kan bieden voor use case 1. Of dit ook zo is zal bij iedere beschreven oplossing worden bekeken.
De invulling van de use case zal gebaseerd worden op SOAP webservices en niet op RESTful webservices. Zoals al eerder is aangeven bestaan standaarden voor authenticatie van RESTful webservices nauwelijks (zie paragraaf 2.3.2). Dit in tegenstelling tot SOAP webservices waar standaarden die message level security mogelijk maken wel bestaan.
Met de keuze voor standaarden en SOAP web services valt ook WS-Federation af, aangezien deze nog niet volledig gestandaardiseerd is en bestaande producten vaak alleen het Web (Passive) Requestor gedeelte ondersteunen, dus het ‘web browser binding’ gedeeelte van WS-Federation dat nu ook al door de SURFfederatie wordt ondersteund maar feitelijk niet over web services gaat.
Een belangrijk principe bij de SURFfederatie is dat organisaties die met elkaar willen communiceren (waarbij één als identity provider en de ander als service provider fungeert) geen onderlinge (technische) relatie hoeven te hebben. Door het vertrouwen van beide organisaties in de SURFfederatie kunnen ze met elkaar communiceren. Dit voorkomt dat iedere service provider met iedere identity provider moet kunnen praten. Indien SURFnet geauthenticeerd webservices verkeer tussen instellingen en organisaties en instellingen onderling mogelijk wil maken zal ditzelfde principe toegepast moeten worden.
Uit een evaluatie van de verschillende beschikbare standaarden voor authenticatie van SOAP webservices zijn twee oplossingsrichtingen voor use case 2 geïdentificeerd. Dit zijn WS-Trust en het SAML ECP profile. De toepassing van deze standaarden op de use case wordt in de volgende paragrafen behandeld.
3.2.1
WS-Trust
3.2.1.1
Communicatie flow
Figuur 8 geeft de toepassing weer van WS-Trust op use case 2. Aan de hand van deze figuur wordt de communicatie flow en verschillende componenten uitgelegd (voor een beschrijving van WS-Trust en STS, zie paragraaf 2.3.2). Wederom geldt dat de rol van SP (Instelling 1) en WS Provider (Instelling 2) zowel door een instelling als door een andere organisatie ingevuld kan worden.
20
Instelling 3
SURFnet
SURFfederatie
A STS End user
A
Trust
Instelling 2
Instelling 1 Trust
WAM
STS
B
C
F
SP Web application WSS/ WS-Trust
WS Client
H WSS/ WS-Trust
E
WS Provider
I
G (Legacy) Applicatie
D Figuur 8 Toepassing WS-Trust op use case 2 A. Dit scenario start met een reguliere SURFfederatie login van een eindgebruiker bij een Service Provider (SP) webapplicatie van een andere instelling of organisatie waarbij de eigen instelling als IdP optreedt. De huidige SURFfederatie inrichting hoeft hiervoor niet te veranderen. Veel instellingen zullen een eigen Web Access Management (WAM) voorziening hebben die in de afscherming en authenticatie van de webapplicaties en in de communicatie met de SURFfederatie voorziet. Denk hierbij aan systemen als Shibboleth, A-Select, simpleSAMLphp of Sun OpenSSO. Aan het einde van deze stap zal de eindgebruiker met een valide SURFfederatie SAML token bij de WAM voorziening aankomen. B. Na validatie van het SAML token zal de WAM voorziening een eigen, proprietary sessie token genereren waarmee de eindgebruiker zich voor volgende bezoeken kan authenticeren (tot een logout of sessie time-out optreedt). Merk op dat nagenoeg alle WAM producten na een federatieve login opvolgende authenticaties middels een eigen WAM token laten lopen. De eindgebruiker wordt nu doorgelaten tot de webapplicatie en kan deze gebruiken. Tot zover is er geen verschil met het huidige gebruik van SURFfederatie. C. Op enig moment moet de webapplicatie communiceren met een SOAP webservice bij instelling 2. Hiertoe roept de webapplicatie de WS Client aan. De WS Client is niet een apart proces maar is een apart stuk code welke de aanroep van de webapplicatie om kan zetten in een SOAP request bericht voor de WS Provider. Om webservices authenticatie in de volgende stappen mogelijk te maken moet de WS Client de beschikking hebben over het WAM token.
21
D. De WS Client heeft het SOAP request gemaakt maar heeft nog geen security elementen toegevoegd aan de SOAP headers. Hiertoe wordt het request nu doorgegeven aan het security deel van de WS Client. Hierbij moet ook het WAM token meegegeven worden. Het security deel is eveneens een stuk code die WS-Security en WS-Trust libraries tot zijn beschikking heeft. E. Het WSS/WS-Trust security deel van de WS Client gaat nu het WAM token (welke alleen betekenis heeft binnen instelling 1) inwisselen voor een SAML token die ook vertrouwd wordt door de SURFnet STS. Om dit inwisselen mogelijk te maken moet instelling 1 een STS hebben die WAM tokens kan valideren. Inwisselen gaat in WSTrust met een “Issuance binding” waarbij de Client een Request Security Token (RST) bericht met daarin het WAM token naar de lokale STS stuurt. Deze zal het WAM token valideren, een SAML token genereren en deze in een Request Security Token Response (RSTR) bericht terug sturen naar de Client. De Client heeft nu de beschikking over een lokaal SAML token uitgegeven door instelling 1. F. Het WSS/WS-Trust security deel van de WS Client gaat nu het lokale SAML token inwisselen voor een SAML token dat uitgegeven is door SURFnet. Hiertoe stuurt de Client een RST bericht naar de SURFnet STS met daarin het lokale SAML token. De SURFnet STS valideert dit token (op basis van de trust relatie met de STS van instelling 1), genereert een SURFnet SAML token en stuurt dit middels een RSTR bericht terug naar de Client. Door vooraf ingestelde trust relaties wordt dit SURFnet SAML token door alle aangesloten instellingen vertrouwd. G. Het WSS/WS-Trust security deel van de WS Client kan nu de security headers aan het SOAP request toevoegen, inclusief het SURFnet SAML token. Eventuele andere security gerelateerde zaken zoals encryptie en signing worden nu ook toegevoegd. Het SOAP request wordt vervolgens naar de WS Provider van instelling 2 gestuurd. H. Aan de WS Provider kant zal ook een WSS/WS-Trust security deel aanwezig zijn om te kunnen valideren dat het aangeboden SAML token door een vertrouwde STS is afgegeven en om eventuele andere security elementen te interpreteren en te valideren (zoals het valideren van de signature en het decrypten van onderdelen van de SOAP body). Door het vooraf vastgestelde vertrouwen tussen instelling 2 en SURFnet zal het SURFnet SAML token gevalideerd kunnen worden. Naast validatie middels een trust relatie is het ook mogelijk het SAML token bij de SURFnet STS te valideren middels een WS-Trust “validation binding”. Het SOAP request is nu van alle security headers ontdaan en wordt aan de WS Provider programmatuur gegeven. Hierbij kan de identiteit van de eindgebruiker meegegeven worden voor bijvoorbeeld logging doeleinden. Merk op dat als de WS Provider voor een correcte verwerking van een SOAP request de eindgebruikers identiteit werkelijk nodig heeft, deze identiteit onderdeel moet zijn van de SOAP body. I. De WS Provider programmatuur zal het SOAP request verwerken door de relevante operaties in de onderliggende (legacy) applicatie uit te voeren. De applicatie op zijn beurt formuleert een antwoord, geeft dit terug aan de WS Provider die dit middels een SOAP response terug stuurt naar de WS Client. Deze terugweg bevat verder geen authenticatie meer, maar kan wel andere security elementen bevatten t.b.v. signing en encryptie. Deze worden dan weer door de WSS/WS-Trust security delen toegevoegd en gevalideerd.
22
Opmerkingen over bovenstaande stappen: De WS Provider kan aangeven welke security policy gehanteerd wordt om een verzoek te kunnen accepteren. Dit kan middels de WS-Policy standaard waarmee bijvoorbeeld het geaccepteerde token type wordt aangegeven. Een WS Client zou dan ook eerst kunnen navragen welke security policy een WS Provider hanteert voordat een webservice verzoek wordt gedaan.
3.2.1.2
Mogelijke varianten en aanvullingen
Op de communicatie flow uit de vorige paragraaf zijn een aantal varianten en aanvullingen mogelijk. Deze worden hieronder weergegeven:
In plaats van het inwisselen van het WAM token in een lokaal SAML token zou de STS van instelling 1, na validatie van het WAM token meteen een SURFnet SAML token kunnen opvragen bij de SURFnet STS. Stap F wijzigt dan en zal plaats vinden tussen de instelling 1 STS en de SURFnet STS. Op deze manier hoeft de WS Client maar één keer een STS aan te spreken. In WS-Trust wordt dit aangegeven met “On-behalf-of” parameters (zie [15]).
Instelling 2 kan ook een lokale STS hebben. De WS Provider zou dan deze STS voor validatie van het SURFnet SAML token kunnen aanroepen. Door een trust relatie tussen de instelling 2 STS en SURFnet STS kan dit token gevalideerd worden. Deze opzet zorgt ervoor dat een WS Provider alleen de lokale STS hoeft te vertrouwen en te kennen. Dit is een voordeel als er binnen instelling 2 ook lokale WS Clients zijn die met een lokale sessie de WS Provider aanroepen, of als er tokens gebruikt kunnen worden uit andere dan de SURFnet federatie. De lokale STS zorgt dan voor validatie van tokens, ongeacht of deze uit een lokale sessie store komen of uitgegeven zijn door de SURFnet of andere STS.
Mogelijk kan de WS Client het originele SAML token (verkregen door de eindgebruiker in stap A) gebruiken om rechtstreeks bij de SURFnet STS in te wisselen voor een SURFnet SAML token. Hierdoor zou een lokale STS overbodig worden; stap E wordt dan vervangen door stap F waarbij het originele SAML token wordt aangeboden aan de SURFnet STS. Voordat deze variant zou kunnen werken moet aan een aantal voorwaarden voldaan worden. Zo zou het eindgebruikers SAML token door de WAM voorziening doorgegeven moeten worden tot aan de WS Client. Verder zou, analoog aan het SAML ECP profile (zie paragraaf 3.2.2), de originele SAML assertion verkregen door de eindgebruiker in stap A met een extra <SubjectConfirmation> element aangevuld moeten worden. Zodoende zou dit SAML token later ook gevalideerd kunnen worden door de SURFnet STS. Er moet dan ook een trust relatie zijn tussen de SURFnet STS en de SURFfederatie.
Het is mogelijk dat gedurende een gebruikerssessie van de webapplicatie meerdere aanroepen van dezelfde webservice nodig zijn. Om voor iedere aanroep de WSTrust stappen uit te voeren kan teveel overhead veroorzaken, niet alleen voor de Client maar ook voor de STS bij SURFnet. Om dit te voorkomen kan er na de eerste succesvolle aanroep (stap H) een security context opgebouwd worden tussen de WS Client en de WS Provider middels een sessie. De WS Client kan dan bij volgende aanroepen een cookie met een sessieID meesturen die de WS Provider direct kan valideren. Aangezien dit op HTTP niveau plaats vindt worden de SOAP berichten hier zelf niet door beïnvloed. Merk op dat het opbouwen van deze security context geen onderdeel is van de gebruikte standaarden maar specifiek zal zijn voor de geïmplementeerde producten.
Een andere mogelijke methode om een security context op te zetten tussen de WS Client en WS Provider na de initiële authenticatie, wordt door WSSecureConversation gedefinieerd [18]. Deze OASIS standaard bouwt voort op WSSecurity en WS-Trust om een security context voor meerdere webservice berichten 23
binnen een sessie op te zetten. Hierbij worden nieuwere, efficiëntere tokens ingezet die de snelheid en veiligheid vergroten.
3.2.1.3
Consequenties van WS-Trust
Een mogelijke implementatie van WS-Trust in de SURFfederatie en bij instellingen heeft een aantal consequenties. Deze worden hieronder beschreven. Voor SURFnet: SURFnet zal een STS moeten inrichten en zal een procedure moeten opzetten om trust relaties met STS-en van instellingen te definiëren en uit te wisselen. Voor instellingen die webservices willen gebruiken:
Een instelling die als consumer van een webservice wil optreden zal een lokale STS moeten inrichten die een trust relatie heeft met de SURFnet STS.
3.2.1.4
Toepasbaarheid op use case 1
De hier geschetste oplossing van use case 2 met behulp van WS-Trust is ook goed toepasbaar op use case 1. Zowel in use case 1 als in use case 2 heeft de eindgebruiker een lokale WAM sessie welke ingewisseld kan worden bij de lokale STS voor een lokaal SAML token. Dat de ene keer de authenticatie middels de SURFfederatie plaats vindt en de andere keer via de lokale WAM voorziening doet hierbij niet ter zake.
3.2.2
SAML ECP profile
Naast het Web Browser SSO profile welke gebruikt wordt door bijvoorbeeld de SURFfederatie voor interactieve login van eindgebruikers kent de SAML standaard nog andere profiles [12]. Eén daarvan is het Enhanced Client or Proxy (ECP) profile welke gebruikt kan worden door client software of proxies voor federatieve authenticatie. Hierbij hoeft geen interactie met een eindgebruiker nodig te zijn voor bijvoorbeeld IdP selectie of authenticatie. Het SAML ECP profile specificeert niet hoe authenticatie bij de IdP plaats moet vinden (stap G in figuur 9). Een specifiekere versie van het SAML ECP profile, namelijk het IDWSF ECP profile [13], legt de authenticatie mogelijkheden wel vast zodat een SAML token over een SOAP connectie mogelijk is. Hier wordt dan ook het ID-WSF ECP profile gebruikt welke hier al eerder is aangehaald bij de ID-WSF SSO Service in paragraaf 2.2.5. Merk op dat behalve deze aanscherping van het SAML ECP profile beide profiles identiek zijn.
3.2.2.1
Communicatie flow
Figuur 9 geeft de toepassing weer van het SAML ECP profile op use case 2. Aan de hand van deze figuur wordt de communicatie flow en verschillende componenten uitgelegd. Ook hier geldt weer dat de rol van SP (Instelling 1) en WS Provider (Instelling 2) zowel door een instelling als door een andere organisatie ingevuld kan worden.
24
Figuur 9 Toepassing SAML ECP profile op use case 2 A. Dit scenario start met een eindgebruiker die een webpagina opent bij een Service Provider (SP) webapplicatie van een andere instelling. Veel instellingen zullen een eigen Web Access Management (WAM) voorziening hebben die in de afscherming en authenticatie van de webapplicaties en in de communicatie met de SURFfederatie voorziet. De WAM voorziening zal de eindgebruiker naar de SURFfederatie redirecten voor authenticatie. Merk op dat het SAML
in deze redirect een extra element kan bevatten zodat het in de volgende stap verstrekte SAML token later hergebruikt kan worden. B. Nadat de eindgebruiker zich bij de SURFfederatie heeft geauthenticeerd zal de SURFfederatie een SAML token genereren en deze via de eindgebruiker aan de WAM voorziening aanbieden. Deze SAML moet een extra <SubjectConfirmation> element bevatten. Deze <SubjectConfirmation> geeft aan dat SURFfederatie het verstrekte SAML token later ook kan consumeren (stap G). Dit extra <SubjectConfirmation> element wordt aan het token toegevoegd doordat het oorspronkelijke verzoek een extra element bevatte. Volgens de SAML standaard is het echter niet verplicht dit element toe te voegen. Een andere mogelijkheid is om de SURFfederatie dit <SubjectConfirmation> element ongevraagd toe te voegen aan de SAML . C. Na validatie van het SURFfederatie SAML token zal de WAM voorziening een eigen, proprietary sessie token genereren waarmee de eindgebruiker zich voor volgende bezoeken kan authenticeren (tot een logout of sessie time-out optreedt). Merk op dat nagenoeg alle WAM producten na een federatieve login vervolg authenticaties middels een eigen WAM token laten lopen. De eindgebruiker wordt nu doorgelaten tot de webapplicatie en kan deze gebruiken. Voor later gebruik (in stap G) zal de webapplicatie van de WAM voorziening het SURFfederatie SAML token door moeten krijgen. WAM producten hebben hier meestal verschillende mogelijkheden voor zoals het plaatsen van het SAML token als attribuut in de lokale sessie of het meegeven van het token in een cookie. 25
D. Op enig moment moet de webapplicatie communiceren met een SOAP webservice bij instelling 2. Hiertoe roept de webapplicatie de WS Client aan. De WS Client is niet een apart proces maar is een apart stuk code welke de aanroep van de webapplicatie om kan zetten in een SOAP request bericht voor de WS Provider. Nadat de WS Client het SOAP request heeft gemaakt moeten er nog security elementen toegevoegd worden aan de SOAP headers. Hiertoe wordt het request doorgegeven aan het security deel van de WS Client (WSS/SAML). Het security deel is eveneens een stuk code die WS-Security en SAML ECP libraries tot zijn beschikking heeft. Om webservices authenticatie nu mogelijk te gaan maken moet de WS Client het SURFfederatie SAML token van de webapplicatie doorgekregen hebben en aan de security libraries ter beschikking stellen. E. Het SOAP request, eventueel aangevuld met security gerelateerde zaken zoals encryptie en signing maar zònder authenticatie wordt verstuurd naar de WS Provider van instelling 2. F. Het security deel van de WS Provider zal het SOAP request evalueren en tot de conclusie komen dat er geen geldige authenticatie voor het verzoek aanwezig is in de SOAP headers. De WS Provider zal nu antwoorden met een PAOS bericht die een SAML bevat. G. Om het SAML te kunnen inwilligen zal de WS Client (WSS/SAML) een Identity Provider moeten bepalen. In dit geval zal dit altijd de SURFfederatie zijn. De WS Client biedt het SAML aan de SURFfederatie aan en authenticeert zichzelf daarbij met het eerder verkregen SURFfederatie SAML token. Vergelijk dit met het reguliere SAML SSO profiel, maar dan is de user de WS Client. De SURFfederatie kan dit SURFfederatie SAML token voor authenticatie gebruiken vanwege de eerder (door zichzelf) toegevoegde <SubjectConfirmation> element. Merk op dat dit SURFfederatie SAML token nog steeds de eindgebruiker als subject heeft. Deze stap wordt middels een SOAP bericht gedaan. Het antwoord van de SURFfederatie is een SOAP bericht met de SAML met daarin het SAML token bedoeld voor de WS Provider. H. De WS Client (WSS/SAML) zal dit nieuwe SAML token verwerken in de security headers van het oorspronkelijke SOAP request en deze aan de WS Provider sturen. De WS Provider (WSS/SAML) valideert het SAML token door de vooraf opgezette trust relatie met de SURFfederatie. Daarnaast wordt eventueel overige security informatie in de SOAP request headers gevalideerd en verwijderd. I. Het SOAP request wordt nu doorgegeven aan de WS Provider code. Hierbij kan de identiteit van de eindgebruiker meegegeven worden voor bijvoorbeeld logging doeleinden. Merk op dat als de WS Provider voor een correcte verwerking van een SOAP request de eindgebruikers identiteit werkelijk nodig heeft, deze identiteit onderdeel moet zijn van de SOAP body. J. De WS Provider programmatuur zal het SOAP request verwerken door de relevante operaties in de onderliggende (legacy) applicatie uit te voeren. De applicatie op zijn beurt formuleert een antwoord, geeft dit terug aan de WS Provider die dit middels een SOAP response terug stuurt naar de WS Client. Deze terugweg bevat verder geen authenticatie meer, maar kan wel andere security elementen bevatten t.b.v. signing en encryptie. Deze worden dan weer door de WSS/WS-Trust security delen toegevoegd en gevalideerd. Opmerkingen over bovenstaande stappen:
De stappen E t/m H zijn onderdeel van het ID-WSF ECP profile 26
De authenticatie van de WS Client naar de SURFfederatie in stap G wordt beschreven in het ID-WSF ECP profile en moet bestaan uit één van de authenticatie mechanismen zoals beschreven in de Liberty Security Mechanisms [14]
3.2.2.2
Mogelijke varianten en aanvullingen
Op de communicatie flow uit de vorige paragraaf zijn een aantal varianten en aanvullingen mogelijk. Deze worden hieronder weergegeven:
De stappen E en F kunnen mogelijk overgeslagen worden. In dat geval maakt de WS Client zelf een verzoek om aan de SURFfederatie aan te bieden. Hiervoor moet dan het ID-WSF SAML Token Service Profile [13] gebruikt worden.
Het is mogelijk dat gedurende een gebruikerssessie van de webapplicatie meerdere aanroepen van dezelfde webservice nodig zijn. Om voor iedere aanroep de stappen uit het ECP profile te volgen kan teveel overhead veroorzaken, niet alleen voor de Client maar ook voor de SURFfederatie. Om dit te voorkomen kan er na de eerste succesvolle aanroep (stap H) een security context opgebouwd worden tussen de WS Client en de WS Provider middels een sessie. De WS Client kan dan bij volgende aanroepen een cookie met een sessieID meesturen die de WS Provider direct kan valideren. Aangezien dit op HTTP niveau plaats vindt worden de SOAP berichten hier zelf niet door beïnvloed. Merk op dat het opbouwen van deze security context geen onderdeel is van de gebruikte standaarden maar specifiek zal zijn voor de geïmplementeerde producten.
3.2.2.3
Consequenties van SAML ECP profile
Een mogelijke implementatie van het SAML ECP profile in de SURFfederatie en bij instellingen heeft een aantal consequenties. Deze worden hieronder beschreven. Voor SURFnet: Op dit moment gebruikt de SURFfederatie het SAML Web Browser SSO profile. Dit zal uitgebreid moeten worden met de mogelijkheid om extra <SubjectConfirmation> elementen toe te voegen aan de SAML berichten (zie stap B uit figuur 9). De huidige SURFfederatie moet het ID-WSF ECP Profile gaan ondersteunen wat o.a. betekent dat de SURFfederatie SOAP berichten kan verwerken (zie stap G uit figuur 9). Voor instellingen die webservices willen gebruiken: De WAM voorziening van een instelling moet aangepast worden zodat bij de SURFfederatie verkregen SAML tokens aan webapplicaties doorgegeven kunnen worden. De aanbieder van webservices zal het ECP profile moeten ondersteunen.
3.2.2.4
Toepasbaarheid op use case 1
De geschetste oplossing van use case 2 met behulp van het SAML ECP profile is niet goed in te zetten voor use case 1. De reden hiervoor is dat dit profile uitgaat van een initiële authenticatie van de eindgebruiker bij de SURFfederatie aangezien de gebruiker zich in een andere instelling bevindt dan de aangeroepen webapplicatie. De webapplicatie heeft 27
zodoende een SAML token tot zijn beschikking die het ECP profile kan hergebruiken voor authenticatie (stap G in figuur 9). In use case 1 bevindt de eindgebruiker zich bij dezelfde instelling als de gebruikte webapplicatie waardoor een authenticatie bij de SURFfederatie als een omweg beschouwd kan worden. De authenticatie zal eerder door de instelling lokaal gedaan worden waardoor er geen SURFfederatie SAML token bestaat en het ECP profile niet uitgevoerd kan worden.
3.3 Conclusie en aanbeveling Op basis van de beschrijvingen en eigenschappen van de communicatie flow van WSTrust en het SAML ECP profile als oplossing van de use cases kunnen een aantal conclusies worden getrokken en kan een aanbeving gedaan worden.
Zowel WS-Trust als het SAML ECP profile kan use case 2 invullen. Echter, zoals in paragraaf 3.2.2.4 is beschreven kan het SAML ECP profile niet voorzien in use case 1.
Na een kort onderzoek op internet is gebleken dat het SAML ECP profile nauwelijks gebruikt wordt en dat de ondersteuning door producten zeer beperkt is7, dit in tegenstelling tot WS-Trust (zie paragraaf 2.2.3).
Het SAML ECP profile vereist een aanpassing aan de bestaande WAM voorziening (moet nu het SAML token doorgeven aan achterliggende webapplicaties) wat voor een instelling drempelverhogend werkt en wat voor diverse verschillende WAM producten uitgezocht zal moeten worden. Voor het gebruik van WS-Trust zijn veel minder aanpassingen nodig aan de kant van Service Providers.
Het SAML ECP profile vereist ook aanpassingen aan de kant van SURFnet. Het IDWSF ECP profile (en daarmee SOAP) zal moeten worden ondersteund en er zullen extra <SubjectConfirmation> elementen aan SAML berichten toegevoegd moeten worden. Deze extra elementen kunnen tot problemen leiden bij de communicatie met Service Providers als ze niet goed geïnterpreteerd worden door de gebruikte WAM voorziening.
Het opzetten van een SURFnet STS past goed bij de rol die SURFnet al heeft binnen de SURFfederatie en kan worden geïmplementeerd zonder aanpassingen aan (en zelfs volledig losstaand van) de huidige SURFfederatie. Het opzetten van een STS heeft dan ook geen impact op de werking van de SURFfederatie zelf.
Het door de SURFfederatie gebruikte PingFederate heeft in versie 6 ondersteuning voor een STS. Hoewel de SURFfederatie nu gebruik maakt van een eerdere release van PingFederate, zal het bij gebleken geschiktheid het ondersteunen van een STS rol hiermee wel gemakkelijker worden voor de SURFfederatie en mogelijk kunnen worden meegenomen in een upgrade naar een nieuwe versie van PingFederate.Op basis van bovenstaande conclusies wordt aanbevolen om de proof of concept uit te voeren met een oplossing op basis van WS-Trust.
7
Alleen Sun OpenSSO ondersteunt het SAML ECP profile 28
4 Proof Of Concept In navolging van de aanbeveling uit het vorige hoofdstuk wordt een Proof Of Concept (POC) voorgesteld op basis van WS-Trust. Deze POC zal use case 2 met WS-Trust invullen zoals weergegeven in figuur 8. Voorgesteld wordt om de SURFnet STS te implementeren middels PingFederate 6 aangezien dit product (weliswaar een oudere versie) ook gebruikt wordt voor de implementatie van de SURFfederatie. De Proof of Concept dient wel los van de huidige SURFfederatie opgezet te worden. Daarbij zal een STS van een instelling in eerste instantie eveneens geïmplementeerd worden met PingFederate 6. Mocht er tijd over zijn kan een STS van een andere leverancier getest worden (bijvoorbeeld OpenSSO). De webservices client en provider die in de POC worden gebruikt zullen een eenvoudige webservice implementeren. De inhoud van de webservice is hierbij van minder belang, er zal voornamelijk aandacht besteed worden aan de webservices authenticatie. Indien de uitvoering van de POC voorspoedig gaat zullen verschillende varianten van het WS-Trust scenario worden uitgevoerd. Hierbij is de eerste variant, zoals beschreven in paragraaf 3.2.1.2, het meest interessant aangezien deze de webservices client implementatie vereenvoudigt.
29
5 Referenties [1] W3C Web Services glossary (http://www.w3.org/TR/ws-gloss/) [2] W3C Web Services Architecture (http://www.w3.org/TR/ws-arch) [3] HTTP Authentication, RFC2617 (http://www.ietf.org/rfc/rfc2617.txt) [4] The Transport Layer Security Protocol version 1.2, RFC5246 (http://www.ietf.org/rfc/rfc5246.txt) [5] Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC5280 (http://www.ietf.org/rfc/rfc5280.txt) [6] Transport Layer Security, Wikipedia (http://en.wikipedia.org/wiki/Transport_Layer_Security) [7] Amazon S3, Authenticating REST requests (http://docs.amazonwebservices.com/AmazonS3/latest/RESTAuthentication.html) [8] Web Services @ W3C (http://www.w3.org/2002/ws/) [9] SOAP Version 1.2 Part 0: Primer (http://www.w3.org/TR/soap12-part0/) [10] Web Services Definition Language (WSDL) Version 2.0 Part 0: Primer (http://www.w3.org/TR/wsdl20-primer/) [11] Web Services Security: SOAP Message Security 1.1 (http://docs.oasisopen.org/wss/v1.1/wss-v1.1-spec-errata-os-SOAPMessageSecurity.pdf) [12] Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0 (http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf) [13] Liberty ID-WSF Authentication, Single Sign-On, and Identity Mapping Services Specification, version 2.0-errata-v1.0 (http://www.projectliberty.org/liberty/content/download/3439/22943/file/liberty-idwsfauthn-svc-2.0-errata-v1.0.pdf) [14] Liberty ID-WSF Security Mechanisms Core, version 2.0-errata-v1.0 (http://www.projectliberty.org/liberty/content/download/3478/23060/file/liberty-idwsfsecurity-mechanisms-core-2.0-errata-v1.0.pdf) [15] WS-Trust v1.4, OASIS (http://docs.oasis-open.org/ws-sx/ws-trust/v1.4/os/wstrust-1.4-spec-os.pdf) [16] Web Services Federation Language (WS-Federation) Version 1.2, OASIS (http://docs.oasis-open.org/wsfed/federation/v1.2/ws-federation.pdf) [17] Understanding WS-Federation, version 1.0, Microsoft and IBM, (http://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-fed/WSFederationSpec05282007.pdf) [18] WS-SecureConversation, version 1.4, OASIS (http://docs.oasis-open.org/wssx/ws-secureconversation/v1.4/os/ws-secureconversation-1.4-spec-os.pdf) [19] Liberty Alliance Web Services Framework: A Technical Overview, Version 1.0, Liberty Alliance Project (http://www.projectliberty.org/liberty/content/download/4120/27687/file/idwsf-introv1.0.pdf) [20] OAuth Core 1.0 (http://oauth.net/core/1.0/) [21] IETF OAuth Charter (http://www.ietf.org/html.charters/oauth-charter.html)
30
