SAML en XACML
Een tweede belangrijke standaardisatie organisatie is OASIS (Organization for the Advancement of Structured Information Standards). Het eerste belangrijke initiatief van OASIS is SAML (Security Assertions Markup Language). Dit is een op XML-gebaseerd modulair raamwerk dat Webservices in staat stelt om security gerelateerde gegevens uit te wisselen. Deze gegevens hebben betrekking op authenticatie- en autorisatiegebeurtenissen die eerder hebben plaatsgevonden. De werking bestaat hieruit dat met behulp van vertrouwde verklaringen (trusted statements) zogenaamde beweringen (assertions) over eindgebruikers, Webservices of andere entiteiten met een digitale identiteit, in XML beschreven en vervolgens, via bijvoorbeeld SOAP berichten, worden uitgewisseld. Figuur 10 geeft het conceptuele model van SAML weer, waarbij opgemerkt moet worden dat de afgebeelde Authorities gecombineerd kunnen worden in een product of dienst.

Voorbeeld van een authenticatiebewering:
“subject Alice was authenticated by means X.509 certificate at time 12.00 o’clock”.

Voorbeeld van een autorisatiebeslissingbewering:
“subject Alice for action Read on resource file index.html given evidence authentication assertion A”.


Figuur 10. SAML domein model

De vertrouwelijkheid en integriteit van SAML assertions kunnen worden gegarandeerd door gebruik te maken van de basisbouwblokken XML Encryption en XML Signature.
Op dit moment bieden fabrikanten leverancierseigen single sign-on oplossingen die niet met elkaar kunnen samenwerken en die vaak cookie-gebaseerd zijn. Het gebruik van dit soort oplossingen blijft vaak beperkt tot enkelvoudige domeinen, omdat cookies in de regel domeingebonden zijn en niet makkelijk uitwisselbaar zijn met andere DNS domeinen. SAML adresseert deze uitdaging door applicaties af te schermen van de complexiteit van de onderliggende authenticatie- en autorisatiesystemen. SAML maakt single sign-on zonder cookies mogelijk door op een gestandaardiseerde manier gebeurtenissen te beschrijven en deze op een gestandaardiseerde manier uit te wisselen, onafhankelijk van de onderliggende applicaties. SAML assertions kunnen worden uitgewisseld met behulp van diverse technieken, waaronder een SAML-binding voor SOAP over HTTP en pull en push (HTTP POST) methoden. Ook is het gebruik van cookies, om SAML assertions in op te slaan, mogelijk.
Het is belangrijk te onderkennen dat SAML géén authenticatieprotocol is. SAML beperkt zich uitsluitend tot het uitwisselen van beweringen over bepaalde authenticatie- en autorisatiegebeurtenissen die hebben plaatsgevonden. Het authenticatieproces en –mechanisme valt buiten de scope van het SAML protocol.

XACML (XML Access Control Markup Language) is een XML taal om policies met betrekking tot toegangscontrole gedetailleerd te beschrijven en uit te wisselen. Het is ontworpen om naadloos te integreren met SAML. XACML levert flexibiliteit waarmee het mogelijk is om selectief te kunnen definiëren welke entiteiten (bijv. gebruikers, Webservices) bepaalde privileges hebben op documenten. Deze documenten hoeven niet noodzakelijkerwijs XML documenten te zijn. In de praktijk zal het veel vaker voorkomen dat het documenten betreft van verschillende gangbare formaten zoals HTML, Word of PDF. Net zoals de andere protocollen schrijft XACML geen specifiek communicatieprotocol voor en zouden XACML berichten via verschillende transportprotocollen uitgewisseld kunnen worden.


Figuur 11. XACML domein model

Figuur 11 geeft het conceptuele model weer van XACML. Merk hierbij op dat SAML in dit plaatje een belangrijke rol speelt. Een aantal aspecten uit de SAML en XACML specificaties is conceptueel. Er zijn verschillende ontwerpen en implementaties mogelijk en in de praktijk zal blijken dat fabrikanten deze oplossingen op verschillende manieren zullen implementeren. Het is cruciaal dat hierbij interoperabiliteit niet uit het oog wordt verloren om acceptatie door de markt niet te frustreren. SAML en XACML zijn overigens op zichzelf staande standaarden die niet noodzakelijkerwijs in een Webservices omgeving gebruikt hoeven te worden.,WS-Security
Een van de belangrijkste Webservices security initiatieven is een gezamenlijke inspanning van Microsoft, IBM en VeriSign. In april 2002 hebben zij de WS-Security roadmap en de eerste specificaties van het basis WS-Security raamwerk gepubliceerd. WS-Security is een set van SOAP extensies die gebruikt kunnen worden om de integriteit, vertrouwelijkheid en authenticiteit van SOAP berichten te waarborgen. Het is ontworpen met het idee om andere (bestaande) security technologieën te abstraheren in claims en tokens. Hierbij kan gedacht worden aan verschillende soorten tokens, digitale handtekeningformaten en encryptie technologieën. WS-Security is het security raamwerk voor Webservices. Het definieert hoe tokens aangevraagd en gekoppeld kunnen worden met identiteiten. Daarnaast definieert het hoe dit via SOAP berichten uitgewisseld kan worden en hoe de XML security specificaties (XML Signature/XML Encryption) gebruikt kunnen worden om deze tokens en/of andere SOAP data te beschermen. Het is belangrijk dat de authenticiteit van de zender onweerlegbaar kan worden vastgesteld door de ontvangende partij. Technisch gezien levert XML Signature alleen data integriteit, maar als er een identiteit gekoppeld is aan een privésleutel dan kan XML Signature ook voor authenticatie en onweerlegbaarheid worden gebruikt. Praktisch gezien betekent dit dat er XML elementen en XML attributen gedefinieerd en vastgelegd zijn om op een gestandaardiseerde manier tokens, XML encryptieblokken en XML signatureblokken in SOAP berichten te kunnen opnemen en te kunnen uitwisselen.

WS-Security wordt in de vakpers soms ten onrechte vergeleken met SAML. Het zijn echter geen concurrerende standaarden, maar aanvullende. WS-Security beschrijft hoe security informatie in SOAP berichten wordt opgenomen en SAML beschrijft om welke security informatie het gaat (wat).

Figuur 12. WS-Security roadmap

WS-Security familie
De roadmap bevat nog een aantal andere initiatieven die ook tot de WS-Security familie behoren (figuur 12). De basis WS-Security standaard beschrijft eigenlijk alleen maar hoe claims, credentials en tokens op een veilige manier uitgewisseld kunnen worden. Voor serieuze B2B toepassingen met Webservices technologie in een open marktsituatie is er behoefte aan duidelijke beleidsrichtlijnen en vertrouwensmodellen. Ook hierin voorziet WS-Security door middel van wat meer ‘zachte’ protocollen. Dit zijn: WS-Policy, WS-Trust, WS-Privacy, WS-SecureConversation, WS-Federation en WS-Authorization. Een aantal van deze specificaties is nog niet gereed en zullen in de loop van de tijd gepubliceerd worden. Deze specificaties beschrijven security policies, privacyrichtlijnen, vertrouwensmodellen, autorisatiemodellen en security management voor federated toepassingen (federated applicaties zijn netwerken van Webservices).

WS-Policy beschrijft de capaciteiten en beperkingen van een Webservice. Het stelt organisaties in staat om de security vereisten met betrekking tot hun Webservices te specificeren. Met WS-Policy geef je aan welke tokens, privacy attributen en algoritmes voor encryptie en integriteitcontrole door je aangeboden Webservices worden ondersteund en welke van de parameters versleuteld aangeleverd dienen te worden.

WS-Trust werkt nauw samen met WS-Policy en definieert een model om vertrouwensrelaties tussen Webservices op te zetten en te controleren. Relaties tussen Webservices en andere entiteiten kunnen direct zijn, maar kunnen ook gebruik maken van een andere Webservice die als intermediair fungeert. De intermediair kan in naam van een Webservice of eindgebruiker opereren. Het kan WS-Policy uitlezen en op basis daarvan een geschikt security token aanvragen bij een vertrouwde partij en vervolgens toevoegen aan een SOAP bericht om de Webservice of de gebruiker te representeren. Om dit mogelijk te maken levert WS-Trust een mechanisme voor delegatie en imitatie (impersonation).

WS-SecureConversation beschrijft hoe de uitwisseling van berichten eenvoudig gemanaged en geauthenticeerd kunnen worden. De huidige versie van het SOAP protocol kent geen sessiecontext voor een groep van SOAP berichten. Dit kan betekenen dat bij ieder inkomend SOAP bericht een heel proces doorlopen moet worden waarbij het bericht ontcijferd wordt en sleutels of credentials geëvalueerd en gevalideerd worden. Omdat er geen sessiecontext is, moeten deze stappen voor ieder SOAP bericht worden herhaald wat ten koste gaat van de prestatie. Cryptografische operaties zijn immers rekenintensief. Indien grote hoeveelheden berichten versleuteld en/of digitaal ondertekend uitgewisseld worden, is er behoefte aan essentiële zaken zoals sleutel- en sessiemanagement. WS-SecureConversation levert een oplossing waarbij een wederzijds geauthenticeerde security context wordt opgezet. Het borduurt voort op het feit dat symmetrische versleuteling sneller is dan asymmetrische versleuteling. Via een asymmetrisch proces wordt een symmetrische sessiesleutel afgesproken. Deze sleutel wordt vervolgens voor een hele serie van SOAP berichten gebruikt. WS-SecureConversation is een soort SSL oplossing op berichtenniveau in een Webservices omgeving.

De WS-Federation specificaties beschrijven hoe vertrouwensrelaties in heterogene federated omgevingen gemanaged kunnen worden. WS-Federation zorgt er voor dat organisaties in een enkelvoudige virtueel security domein kunnen opereren. Het levert een oplossing om met verschillende identiteitstandaarden te kunnen omgaan. Een organisatie ondersteunt bijvoorbeeld alleen maar Kerberos, terwijl een partner alleen maar X.509 ondersteunt. Het WS-Federation protocol treedt op als “tussenpersoon” om beide partijen toch met elkaar op een veilige manier te kunnen laten communiceren. Een eindgebruiker kan zich authenticeren bij Webservice A en vervolgens gebruik maken van Webservice B zonder zich daar opnieuw te authenticeren. WS-Federation werkt samen met WS-Trust en WS-SecureConversation. Bekende federated identiteitsystemen zijn Microsoft Passport en Liberty Alliance.

De specificaties van de laatste twee initiatieven zullen waarschijnlijk dit jaar worden vrijgegeven. Het betreft hier WS-Privacy dat antwoord moet gaan geven op de vraag hoe omgegaan wordt met privacyaspecten van organisaties of individuen binnen een Webservices omgeving. Met behulp van WS-Privacy worden privacy policies beschreven en gecommuniceerd zodat andere partijen hiervan kennis kunnen nemen en zich hieraan kunnen conformeren. Het laatste initiatief WS-Authorization zal tenslotte het management van autorisatiedata en autorisatiepolicies beschrijven. Deze specificatie zal zeer waarschijnlijk op een aantal punten overlappen met XACML. Volgens de eerste berichten zal WS-Authorization zowel ACL-gebaseerde modellen, als RBAC-gebaseerde modellen gaan ondersteunen.

Figuur 13. WS-Security raamwerk

Alle standaarden binnen de WS-Security familie maken gebruik van elkaar (figuur 13). WS-Policy en WS-Trust zijn bijvoorbeeld benodigd om vast te stellen welke tokens geaccepteerd worden en hoe en waar deze aangevraagd kunnen worden. WS-Privacy claims kunnen in een WS-Policy beschrijving worden toegevoegd en WS-Trust wordt vervolgens gebruikt om deze privacy claims weer te kunnen evalueren tegen de gebruikersvoorkeuren en de policy van de organisatie. Er zijn nog meer ontwikkelingen gaande, zoals het WS-I profiel (WS-I Basic Security Profile), dat een initiatief is van de Web Services Interoperability organisatie. Deze specificatie is echter buiten scope van dit artikel gehouden.
Samen zullen de initiële specificaties van de WS-Security familie een veelbelovend fundament gaan vormen voor veilige, interoperabele en gedistribueerde Webservices oplossingen.

Volgende week het laatste deel, waarin Vincent Alwicher Webservices gateways behandeld en zijn conclusie geeft over de beveiliging van Webservices.