Gemeente Den Haag. Technische standaardisatie van Webservices (Leveranciers-editie) v.1.0

Transcriptie

1 Technische standaardisatie van Webservices (Leveranciers-editie) v.1.0 1

2 Versie Datum Auteur Opmerkingen november 2007 Karl de Boer Concept ter bespreking standaardisatiecommissie december 2007 Frank Dane Opmerkingen van de standaardisatiecommissie verwerkt. 2

3 Inhoudsopgave 1 Inleiding Leeswijzer Achtergrond Definities Webservices Wat zijn Webservices? Registratie en publicatie van Webservices Ontwikkeling van Webservices Algemene eisen aan Webservices Inhoudelijke eisen aan de WSDL Tools Beheer Naleven van de standaarden en voorschriften Beheer van de standaard Functioneel Beheer van WebServices Beheer van de MetaData Security

4 1 Inleiding 1.1 Leeswijzer Dit document beschrijft de richtlijnen van de gemeente Den Haag m.b.t. Webservice ontwikkeling. Richtlijnen waar u als leverancier zich aan dient te conformeren. Het document is een leverancierspecifieke versie van een document dat tot stand is gekomen in een werkgroep waarin verschillende diensten van de gemeente Den Haag vertegenwoordigd zijn. Opdrachtgever is de Standaardisatiecommissie. In het algemeen geldt dat de beschreven standaarden gevolgd moeten worden. Uitzonderingen kunnen slechts worden gemaakt na raadpleging van de webservicebeheerder (een nieuwe functie bij bureau Internet & Intranet van de directie VEB van de Bestuursdienst) of een adviseur van het cluster I&M van de directie POI van de Bestuursdienst. Daarnaast is er een toetsingscommissie die de gemeentelijke architectuur en standaarden bewaakt en indien noodzakelijk een besluit neemt hoe om te gaan met het: - beslechten van eventuele meningsverschillen over de interpretatie van de architectuur en het - toestaan van uitzonderingen op de regel indien hier naar het oordeel van de toetsingscommissie steekhoudende argumenten voor zijn (bijvoorbeeld kosten/baten, risicoanalyse, concernbelang, enz) In het algemeen geldt dat in Den Haag gebruik gemaakt wordt van Webservices. Een toelichting hierop is opgenomen in de beschrijving van de ICT-architectuur 1 en de ICT Architectuur Update Hierop wordt nog kort in paragraaf 1.3 ingegaan. Naast een algemene beschrijving met betrekking tot het gebruik van Webservices zijn vier onderwerpen verder uitgewerkt: 1. Voorschriften 2. Beheeraspecten 3. Beveiliging van Webservices 4. Aanpassing / uitwerking van de ICT-architectuur. Dit rapport dient als aanvulling bij het handboek ICT-standaarden (versie 2.0 van november 2005) en wordt gebruikt in aanbestedingstrajecten. 1.2 Achtergrond De gemeente Den Haag is gestart met het ontwikkelen van diensten op basis van Webservice technologie, ten einde te komen tot een Service Gerichte Architectuur (SGA) of Service Oriented Architecture (SOA). Kijkend naar zowel het ontwikkelproces (definitie van functionaliteit, grote betrokkenheid en afhankelijkheid van externe softwarehuizen) als het organisatorische aspect (wie stuurt en bewaakt het geheel) waren verbeteringen nodig op zowel het technische niveau als het organisatorische niveau (tactisch en operationeel). Tevens kan met deze standaards worden nagegaan of de richtlijnen uit de ICT-architectuur t.a.v. Webservices voldoende worden geïmplementeerd. 1 ICT-architectuur nader beschouwd, v.1.0, september ICT-Architecuur Update 2007, v0.8 april

5 Moderne inrichting van processen en systemen, binnen en tussen individuele overheidsorganisaties, vraagt om afstemming van organisatiegrens overschrijdende (informatie) voorzieningen. Om hier aan te kunnen voldoen maakt de gemeente Den Haag ook gebruik van de Nederlandse Overheids Referentie Architectuur (NORA 2.0) en als afgeleide daarvan de Handreiking Strategie Elektronische Gemeente, versie 1.0, van de EGEM. Daarnaast komen in de documenten ICT-architectuur nader beschouwd en de ICT Architectuur Update 2007 onderwerpen voor die nog voor nader onderzoek zijn benoemd. Alle door de gemeente Den haag aangeboden webservices dienen aan de beschreven architectuur te voldoen. 1.3 Definities Het begrippenkader voor dit document: Eenvoudige webservices: webservices die slechts datatoegang bevatten of eenvoudige businesslogica. Authenticatie: het controleren / vaststellen van de identiteit van een gebruiker. Autorisatie: verlenen van een bevoegdheid aan een gebruiker. Encryptie: codering van de informatie. Signing: ondertekening t.b.v. onweerlegbaarheid en evt. authenticatie. UDDI: Universal Description, Discovery, and Integration. Een platform onafhankelijk XML gebaseerd register om Webservices te beschrijven en te lokaliseren op het internet of intranet. WSDL: Web Services Definition Language. Beschrijving van een webservice in XML formaat. XML: extensible Markup Language, een standaard voor het definiëren van formele markup-talen voor de representatie van gestructureerde gegevens in de vorm van platte tekst. Deze representatie is zowel machineleesbaar als leesbaar voor de mens. Anders geformuleerd: een standaard om gestructureerde informatiedocumenten te beschrijven. XML Schema: een standaard om de structuur, inhoud en semantiek van een XML document te beschrijven. SOAP: Simple Object Access Protocol. Een protocol voor de uitwisseling van XML gebaseerde communicatie tussen computer systemen. Meestal is HTTP de onderliggende transportlaag. WS-I: Web Service Interoperability, een organisatie opgezet om standaardisatie van Webservices te bevorderen. De aanbevelingen van deze organisatie (de zgn. Basic Profiles) zijn uitgangspunt voor de standaards in dit document. UTF8: wijze van codering van karakters in een XML Document. Alle internationale karakters worden ondersteund door deze codering. HTTP: HyperText Transfer Protocol. URL: Uniform Resource Locator. 5

6 2 Webservices Webservices vormen de meest technologieonafhankelijke koppeling van systemen die op dit moment geboden wordt. Deze onderlinge onafhankelijkheid moet er echter niet toe leiden dat services lastig gezamenlijk gebruikt kunnen worden. Functionaliteit voor de klant zal vaak gerealiseerd worden door het aanroepen van meerdere webservices, die vaak door verschillende partijen zijn gebouwd. Den Haag richt zich bij realisatie van haar SGA op een bepaalde familie van standaards, de zgn. WUS stack (voortbouwend op WSDL, UDDI en SOAP). De OverheidsServiceBus zal ook de ebxml familie ondersteunen met name voor betrouwbare berichtuitwisseling, maar bevat WUS-adepters Wat zijn webservices? Het standaardisatie instituut W3C definieert Webservices als volgt: Een Webservice is een software systeem ontworpen om interoperabele machine machine interactie over een netwerk mogelijk te maken. Het heeft een interface die beschreven is in een computer verwerkbaar formaat (het WSDL document). Andere systemen communiceren met de Web service op deze voorgeschreven wijze gebruikmakend van SOAP berichten, meestal via het HTTP protocol. Anders geformuleerd: webservices zijn functies die over een netwerk kunnen worden aangeroepen op een gestandaardiseerde manier. Onder een webservice verstaan we alle operaties die genoemd worden in de WSDL. In beginsel is het mogelijk dat een gebruiker een webservice kan aanroepen zonder veel extra documentatie of uitleg. Internationale standaarden die hiervoor gebruikt worden en door ons worden overgenomen zijn: XML-specificatie o extensible Markup Language; een standaard manier om informatie vast te leggen (zie ook 1.3 definities) SOAP v.1.1 of SOAP v.1.2 o Een Standaard mechanisme voor de ontwikkeling van een applicatie protocol op een manier die onafhankelijk is van het transport protocol. Een SOAP bericht bestaat uit een header, het document (SOAP Body) en een optioneel attachment 3 Zie 6

7 Security-richtlijnen o WS-Security en WS-I Basic Security Profile 1.0/1.1 Metadata specificaties o WSDL v.1.2 o XML-schema UDDI o Universal Description, Discovery and Integration o Definieert hoe verschillende partijen een webservice publiceren en ter ontsluiting aanbieden aan andere partijen. WS-I Basic Profile v Registratie en publicatie van webservices Omdat webservices bijdragen aan eenmalige gegevens vastlegging en meervoudig gebruik, en informatie kunnen ontsluiten vanaf de bron, is het belangrijk dat het gebruik gestimuleerd wordt. Om (her-)gebruik van webservices te stimuleren moeten ze allereerst gevonden kunnen worden en daarnaast helder beschreven zijn. Publicatie heeft als bedoeling dat iedereen die gegevens, of functionaliteit wil gebruiken deze kan opzoeken, beoordelen en als start van een implementatie kan gebruiken. Het moet de ontwikkelaar stimuleren tot voldoende documentatie van zijn werk. Ten aanzien van publicatie gelden de volgende richtlijnen: Publicatie gebeurt in principe voor alle Haagse webservices (zowel intern dienst, interngezamenlijk en extern) na overleg met de webservicebeheerder. De volgende gegevens dienen aan de webservicebeheerder ter beschikking te worden gesteld ter publicatie: o Naam o Doel o Privacygevoeligheid gegevens (Hoog/Normaal/Laag; persoonsgegevens) o Foutcodes en foutomschrijvingen o Status (Productie, acceptatie, in ontwikkeling ed.) o Versie 7

8 o Beschikbaarheid (beschikbaarheidvenster dagen per week en uren per dag) o Maximale responstijd o Verwijzing naar object of datamodel o URL productie o URL acceptatietest o URL WSDL en alle gebruikte XSD s o Lijst met operaties (functies) die de service levert. o Eigenaar o Functioneel beheerder (Volledige naam, telefoon, ) o Technisch beheerder (Volledige naam, telefoon, ) o Leverancier (ontwikkelaar) o Contactpersoon leverancier (Volledige naam, telefoon, ) o Verwijzingen naar achterliggende documentatie o Eventuele aansluitvoorwaarden 3 Ontwikkeling van webservices Om te zorgen dat de gerealiseerde webservices beoordeelbaar, herbruikbaar en onderhoudbaar zijn is een ontwikkelstandaard een eerste vereiste. 3.1 Algemene eisen aan webservices Webservices dienen de interoperabiliteit van IT systemen. Het contract tussen de aanbieder van de service en de afnemer(s) van de service staat centraal. De technische component in dit contract is het WSDL document. De implementatie van de webservice dient dan ook gebaseerd te zijn op een WSDL. De WSDL dient te worden goedgekeurd door de webservicebeheerder. Wellicht ten overvloede: voorafgaand aan het service ontwerp dient een goed semantisch model aanwezig te zijn 4, bijv. een gegevensmodel. Uiterlijk op het moment dat de services in de acceptatie omgeving worden geïnstalleerd of eerder indien de geboden service interface zich gestabiliseerd heeft. Hierbij worden alle standaards nagelopen bijvoorbeeld in hoeverre er intensief gebruik is gemaakt van alle WSDL / schema constraints. Dit proces kan voor een groot deel geautomatiseerd worden m.b.v. SoapScope (zie paragraaf Tools). De webservices moeten minimaal voldoen aan de eisen gesteld door de webservice Interoperability organisatie: WS-I Basic Profile 1.1 (Het WS-I Basic Profile beschrijft wat wel en niet mag met SOAP en WSDL. Zie Voor het programmeren van webservices bestaan twee stijlen, te weten Document /Literal en RPC / Literal. De gemeente Den Haag wil het document centraal stellen en kiest daarom voor Document / Literal ( Het gebruik van RPC / Literal is ook toegestaan, mits beargumenteerd wordt waarom niet kan worden volstaan met Document / Literal. De XML berichten dienen gecodeerd te worden in het UTF8 formaat. 4 Zie uitgave ICTU-Kenniscentrum Service Gerichte Architectuur, versie 1.0, d.d. september

9 Alle operaties maken gebruik van een standaard foutbericht. Deze wordt run-time opgenomen in de detail sectie van de SOAP Fault. De naamgeving van de elementen is gebaseerd op de OverheidsServiceBus (OSB.xsd) <xsd:complextype name="fout"> <xsd:sequence> <xsd:element name="foutmelding" type="xsd:string" nillable="true"/> <xsd:element name="foutmeldingcode" type="xsd:string" nillable="true"/> </xsd:sequence> </xsd:complextype> De documentatie van de service moet een opsomming bevatten van de foutcodes en omschrijvingen die geretourneerd kunnen worden door de service Zoekfuncties die geen resultaat opleveren, retourneren een normaal soap bericht zonder rij elementen maar wel met het omsluitende element: Voorbeeld zonder result set: <adressen> </adressen> Voorbeeld met result set: <adressen> <adres>adres 1</adres> <adres>adres 2</adres> </adressen> Vanzelfsprekend moeten zoekfuncties die geen resultaten teruggeven die volgens bestaande bedrijfsregels wel aanwezig dienen te zijn een foutbericht met foutcode retourneren. 3.2 Inhoudelijke eisen aan de WSDL De WSDL beschrijft een webservice. Bij bestaande webservices levert dat de specificaties die de gebruiker nodig heeft om zijn applicatie aan te sluiten. Bij nieuwe, te ontwikkelen webservices is de WSDL het contract tussen aanbieder en gebruiker. Er wordt gestreefd geen nieuwe element definities te creëren voor een WSDL die ook reeds bestaan in andere schema s binnen de gemeente Den Haag of daar buiten in het GFO/StUF domein (Gemeentelijk Functioneel Ontwerp/Standaard Uitwisselings Formaat). Voor zover deze niet in al bestaande XSD s zijn opgenomen dienen de in een WSDL genoemde elementdefinities te worden vastgelegd in een apart XML schema bestand. In de WSDL zijn dus geen elementdefinities te vinden. Alle mogelijkheden van XML Schema om gegevens te beschrijven en valideren dienen benut te worden. Zo dienen bijvoorbeeld de volgende schema opties te worden gebruikt (indien van toepassing): minoccurs maxoccurs 9

10 nillable minlength (bij Strings) maxlength (bij Strings) patterns (bijv. bij postcode en sofinummer) totaldigits (bij decimals) fractionaldigits (bij decimal) Enumerations dienen te worden geïmplementeerd als choice Annotations voor functioneel commentaar Voorbeeld van elementdefinities: <xs:simpletype name="postcodetype"> <xs:restriction base="xs:string"> <xs:pattern value="\d{4}\s[a-z]{2}"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="huislettertype"> <xs:annotation> <xs:documentation>eigen definitie, gebaseerd op Logisch Ontwerp GBA II; GFO BRVG. Leeg, of A- H, J-Z </xs:documentation> </xs:annotation> <xs:restriction base="xs:string"> <xs:maxlength value="1"/> <xs:pattern value="[a-z]"/> </xs:restriction> </xs:simpletype> Naamgeving algemeen. De taal is Nederlands en elk zelfstandig naamwoord begint met een hoofdletter (zogenaamde Pascal casing) Type definities wordt gevolgd door het woord Type bv. OpenbareRuimteType Naamgeving operaties. Voor de leesbaarheid en uniformiteit van de services in de datalaag zijn de volgende naamgevingconventies gedefinieerd. Situatie Zoek operaties die een lijst van 0,1 of meer objecten retourneren zijn als volgt geformatteerd Ophaal / Retrieval functies die 1 object retourneren Object creëren Object wijzigen Naamgeving zoek{objectnamen}{via}{zoekingang} Voorbeelden: zoekopenbareruimteviapostcode Indien er bij het zoeken gebruik gemaakt wordt van generieke filter berichten kan worden volstaan met zoek{objectnamen} haal{objectnaam}op(via{zoekingang}) Voorbeelden: haalopenbareruimteop haalopenbareruimteopviaid maak{objectnaam}aan wijzig{objectnaam}{via}{uniekesleutel} 10

11 Voorbeelden: wijzigopenbareruimteviaid wijzigopenbareruimteviacode Object verwijderen Identificerende gegevens kunnen ook deel uitmaken van een (complex) berichttype. In dat geval volstaat wijzig{objectnaam} verwijder{objectnaam}{via}{uniekesleutel} Voorbeelden: verwijderopenbareruimteviaid verwijderopenbareruimteviacode Identificerende gegevens kunnen ook deel uitmaken van een (complex) berichttype. In dat geval volstaat verwijder{objectnaam} Aan services die ingekocht worden (met een standaard pakket worden meegeleverd) kunnen deze eisen niet worden opgelegd. Proces gerelateerde services kennen (nog) geen naamgevingconventies. De URL waar de webservice beschikbaar wordt geteld heeft de volgende lay-out: http(s)://{domein}.denhaag.nl/{applicatie}/{versie}.{subversie}/{serviceen dpoint}ws domein=functiegebied applicatie=toepassing (bijv. een verzameling services) versie=numerieke hoofdversie aanduiding (bijv. 1) subversie=numerieke aanduiding voor een verdere versie aanduiding ServiceEndpoint=Naam van de webservice (verzameling operaties) Bijvoorbeeld: Een nieuw versie/subversienummer wordt alleen toegewezen wanneer de interface wijzigt. Dit komt overeen met standaard ICT gebruik van versienummers waarbij bug fixes en niet functionele zaken op sub-subnummer niveau wordt bijgehouden Leverancierspecifieke namespaces zijn niet toegestaan indien de services worden ontwikkeld onder verantwoording van de gemeente Den Haag 3.3 Tools Er zijn diverse tools om XSD s en WSDL te definiëren en valideren. Het definiëren van webservices gebeurt in de regel met de ontwikkelomgeving (bijv. Visual Studio en Eclipse) of met speciale WSDL editors. De gemeente Den Haag schrijft niet voor welke tools in dit kader 11

12 gebruikt moeten worden. Binnen de gemeente Den Haag is SoapScope van MindReef de meest gebruikte tool om de WSDL te valideren en de implementatie te testen. 12

13 4 Beheer Onder beheer wordt verstaan het toezien op de naleving van de afgesproken standaarden en voorschriften, het functioneel beheer en het beheer van de webservices standaarden zelf. Op enig moment in het ontwikkelproces van een toepassing met Webservices moet ontwerp en voorgestelde implementatie van de WS worden getoetst. 4.1 Naleven van de standaarden en voorschriften De webservicebeheerder zal op een bepaald moment in het ontwikkelproces van nieuwe webservices in beeld komen. Leveranciers/ontwikkelaars wordt gevraagd om al in een vroegtijdig stadium met de webservicebeheerder in contact te treden teneinde de goede keuzes te maken. Er wordt getoetst of de voorgestelde oplossing voldoet aan de gemeentelijke en de landelijke voorschriften. Hiervoor is in het document Aansluitvoorwaarden E-infrastructuur en ICT-architectuur een werkwijze voorgesteld voor applicatieontwikkeling. Rondom beheer en ontwikkeling van webservices is een groot aantal mensen betrokken. Het WSontwikkelproces is hieraan goed te relateren. Globaal ziet de afgesproken gestandaardiseerde - aanpak er dan als volgt uit: 13

14 Projectvoorstel nieuw systeem Major update bestaand systeem Legenda webservice beheerder Controleren noodzaak WS Project webservice noodzakelijk Registratie webservice (status ontwikkeling) Ontwerp en bouw Optionele controle ontwerp WSDL Deze stap wordt ten strengste aanbevolen. Advies: het WSDL first principe Oplevering acceptatie Controleren WSDL Voldoet niet aan standaarden Overzicht noodzakelijke aanpassingen Voldoet wel aan standaarden Registratie WSDL (status geaccepteerd) Oplevering productie Registratie WSDL (status in productie) 14

15 Hierbij zal de webservicebeheerder (dwingend) adviseren en op verschillende momenten in het proces toetsen op de volgende punten: Controleren noodzaak van (nieuwe) webservice Het naleven van de technische voorschriften Bewaken van samenhang en niet dubbel uitvoeren van functionaliteit Vaststellen of het goede beveiligingsniveau voor een service is gekozen De WSDL wordt aan de webservicebeheerder ter goedkeuring aangeboden. Bij voorkeur gebeurt dit voordat er gebouwd gaat worden, maar in ieder geval voordat de acceptatietest plaatsvindt. Hierbij worden alle standaards nagelopen, bijvoorbeeld in hoeverre er intensief gebruik is gemaakt van alle WSDL / schema constraints. 4.2 Beheer van de standaard Een andere beheertaak is het beheer van de standaard. Het gaat hierbij om de opgestelde voorschriften met betrekking tot webservices en de relatie van deze voorschriften met de ICTarchitectuur. Dit is een taak van de standaardisatiecommissie. De standaardisatiecommissie zal jaarlijks in overleg met de webservicebeheerder en de beheerder van het ICTarchitectuurdocument nagaan in hoeverre de vastgestelde standaard aanpassing of uitbreiding behoeft. 4.3 Functioneel beheer van webservices Het functioneel beheer van webservices vindt op concernniveau plaats en wordt uitgevoerd door de webservicebeheerder. Het functioneel beheer betreft configuratie-, specificatie-, wijzigings-, probleem- en beveiligingsbeheer. Dit betekent dat aanvragen altijd in overleg met de webservicebeheerder zullen verlopen. 4.4 Beheer van de MetaData Het beheer van de metagegevens van de service zoals vermeld in paragraaf 2.2 vindt plaats op concern niveau tenzij er een dienst specifieke verantwoordelijkheid is die dit verhindert. 15

16 5 Security De beveiliging moet recht doen aan allerlei situationele aspecten: Eisen gesteld aan gegevensdiensten (CRUD operaties) die de datalaag benaderen kunnen een andere invulling krijgen dan diensten op de businesslaag. Afhankelijk van het aantal logische applicatielagen kan op de diepere lagen worden volstaan met systeemautorisatie en op de lagen die dichter bij een eindgebruiker staan moet vastgehouden worden aan gebruikersautorisatie De aard van de gegevens die aangeboden worden aan of geretourneerd worden door de webservice kunnen een specifiek beveiligingsniveau vereisen. Vertrouwelijke gegevens bijvoorbeeld kunnen worden versleuteld terwijl dit voor publieke gegevens niet nodig is. Dit document beschrijft in een bijlage de security maatregelen die nodig zijn om webservices beter te beveiligen. Indien wordt besloten tot het inzetten van een XML Firewall moet deze ook voldoen aan de gestelde eisen. Een XML Firewall kan beveiligingstaken overnemen van de applicatie(server). Maar de gewenste security maatregelen gelden ongeacht de aanwezigheid van een XML firewall. Voor de webservice beveiliging is gekozen uit onderdelen van de WS-I Basic Security Profile 1.0 ( De beveiliging vindt voornamelijk plaats op SOAP bericht niveau en niet op de transportlaag om onafhankelijk te blijven van de transportlaag. Aangezien webservices gebruikt worden als leverancieronafhankelijk integratie en communicatiemiddel dient een beveiligingsoplossing gebaseerd te zijn op open standaarden. De security standaard voor webservices is de WS-Security standaard van OASIS ( Aangezien vele standaarden hierin zijn ondergebracht en het ondoenlijk en onpraktisch is deze allemaal te implementeren is er een subset geselecteerd die de marktpartijen volledig of deels ondersteunen. Dit is het WS-I Basic Security Profile 1.0 van de WS-I organisatie (wsi.org). Beveiliging kent vele aspecten. Voor diverse van deze aspecten biedt WS-Security een oplossing: Beveiligingsaspect Authenticatie Vertrouwelijkheid Onweerlegbaarheid Gegevensintegriteit WS-Security standaard UserName Token Profile, X509 Token Profile, SAML, XML Digital Signature XML Encryption, SSL/TLS XML Digital Signature XML Digital Signature 16

17 Autorisatie is geen onderdeel van WS-Security dus moet dit opgelost worden door de applicatie, XML Firewall of applicatieserver. Bij voorkeur niet via code in de applicatie! Onweerlegbaarheid en vertrouwelijkheid zijn niet altijd nodig. Indien de webservice deze additionele beveiliging moet bieden, moet gebruik worden gemaakt van XML Digital Signatures en /of XML encryptie. Er is sprake van een zekere overhead bij het gebruik van XML Digital Signature en XML Encryption. XML firewalls zijn in dit verband nuttig om de performance hoog te houden. Bij authenticatie bestaan er diverse opties. De keuze is beïnvloed door de volgende factoren: Het ontbreken van een Public Key Infrastructure (PKI). Dit maakt grootschalige authenticatie op basis van een XML Digital Signature of X509 Token Profile moeilijk. SAML Tokens vervullen momenteel alleen een rol bij de ichain authenticatie. De SAML tokens zijn niet beschikbaar bij de webservice aanroepen in het interne netwerk. Gekozen is voor het doorgeven van authenticatie-gegevens via de SOAP envelop en niet via het transport protocol. SOAP is protocol onafhankelijk en biedt ook bindings mogelijkheden naar andere protocollen dan HTTP. Authenticatie op transport niveau beperkt deze onafhankelijkheid weer. Alle diensten moeten worden beveiligd volgens het username token profile 1.0. Deze security standaard is onderdeel van WS-Security en maakt tevens deel uit van het WS-I Basic Security Profile, een geadviseerde subset van WS-Security. De usernames kunnen zowel systeem accounts representeren als eindgebruikers, afhankelijk van de toepassing. Indien de gebruiker reeds in een eerdere logische applicatielaag is geauthenticeerd en voor de werking of auditing van de service is het niet interessant om te weten wie de eindgebruiker is kan worden volstaan met een systeemaccount. Het wachtwoord mag niet worden doorgegeven in plain text. Het wachtwoord moet of worden doorgegeven in digested form (passworddigesttype) of versleuteld worden op de transportlaag (TLS/SSLV3) De documentatie is hier beschikbaar: wss-username-token-profile-1.0.pdf. Zowel.Net, JBoss als Oracle Application Server ondersteunen deze security token. Hierboven is gesteld dat de keuze voor het username token profile als authenticatie middel beïnvloed is door de afwezigheid van andere opties. Mocht deze situatie wijzigen is nieuwe besluitvorming noodzakelijk. Een voorbeeld SOAP bericht met de username token in de SOAP Header is hieronder afgedrukt: <SOAP:Envelope xmlns:s11="..." xmlns:wsse="..." xmlns:wsu= "..."> < SOAP:Header>... <wsse:security> <wsse:usernametoken> <wsse:username>nnk</wsse:username> <wsse:password Type="...#PasswordDigest"> weyi3nxd8ljmnvksckfv8t3rghh3rw== </wsse:password> <wsse:nonce>wscqanjceac4mqobe07saq==</wsse:nonce> 17

18 <wsu:created> t01:24:32z</wsu:created> </wsse:usernametoken> </wsse:security>... </ SOAP:Header> <SOAP:Body>... Hier bevindt zich de applicatie data... </SOAP:Body> </ SOAP:Envelope> De autorisatiestap kan worden verzorgd door de XML Firewall of door de applicatie server die de webservice host via een pluggable authenticatie module. Indien het applicatieplatform deze functionaliteit niet biedt moet de service implementatie zelf de autorisatie verzorgen via het Identity Management Systeem. Speciale aandacht wordt gegeven aan applicaties of webservices uit andere domeinen die webservices aanspreken in het intern gezamenlijk domein. Behalve username token profile authenticatie op service niveau authenticeren de servers elkaar ook wederzijds via digitale certificaten als onderdeel van het SSL protocol. Er wordt met andere woorden een beveiligde tunnel tussen de twee servers gecreëerd met behulp van wederzijds certificaat uitwisseling. Bij voorkeur wordt de Secure Sockets Layer (SSL) afhandeling verzorgd door de XML Firewall. In dat geval loopt de SSL tunnel slechts tot de XML Firewall en moet er zorg voor worden gedragen dat de service niet direct benaderd kan worden (dus buiten de XML Firewall om). Gezien de organisatorische kosten die een PKI oplossing met zich mee brengt is het verstandig om de certificaten van buiten te betrekken. PKI Overheid certificaten zijn de meest voor de handliggende en zijn absoluut nodig voor de externe communicatie. Om de beveiligingsmaatregelen per service te kunnen benoemen is het nodig deze te classificeren. Er kunnen de volgende soorten services op basis van positie in het applicatielagen model onderscheiden worden: Proces Samengesteld Eenvoudig Een webservice die een bedrijfsproces representeert en daartoe andere services orkestreert en op haar beurt ook een webservice interface aanbiedt. Voorbeeld een BPEL proces of een ESB Serviceketen Een webservice die andere services synchroon aanroept. De aanroep is hard coded. Een webservice voor datatoegang of eenvoudige businesslogica (bijv. een rule of rekenmodule). Eenvoudige (basic) webservices die de gegevenslaag benaderen bevinden zich uitsluitend op de applicatie laag van het interne domein Al deze diensten bevinden zich in de fysieke applicatielaag, waarschijnlijk draaiend in een applicatieserver container. 18

19 Onderstaande matrix geeft aan welke soorten diensten geïmplementeerd mogen worden per netwerk domein: Domein Toegestane webservice Soort Opmerking Intern gezamenlijk Proces Samengesteld Eenvoudig Berichten Alle verwerkingslogica wordt gerealiseerd in het intern domein beschermd door een XML Firewall Internet geauthenticeerd Proces Echter bij voorkeur gerealiseerd in intern gezamenlijk domein Internet anoniem Proces Bij voorkeur gerealiseerd in intern gezamenlijk domein Onderstaande matrix geeft aan welke beveiligings maatregelen nodig zijn voor services in het intern gezamenlijk domein indien deze aangeroepen wordt vanuit een ander of zelfde netwerk domein. Het intern gezamenlijk domein is het geadviseerde domein om webservices te realiseren. Aanroepend Domein SSL/ TLS op transport laag Authenticatie op basis van Username Token Profile Privacy gevoelig Intern gezamenlijk Nee(3) Ja XML Encryption Berichtenverkeer Nee (1,3) Ja (2) XML Encryption Internet Ja Ja XML geauthenticeerd Encryption Internet anoniem Ja Ja XML Encryption Onweerlegbaarheid nodig? XML Signature XML Signature XML Signature XML Signature 1). Mits XML Signature en XML Encryption is toegepast. 2). Indien authenticatie heeft plaatsgevonden op de XML Firewall kan dit achterwege blijven of voegt de XML Firewall zelf een systeemuser toe als username token in de SOAP header. 3). Indien de wachtwoorden in plain text worden doorgegeven is er wel een SSL / TLS verbinding vereist. Proces services die zich bevinden in andere domeinen moeten in ieder geval het UserName Token Profile 1.0 adopteren en daarnaast zorg dragen voor autorisatie tegen een Identity Management Systeem (CDS). De applicatielaag in de domeinen internet geauthenticeerd en internet anoniem mogen niet rechtstreeks communiceren met de gegevenslaag in het intern gezamenlijk domein. In het 19

20 document Update ICT architectuur 2007 wordt aanbevolen alle gezamenlijke gegevens uiteindelijk naar dit domein te verhuizen teneinde redundante opslag van gegevens te vermijden. Dit impliceert dat de applicatielaag van internet gezamenlijk en internet anoniem alleen met de gegevenslaag intern gezamenlijk kan communiceren via webservices die zich bevinden in de applicatielaag van het intern gezamenlijk domein. 20