IAM Application Integration Guide

Transcriptie

1 IAM Application Integration Guide Date 7/05/2012 Version 2.0

2 INHOUDSTAFEL 1 Business Oogpunt Doelstellingen van het Federaal IAM De rol van het Fedict IAM programma bij het leveren van authenticatie en attribuutpublicatie diensten Informatie oogpunt Functionele flow van koppeling Informatie categorieën Uitgewisselde attributen Lessons learned: valkuilen Toepassing: informatie in een koppeling zonder rollen informatie Architectuur oogpunt Overzicht componenten in functie van Referentie Architectuur Toepassing: Fedlet FAS integratie uit architectuur oogpunt Technisch oogpunt Ondersteuning van integratiescenario s Migratie van standaard FAS1 implementaties naar FAS+ via Fedlet Overzicht van configuratie en integratie van de OpenAM Fedlet Toepassing: voorbeeldcode en berichten Annex: Nuttige links Specificaties Fedlet integratie Hulpmiddelen FAS+ Integration Kit

3 1 BUSINESS OOGPUNT 1.1 Doelstellingen van het Federaal IAM Binnen het hedendaagse egovernment landschap leveren verschillende partijen diensten en applicaties in een geïnformatiseerde overheid. Zoals afgebeeld hieronder in Figuur 1 zijn zij elk binnen hun domein verantwoordelijk voor gelijkaardige taken op het niveau van identiteits- en authenticatiediensten, toegangscontrole, aangeboden egov applicaties, attribuut- en privilege publicatie diensten en Identity Management. Het Fedict IAM-systeem komt tegemoet aan vijf strategische doelstellingen in dit kader van egovernment: De gebruikers een transparante toegang bieden tot de toepassingen en informatiebronnen van de (federale) Belgische overheid, rekening houdend met het uiterst heterogene en gedistribueerd karakter ervan. Risico s op ongeoorloofde toegang tot de toepassingen controleren en verminderen en de integriteit waarborgen. De efficiëntie en operationele doeltreffendheid van het dagelijkse beheer van de identiteiten en rollen verhogen. Het opzetten van een technische architectuur die een optimale werking en interoperabiliteit garandeert voor het globale systeem, rekening houdend met de autonomie van de betrokken partijen zowel op technisch als op operationeel niveau. Het opzetten van een governance structuur die een optimale werking en interoperabiliteit garandeert voor het globale systeem, rekening houdend met de autonomie van de betrokken partijen zowel op technisch als op operationeel niveau. Figuur 1: egovernment landschap 3

4 Bij het ontsluiten / uitwisselen van informatie zijn overheden verplicht om hun informatie te ontsluiten via een degelijke (gedistribueerde) toegangsbeheersomgeving. Deze omgeving bestaat uit: Ondersteunende identity / authenticatie diensten (bv eid-kaart, bv REAL-kaart, bv Stork, ) zodat de access control omgeving de gebruiker uniek kan identificeren. Bijbehorende access control (decision/administration) diensten aka policy decision/administration points, dewelke op basis van rules de beslissing nemen of een toegang / uitwisseling mag plaats vinden. Effectieve access control (enforcement) diensten, aka policy enforcement points, voor het bewaken van toegang tot / uitwisseling van gegevens. Voornoemde access control omgeving dient beroep te kunnen doen op attribute / rol / mandaat bronnen (aka Policy Information Points) om te kunnen evalueren of de gebruiker voldoet aan de voor de toegang / uitwisseling geldende toegangsregels. Hiertoe is een degelijke (gedistribueerde) gebruikersbeheersomgeving noodzakelijk. Deze bestaat uit: Authentieke bronnen (authentic sources) waarin zich de betreffende identity en attribute / rol / mandaat gegevens bevinden Publicatie/verificatie diensten ten behoeve van het kunnen opvragen van identity en attribute / rol / mandaat informatie Beheers/registratiediensten ten behoeve van het kunnen beheren van de identity en attribute / rollen / mandaten (incl beheer van meta-informatie, rollen-cataloog, ) 1.2 De rol van het Fedict IAM programma bij het leveren van authenticatie en attribuutpublicatie diensten De rol van het Fedict IAM binnen het egov kader, situeert zich in twee domeinen. Een eerste domein is het strategisch vlak. Dit is het maken van de juiste afspraken op niveau van diensten en interfaces alsook op het niveau van de gebruikte informatiemodellen (identiteiten, rollen, mandaten, ). Het tweede domein is het tactisch/operationeel vlak. Dit is het toepassen van deze afspraken/normen/standaarden op de componenten die Fedict aanlevert voor het bieden van authenticatie en attribuut publicatie diensten. Fedict levert de uitwerking en ondersteuning van een gemeenschappelijke strategie op het gebied van federaal IAM door middel van: Governance op strategisch vlak: IAM Framework (cfr noden, omkadering, prioritisering). Governance op tactisch vlak: IAM Enterprise Architectuur, Information-model, Governance op operationeel vlak: IAM service (level) management, security, Het Fedict IAM programma levert als Trusted Third Party advies inzake IAM op strategisch, tactisch en operationeel vlak aan andere overheidsdiensten of organisaties met een publieke functie die op het Fedict IAM een beroep doen: Het uitwerken van de nodige concrete normen, standaarden en basisarchitecturen ten behoeve van het realiseren van degelijke IAM-diensten alsook het waken over de naleving dmv het 4

5 valideren van federale componenten tov het federaal IAM-framework / IAM enterprise architectuur. Het begeleiden van de federale overheidsdiensten bij de implementatie van hun respectievelijke componenten / services binnen hogervermeld kader (dmv architecturale bijstand of dmv het bieden van herbruikbare componenten en IAM-gerelateerde diensten). Het uitwerken van projecten en diensten in de vorm van ondersteunende, herbruikbare componenten en IAM-gerelateerde diensten die ter beschikking gesteld worden van geinteresseerde federale overheidsdiensten. Dit document situeert zich vooral in het begeleiden van federale overheidsdiensten in de implementatie van de koppeling van hun systemen met het Fedict IAM, waarbij de overheidsdiensten als Relying Parties een beroep doen op het Fedict IAM als Trusted Third Party en zo een Circle of Trust vormen. Een van de belangrijkste manieren om te koppelen met het Fedict IAM systeem, is de Federale Authenticatie Service (FAS). Relying Parties kunnen hiervan gebruik maken om eindgebruikers te identificeren en authentiseren. Bovendien geeft het systeem ook relevante attributen en rollen mee om de Relying Party in staat te stellen een gepaste autorisatie beslissing te maken. 5

6 Service Provider (Applicatie) IAM Application Integration Guide v2.0 2 INFORMATIE OOGPUNT De partijen binnen de Circle of Trust moeten aan informatie-uitwisseling doen om aan Identity Federation te doen. Dit hoofdstuk biedt een overzicht van de verschillende soorten informatie en hoe het Fedict IAM ze behandelt. De eerste sectie van dit hoofdstuk geeft een functioneel overzicht van de SAML 2.0 HTTP Post binding en illustreert hoe de communicatie verloopt tussen de gebruiker en de hoofdcomponenten, de applicatie en de FAS. Deze sectie dient als praktisch voorbeeld om de volgende sectie te ondersteunen. De tweede sectie biedt een overzicht van de verschillende informatiecategorieën en waar deze van belang zijn in de koppeling met het Fedict IAM. De laatste sectie geeft een overzicht van de attributen die uitgewisseld worden tussen het Fedict IAM en de Relying Party en typische valkuilen in deze attributen. 2.1 Functionele flow van koppeling Relying Party Figuur 2 geeft een functioneel overzicht van een SAML 2.0 HTTP Post binding tussen een Service Provider en een Identity Provider (FAS): 1) De Gebruiker vraagt een applicatie op. 2) De Fedlet in de applicatie verwijst de gebruiker door naar het login scherm van FAS bij Fedict. 3) De Gebruiker authentiseert zich op een scherm van Fedict. 4) FAS verwijst de gebruiker terug door naar de applicatie FAS+ Fedlet Circle of Trust met: Het resultaat van de aanmelding. Attributen voor consumptie door de applicatie indien succesvolle aanmelding. Figuur 2: Functionele flow binnen Circle of Trust 2.2 Informatie categorieën De klant van Fedict heeft als Relying Party vertrouwen in de informatie die het Fedict IAM verstrekt over identiteiten en hun sessies. De uitgewisselde informatie valt uiteen in 4 categorieën: 1. Persoonlijke informatie laat toe de werkelijke identiteit van de gebruiker vast te stellen, de gebruiker uniek te identificeren. Voorbeelden van persoonlijke informatie zijn voornaam en naam, Rijksregister nummer en persoonlijke contactgegevens, etc. 2. Contact informatie bevat contact- en adresgegevens met betrekking tot de professionele context van de gebruiker. 3. Externe identificatie informatie bevat een combinatie van persoonlijke en contactinformatie die wordt opgehaald uit een externe bron zoals KBO, KSZ, Rijksregister, etc. 6

7 4. Privilege informatie beschrijft de rollen met hun parameters die toegekend zijn aan een Identiteit. 5. Metadata informatie beschrijft eigenschappen van de sessie, van de SAML berichten zelf, etc. Deze categorieën komen in verschillende punten in de functionele flow terug: Metadata informatie wordt uitgewisseld in zowel request als response. Contact informatie, externe identificatie informatie en privilege informatie kunnen enkel teruggegeven worden door Fedict aan de Relying Party. Persoonlijke informatie kan gebruikt worden in het kader van attribute query s en dient dus ook zowel voor requests als responses. In bepaalde gevallen is registratie noodzakelijk of moet het Fedict IAM een externe bron raadplegen om informatie in de response terug te kunnen geven: Persoonlijke informatie staat gedeeltelijk op de eid kaart en kan zonder registratie uitgeleverd worden (RRN, Naam, Voornaam). Persoonlijk adres staat niet op de eid kaart en is enkel voorhanden na registratie binnen het Fedict IAM. Contact informatie vereist in alle gevallen een registratie in het Fedict IAM: de gebruiker moet bestaan binnen een organisatie om te beschikken over bvb een professioneel adres. Externe identificatie informatie vereist per definitie een opzoeking door het Fedict IAM. Hiervoor is echter niet noodzakelijk een registratie nodig. Privilege informatie kan uitgeleverd worden op basis van expliciete roltoekenningen via het Rollenbeheer in het Fedict IAM of op basis van raadpleging van externe bronnen, bvb een wettelijk vertegenwoordiger in het KBO kan impliciet een bepaalde rol toegekend krijgen voor een KBO nummer, terwijl de identiteit daarvoor niet hoeft geregistreerd te zijn in het Fedict IAM. 2.3 Uitgewisselde attributen Deze sectie beschrijft de verschillende attributen die via het Fedict IAM uitgewisseld kunnen worden. De kolom Attribuut geeft de naam van het attribuut en de xpath expression van het attribuut in de XML structuur van de SAML 2.0 berichten. De kolom omschrijving geeft meer informatie over het attribuut en mogelijk gebruik. Attributen kunnen niet anders ingevuld worden dan hier omschreven. Het is bijvoorbeeld onmogelijk om een organisatiecode in een ander veld uit te leveren. Zie sectie 2.5 hieronder voor een voorbeeld van een SAML 2.0 response waarin sommige van deze attributen terugkomen. 7

8 2.3.1 Persoonlijke informatie Vervat in stap 4) in sectie 2.1 hierboven. Attribuut Identiteitscode (/Response/Assertion/Subject/NameID) Omschrijving NameID code die bij de authenticatie wordt doorgegeven. Bij een koppeling met persistent NameID is dit een gesynchroniseerde waarde tussen de omgeving van de Relying Party en van Fedict. Deze gesynchroniseerde waarde is niet de UserID binnen het Fedict IAM (attribuut egovuserid) of de applicatie van de Relying Party, maar een identifier die uitgewisseld wordt tussen Fedict en de Relying Party en die de Identiteit aan beide zijden kan identificeren. Gebruikersnaam (/Response/Assertion/AttributeStatement/Attrib egovuserid /AttributeValue) Rijksregisternummer (/Response/Assertion/AttributeStatement/Attrib egovnrn /AttributeValue) Voornamen (/Response/Assertion/AttributeStatement/Attrib givenname /AttributeValue) Familienaam (/Response/Assertion/AttributeStatement/Attrib surname /AttributeValue) Persoonlijk adres (/Response/Assertion/AttributeStatement/Attrib Personal /AttributeValue) Bij een koppeling met een transient NameID is dit een veranderende waarde. De gebruikersnaam waarmee de gebruiker geregistreerd is in het Fedict IAM. Dit is niet de NameID in het geval van een Persistent Identity koppeling, maar de specifieke UserID waarmee een persoon kan inloggen met Username/Password in het Fedict IAM. Het Rijksregisternummer in het Fedict IAM. Op het moment van registratie wordt dit gecontroleerd aan de hand van de authentieke bron. Dit attribuut kan rechtstreeks van de eid kaart uitgeleverd worden bij eid logon. De voornamen van de identiteit. Dit attribuut kan rechtstreeks van de eid kaart uitgeleverd worden bij eid logon. De familienaam van de identiteit. Dit attribuut kan rechtstreeks van de eid kaart uitgeleverd worden bij eid logon. Het persoonlijk adres dat in het Fedict IAM is geregistreerd voor de identiteit (!= professioneel adres). 8

9 Voorkeurtaal De taal waarin de gebruiker wil werken. (/Response/Assertion/AttributeStatement/Attrib PrefLanguage /AttributeValue) Contact informatie Vervat in stap 4) in sectie 2.1 hierboven. Er is altijd een registreerde identiteit nodig om contactinformatie uit te leveren, zie sectie 2.2 hierboven. Attribuut Agentschap (/Response/Assertion/AttributeStatement/Attrib egovagency /AttributeValue) Departement (/Response/Assertion/AttributeStatement/Attrib egovdepartment /AttributeValue) Professioneel adres (/Response/Assertion/AttributeStatement/Attrib egovprof /AttributeValue) Professioneel telefoonnummer (/Response/Assertion/AttributeStatement/Attrib egovphone /AttributeValue) Statuut (/Response/Assertion/AttributeStatement/Attrib egovcsstatute /AttributeValue) Titel (/Response/Assertion/AttributeStatement/Attrib egovworktitle /AttributeValue) Omschrijving Het agentschap waarin een ambtenaar werkt. Enkel van toepassing op ambtenaren. Het departement binnen het agentschap waarin een ambtenaar werkt. Enkel van toepassing op ambtenaren. Het professioneel adres van de identiteit in zijn hoedanigheid binnen een agentschap en departement. Het professioneel telefoon nummer van de identiteit in zijn hoedanigheid binnen een agentschap en departement. Het ambtenarenstatuut van de identiteit, TRUE of FALSE met TRUE=Identiteit is als ambtenaar bekend in het Fedict IAM. De professionele titel in de hoedanigheid binnen het agentschap en departement van de identiteit Externe identificatie informatie Vervat in stap 4) in sectie 2.1 hierboven. Er is altijd een opzoeking in een authentieke bron nodig om externe identificatie informatie uit te leveren, zie sectie 2.2 hierboven. Attribuut Burgerlijke staat (/Response/Assertion/AttributeStatement/Attrib nrnmartialstatus /AttributeValue) Omschrijving De burgerlijke staat van de identiteit. Dit attribuut wordt uitgelezen uit het Rijksregister. 9

10 Geslacht (/Response/Assertion/AttributeStatement/Attrib nrngender /AttributeValue) Het geslacht van de identiteit. Dit attribuut wordt uitgelezen uit het Rijksregister Privilege informatie Vervat in stap 4) in sectie 2.1 hierboven. Er is altijd een registreerde identiteit met expliciete roltoekenning of een opzoeking in een authentieke bronnen met impliciete roltoekenningen nodig om privilege informatie uit te leveren, zie sectie 2.2 hierboven. Attribuut Toegekende Rol (/Response/Assertion/AttributeStatement/ Attribute/Name=<appCode>/AttributeValue) RoleParameter (/Response/Assertion/AttributeStatement/ Omschrijving De naam van de toegekende rol, bestaat uit een code voor de applicatie en de rol. De naam van het attribuut kan per applicatie wisselen, in de voorbeelden in deze gids heet het attribuut roles. Een of meerdere parameters die aan de roltoekenning zijn verbonden. Dit kan bvb het rolbereik bevatten: het gedeelte van de organisatie waarvoor de roltoekenning van toepassing is Metadata informatie Metadata informatie in authentication request Vervat in stap 2) in sectie 2.1 hierboven. Attribuut Gevraagde Authenticatie methode (/AuthnRequest/RequestedAuthnContext/ AuthContextClassRef) Omschrijving Verwijzing naar het gevraagde authenticatiemiddel. Dit laat applicaties toe van functionaliteit te bieden afhankelijk van het gebruikte authenticatiemiddel, bvb leesrechten bij gebruik van een Burgertoken en schrijfrechten enkel bij eid authenticatie. Authenticatie vergelijking Mogelijk zijn specifieke AuthContextClasses nodig voor de applicatie, zie sectie 2.4 Lessons learned: valkuilen hieronder. Toegelaten waarden: exact of minimum. (/AuthnRequest/RequestedAuthnContext/ 10

11 @Comparison) Exact het gevraagde of minimum het gevraagde authenticatiemiddel. Er is door Fedict een ordening in authenticatiemidellen vastgelegd, bvb eid is sterker dan Burgertoken en Burgertoken is sterker dan username/password. Hernieuwing authenticatie vereist? Indien bvb minimum Burgertoken wordt gevraagd door de applicatie zal een eid ook tot een geslaagde authenticatie leiden, in tegenstelling tot wanneer exact Burgertoken wordt gevraagd. Een Service Provider kan vragen van zowiezo een nieuwe authenticatie uit te voeren voor elke gebruiker, zelfs al heeft deze gebruiker reeds een actieve sessie met een voldoende sterk authenticatiemiddel op de FAS+. Type van gebruikersidentificatie Dit attribuut controleert dus het Single Sign On gedrag van de FAS+ over de verschillende Service Providers binnen de Circle of Trust met Fedict. Toegelaten waarden: urn:oasis:names:tc:saml:2.0:nameidformat:transient urn:oasis:names:tc:saml:2.0:nameidformat:persistent Authenticatie request code Specifieert of transient of persistent NameID s gebruikt moeten worden in de koppeling. Zie sectie 2.4 Lessons learned: valkuilen hieronder. Unieke identificatie van de Authentication Request. (/AuthnRequest/@ID) Afkomstig van Service Provider (/AuthnRequest/Issuer) De unieke identifier van de Service Provider binnen het Fedict IAM systeem. 11

12 Metadata informatie in authentication response Vervat in stap 4) in sectie 2.1 hierboven. Attribuut Authenticatie method (/Response/Assertion/AttributeStatement/ AttributeValue) Authenticatie resultaat Tijdstip sinds begin sessie Omschrijving Verwijzing naar het gebruikte authenticatiemiddel. Dit laat applicaties toe van functionaliteit te bieden afhankelijk van het gebruikte authenticatiemiddel, bvb leesrechten bij gebruik van een Burgertoken en schrijfrechten enkel bij eid authenticatie. Het resultaat van de aanmelding. Ook ingeval van een mislukte authenticatie zal Fedict een antwoord sturen aan de Relying Party. Moment van de authenticatie. Doel Service Provider (/Response/Conditions/AudienceRestriction /Audience) Referentie naar Authenticatie request code (/Response/Subject/SubjectConfirmation/ Bepaalt voor welk Service Provider (=Relying Party) het antwoord geldig is. Verwijzing naar de Authentication Request van de Relying Party waarop Fedict reageert. SessieID Dit metadata attribuut vermijdt dat een respons van Fedict wordt hergebruikt, mogelijk zonder een geldige Autentication Request van de Relying Party. De unieke identifier van de gebruikerssessie op het Fedict IAM systeem. 2.4 Lessons learned: valkuilen Authenticatiemethode De Service Provider dient een specifieke authenticatiemethode aan te vragen in de SAML 2.0 Authentication Request via een SAML 2.0 attribuut AuthenticationContext. In bepaalde gevallen, bvb gebruik van rollen of specifieke opzoekingen in authentieke of betrouwbare bronnen, wordt afgeweken van de standaard AuthenticationContext. Het is in alle gevallen belangrijk dat de Service Provider de correcte URN van de correcte AuthenticationContext aanvraagt bij de FAS+ IDP, zoniet worden mogelijk niet de juiste attributen, rollen of authenticatiemethode teruggegeven of worden bepaalde authenticatiemethodes zelfs niet als loginscherm aangeboden. 12

13 De authenticatiemethode kan door exact het gevraagde of minimaal het gevraagde authenticatiemiddel ingevuld worden Persistent en transient name ID s Om problemen met machtigingen van de privacy commissie te vermijden is het mogelijk om het Fedict IAM geen gevoelige attributen over Identiteiten te laten uitleveren. In sommige gevallen volstaat het binnen een applicatie van op basis van een transient name ID en een rol een gebruiker toegang te geven tot de applicatie. Fedict plant in de toekomst een dienst die een audit trail verzekert. Deze dienst zal in gerechtvaardigde situaties toelaten van de transient ID op dat tijdstip te linken met een Identiteit, zonder dat de Service Provider hiervoor privacy gevoelige informatie heeft ontvangen. Op dit ogenblik biedt Fedict deze dienst nog niet aan. In sommige gevallen bestaan lokale user accounts en kunnen deze met een door Fedict gegeneerde Persistent Identifier verrijkt worden in de Identity Store van de Service Provider. Het Fedict IAM kan bij authenticatie dan de Persistent Identifier uitleveren, op basis waarvan de gebruiker lokaal bij de Service Provider kan geïdentificeerd worden. Opnieuw heeft Fedict geen gevoelige informatie uitgeleverd, wat het machtigingsproces vergemakkelijkt Structuur van privilege informatie Het Fedict IAM levert privilege informatie op twee verschillende vormen uit: string formaat en HTML encoded XML formaat. In beide gevallen zit de informatie vervat in de privilege informatie attributen in het SAML bericht. De string formaten worden per consumerende Service Provider afgesproken. Datavelden worden van mekaar gescheiden door middel van scheidingstekens zoals :, _,,, etc. met als meestgebruikte vorm: <applicatie>_<rol>:<orgcode1>,<orgcode2> <applicatie>_<rol2>:<orgcode3>,<orgcode4> Het XML formaat volgt een schema om deze rolinformatie over te dragen met als vaste attribuut role name en mogelijk één of meerdere parameters, bvb: <rol:roleresult xmlns:rol=" <rol:role name="<applicatie_rol>" xmlns:rol=" <rol:roleattribute name="companyid"> </rol:roleattribute> <rol:roleattribute name="fedictdomain">somedomain</rol:roleattribute> </rol:role> </rol:roleresult> 2.5 Toepassing: informatie in een koppeling zonder rollen informatie In het eenvoudigste scenario vraagt de Service Provider een bepaalde AuthenticationClass aan voor de sessie van een gebruiker en levert de FAS+ een aantal identiteitsattributen, geen privilege informatie, uit aan de Service Provider. 13

14 Een typische request ziet er dan als volgt uit, met de belangrijkste attributen uit het informatie oogpunt vet aangeduid: ForceAuthn, Issuer, NameIDPolicy en RequestedAuthnContext. <samlp:authnrequest xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" ID="s f77b ef3c1c3ad7038ec635ab9a" Version="2.0" IssueInstant=" T19:00:14Z" Destination=" ForceAuthn="false" IsPassive="false" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL=" <saml:issuer xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion">fedlettest1</saml:issuer> <ds:signature xmlns:ds=" <! - signature information removed of readability --> </ds:signature> <samlp:nameidpolicy xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" SPNameQualifier="FedletTest1" AllowCreate="true"></samlp:NameIDPolicy> <samlp:requestedauthncontext xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" Comparison="minimum"> <saml:authncontextclassref xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion">urn:be:fedict:citizentoken</saml:authnconte xtclassref> </samlp:requestedauthncontext> </samlp:authnrequest> Een typische response ziet eruit als volgt, met als belangrijkste attributen: combinatie Destination, ID en InResponseTo verhinderen replay attacks en misbruik van gecapteerde responses, de Status Code, de AuthnContext de inhoud van de attribute statement (alle info binnen <saml:attributestatement> tags, niet in kleur). <samlp:response xmlns:samlp="urn:oasis:names:tc:saml:2.0:protocol" xmlns:saml="urn:oasis:names:tc:saml:2.0:assertion" Consent="urn:oasis:names:tc:SAML:2.0:consent:obtained" Destination=" ID="idEgYuquDWiDQypa6K1U0JaSk-x8s" InResponseTo="s f77b ef3c1c3ad7038ec635ab9a" IssueInstant=" T19:00:15Z" Version="2.0"> <saml:issuer> <samlp:status> <samlp:statuscode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> </samlp:status> <saml:assertion ID="id75HGuPQ5xcAnd13bQfs8Paheako" IssueInstant=" T08:03:38Z" Version="2.0"> <saml:issuer> <ds:signature xmlns:ds=" <! Signature information removed for readability --> </ds:signature> 14

15 <saml:subject> <saml:nameid Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" NameQualifier=" SPNameQualifier="FedletTest1">zrStwEUD9k/MBXAmWwFwLVMIfSBVD3slYgdALw==</saml:NameID> <saml:subjectconfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:subjectconfirmationdata InResponseTo="s f77b ef3c1c3ad7038ec635ab9a" NotOnOrAfter=" T9:02:15Z" Recipient="FedletTest1"/> </saml:subjectconfirmation> </saml:subject> <saml:conditions NotBefore=" T08:58:38Z" NotOnOrAfter=" T09:08:38Z"> <saml:audiencerestriction> <saml:audience>fedlettest1</saml:audience> </saml:audiencerestriction> </saml:conditions> <saml:authnstatement AuthnInstant=" T09:00:15Z" SessionIndex="id75HGuPQ5xcAnd13bQfs8Paheako"> <saml:authncontext> <saml:authncontextclassref> urn:be:fedict:eid</saml:authncontextclassref> <saml:authncontextdeclref>urn:be:fedict:eid</saml:authncontextdeclref> </saml:authncontext> </saml:authnstatement> <saml:attributestatement> <saml:attribute xmlns:xsd=" xmlns:xsi=" Name="surname" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:attributevalue xsi:type="xsd:string">lenaerts</saml:attributevalue> </saml:attribute> <saml:attribute xmlns:xsd=" xmlns:xsi=" Name="egovNRN" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:attributevalue xsi:type="xsd:string"> </saml:attributevalue> </saml:attribute> <saml:attribute xmlns:xsd=" xmlns:xsi=" Name="givenName" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic"> <saml:attributevalue xsi:type="xsd:string">pieter Andreas</saml:AttributeValue> </saml:attribute> </saml:attributestatement> </saml:assertion> </samlp:response> 15

16 3 ARCHITECTUUR OOGPUNT Dit hoofdstuk wil een conceptueel overzicht geven van de verschillende abstracte componenten die een taak vervullen in het Federation scenario tussen een applicatie en de Federal Authentication Service (FAS) zodat het mogelijk wordt een gemeenschappelijke terminologie aan te wenden over betrokken componenten in de koppelingen met FAS. Een duidelijk / consistent begrippenkader is noodzakelijk met betrekking tot diensten (en vooral specifieke implementaties en interoperabiliteit van dergelijke diensten). Dit wil zeggen dat simpele begrippen zoals Policy Enforcement Points, Policy Decision Points, Policy Administration Points, Policy Information Points (IDPs) algemeen gebruikt worden, maar dat alle partijen er zich van bewust moeten zijn dat deze heel anders technologisch ingevuld worden bij de verschillende spelers. Het is dus noodzakelijk dat de betrokkenen zich hiervan bewust moeten zijn, dat er een overkoepelende IAM Enterprise Architectuur dient te zijn en dat de juiste interoperabele interfaces afgesproken moeten worden. De eerste sectie geeft een opsplitsing in abstracte componenten van de security architectuur van de applicatie en de componenten van de Federation architectuur die de integratie tussen de applicatie en FAS mogelijk maakt. Deze sectie verbindt de abstracte componenten met de functionele flow en verklaart stap voor stap welke component welke taak voor zich neemt. De tweede sectie herhaalt de functionele flow uit de eerste sectie en illustreert de rollen van de verschillende componenten aan de hand van de Fedict IAM Referentie Architectuur. 3.1 Overzicht componenten in functie van Referentie Architectuur Figuur 3 hieronder geeft weer welke abstracte componenten werkzaam zijn in en met het Fedict IAM. De verticale kolommen geven de hoofd domeinen weer waarin de componenten werkzaam zijn. Horizontaal wordt weergegeven in welke laag de component werkzaam is: in business logica, in informatie uitwisseling of opslag van data. De componenten met een gekleurd kader zijn van belang in het kader van authenticatie via Federation met het Fedict IAM. De componenten met een oranje kader worden beheerd door Fedict. De componenten met een groen kader worden beheerd door de klant van Fedict. De volgende subsecties verduidelijken de algemene rol van deze componenten en illustreren deze ook in volgorde van hun voorkomen in de functionele flow uit sectie 2.1 hierboven. Figuur 4 onderaan deze sectie toont de informatieflows tussen de eindgebruiker, de verschillende componenten binnen een organisatie en tussen de componenten die de organisaties integreren. 16

17 Component bij Klant Component bij Fedict Figuur 3: Fedict Referentie Architectuur Access Control Policy Enforcement Point Het Policy Enforcement Point (PEP) is een component van een applicatie die toegang tot de applicatie controleert. De PEP bevindt zich typisch op twee plaatsen in de applicatie architectuur. Enerzijds zal er voor coarsegrained access control een PEP voorzien zijn vóór de web applicatie of zeer vroeg in de logica die sessie informatie controleert en zo toegang tot een pagina levert of niet. Concreet kan dit ingevuld worden door een web filter of een intercepting filter, etc. Anderzijds komt een PEP voor in de business logica waar fine-grained access control op business transaction niveau plaatsvindt. Wanneer een gebruiker een web applicatie contacteert onderschept de PEP van de applicatie de browser request en stelt een Policy vraag aan de Policy Decision Point. Tijdens het presenteren van pagina s en verwerken van transacties zal de business logic laag van de applicatie ook Policy vragen stellen aan de Policy Decision Point. Dit gebeurt in stap 2) van de functionele flow in sectie 2.1. De PEP zal conceptueel gezien geen beslissing nemen of een aanvraag tot toegang al dan niet mag uitgevoerd worden. De PEP geeft zijn vraag door aan de Policy Decision Point. Vaak vallen PEP en PDP samen in een conditional statement in applicatielogica. In dit geval zijn de PEP en de PDP geen logisch afzonderlijke modules, maar de functies van een PEP en PDP worden hierdoor wel degelijk ingevuld. 17

18 3.1.2 Access Control Policy Decision Point De Policy Decision Point (PDP) is een component die beslissingen neemt over het al dan niet ter beschikking stellen van functionaliteit, gebaseerd op informatie over een gebruiker (bvb privilege informatie, persoonlijke informatie zoals leeftijd, etc). Deze component kan centraal zijn of een onderdeel van de business logic laag van een applicatie. Door de PDP als een aparte logische component weer te geven kunnen autorisatievragen doorgegeven worden een bvb een centrale autorisatie server die vragen van verschillende applicaties centraal en dus uniform over de hele organisatie beantwoordt. De PDP baseert de beslissing op informatie over de gebruiker afkomstig van een Policy Information Point. Wanneer de PEP een vraag heeft geformuleerd over het leveren van toegang aan een pagina of transactie aan de sessie van een gebruiker, dan zal de PDP informatie vragen over de sessie aan de PIP Access Control Policy Information Point Het Policy Information Point (PIP) 1 is een component van een centrale PDP of van de PDP intern in de applicatie die informatie over een gebruiker uitlevert aan de PDP. De Fedlet vervult deze rol door sessie informatie en privilege informatie op te vragen bij de Identity Provider van Fedict, de FAS Federation Service Provider Een Federation Service Provider (SP) is een component in een Federation context die een dienst levert aan een verbruiker van de dienst en daarvoor vertrouwt op informatie over de verbruiker afkomstig van Trusted Third Parties. De SP haalt de informatie op via een authentication request aan de FAS Identity Provider in een Federation context. Daardoor fungeert de Fedlet enerzijds als PIP in de applicatie security architectuur en anderzijds als Service Provider in de Federation architectuur. Het doorgeven van de authentication request van de SP naar de IdP komt overeen met stap 2) in sectie Deze component staat niet afgebeeld in Error! Reference source not found., maar situeert zich op de Informatie laag voor Access Control & Identification. 18

19 3.1.5 Federation Identity Provider De Federation Identity Provider levert informatie over Identiteiten aan partijen die vertrouwen (relying) op het antwoord van de IdP. De IdP vormt zo een Circle of Trust met de Relying Parties, waaronder de Federation Service Providers uit sectie De doorgegeven informatie kan van verschillende aard zijn: Persoonlijke Informatie laat toe van de Identiteit van de gebruiker vast te stellen, bvb Rijksregister nummer. Contact Informatie bevat contactinformatie zoals adres of voorkeurstaal. Privilege Informatie bevat informatie over toegekende rollen aan de gebruiker. De IdP ontvangt een vraag van een Relying Party in stap 2) in sectie 2.1, maar moet mogelijk nog de identiteit van de gebruiker vaststellen. Deze identificatie zal gebeuren door een Access Control Identity Verification Point aan de gebruiker te presenteren Access Control Identity Verification Point Het Access Control Identity Verification Point (IVP) heeft als doel de identiteit van een gebruiker vast te stellen. In de FAS gebeurt dit op vraag van de IdP in de loginschermen van Fedict, waar de gebruiker een keuze kan maken tussen authenticatiemiddelen. De IVP baseert zich op credential information van identiteiten die opgeslagen zitten in de Identity Identification Storage Point en geeft het resultaat van de aanmelding terug aan de IdP Identity Identification Storage Point Het Identity Identification Storage Point (ISP) is een datastore die credential, persoonlijke en contact informatie over de identiteit bevat. De ISP wordt aangesproken door de IdP voor het uitleveren van attributen en door de IVP voor de verificatie van de identiteit Identity Privilege Storage Point Het Identity Privilege Storage Point (PSP) is een datastore die privilege informatie bevat voor een identiteit: roltoekenningen en alle parameters en metadata van die toekenningen zoals geldigheidsdata, parameterwaarden, enz. De PSP wordt aangesproken door de IdP voor het uitleveren van privilege informatie van een identiteit. 19

20 3.2 Toepassing: Fedlet FAS integratie uit architectuur oogpunt Figuur 4 hieronder geeft de verschillende abstracte componenten in de Fedict IAM Referentie Architectuur weer. De pijlen op de figuur geven weer welke component een andere component contacteert voor informatie. Merk op dat een technische component meerdere rollen kan vervullen: - In het integratiescenario van een Fedlet koppeling met de FAS vervult de Fedlet de rol van Access Control Policy Information Point en Federation Service Provider. - De Fedict edirectory doet dienst als zowel Identity Identification Storage Point als Identity Privilege Information point. Wanneer we de stappen uit sectie 2.1 volgen doorlopen we volgende componenten van de referentie architectuur: De Gebruiker contacteert de applicatie en wordt onderschept door de logica in de applicatie die sessies controleert, dit is een PEP op coarse-grained niveau, die toegang tot delen van de applicatie afschermt. De PEP stelt zijn vraagt aan de PDP om de gebruiker toegang te geven, maar er is nog geen informatie over de identiteit van de gebruiker of zijn/haar privileges. De PDP contacteert dus de PIP voor het ophalen van informatie van de gebruiker. De applicatie is in een Federation Circle of Trust verbonden met Fedict en vertrouwt op Fedict voor informatie over de gebruikers en hun privileges. De PIP contacteert dus een Federation Service Provider die een authentication request stelt aan de Federation Identity Provider. De IDP stelt vast dat er nog geen informatie bekend is over de sessie van de gebruiker, en moet dus de gebruiker identificeren. Daarom wordt de gebruiker naar een Identity Verification Point gestuurd waar zijn/haar identiteit op basis van informatie in een Identity Identification Storage Point wordt bepaald. Uit een Identity Privilege Storage Point wordt privilege informatie opgehaald, zodat de IDP de Identification Information en Privilege Information van de gebruiker kan terugsturen naar de Service Provider in een authentication response. Deze Service Provider ontvangt de authentication response en geeft de identity en privilege information terug aan het Privilege Information Point. De PIP kan nu de informatie doorgeven aan het Policy Decision Point, welke nu een beslissing kan nemen of de gebruiker toegang mag krijgen tot bepaalde logica. De goed- of afkeuring door de PDP wordt doorgegeven aan de Policy Enforcement Point, die de effectieve presentatie van de inhoud toelaat. 20

21 Fedlet IAM Application Integration Guide v2.0 Eindgebruiker Applicatie intern IDP - SP SP PIP PEP Web Pages WEB LAYER IVP IDP PDP Business Logic PEP BUSINESS LAYER PSP ISP Database Tables DATA LAYER FAS Applicatie Figuur 4: Referentie componenten in Fedlet koppeling 21

22 4 TECHNISCH OOGPUNT Dit hoofdstuk wil een overzicht bieden van drie technische implementatiescenario s en een inleiding bieden om een vrij verkrijgbare standaard oplossing, de OpenAM Fedlet, enerzijds te configureren als Federation Service Provider in een Circle of Trust met het Fedict IAM en anderzijds de Fedlet te integreren als Policy Information Point voor een web applicatie. Om de integratie met FAS+ te vereenvoudigen is er een integratie kit ontwikkeld. In annex 5.4 wordt deze integration kit uitgebreid beschreven. 4.1 Ondersteuning van integratiescenario s Drie belangrijke implementatiestrategieën kunnen gebruikt worden om te koppelen voor authenticatie en attribuut diensten met het Fedict IAM. Elk van deze strategieën biedt uiteraard voor- en nadelen, vooral naar complexiteit van implementatie en kost toe. De best ondersteunde integratiestrategie is het uitrollen van een vendor-supported Federation oplossing zoals ForgeRock OpenAM, Novell Access Manager, Oracle Identity Federation, Microsoft ADFS 2.0, etc. Deze producten nemen voor een groot deel de complexiteit van een Federation scenario voor zich. De rol van Fedict beperkt zich voor ondersteuning tot het aanleveren van het architectuurkader zoals hierboven omschreven en ondersteuning kan ook geboden worden door de vendor in kwestie. De tweede integratiestrategie gebruikt de Fedlet, een onderdeel van OpenAM code. Dit is een vrij te gebruiken, open source, lichtgewicht implementatie van een Federation Service Provider. Deze kan geïntegreerd worden met een web applicatie om deze via Federation te ontsluiten. Bij deze strategie biedt Fedict dit document als ondersteuning voor de technische configuratie maar het is aan de klanten van Fedict om de nodige know-how te voorzien voor de integratie van de Fedlet code met de web applicatie. Er is ook de mogelijkheid om een aangepaste Fedlet te gebruiken. Deze integration kit bevat al enkele elementen die specifiek zijn aan het Fedict systeem. De laatste integratiestrategie is een volledig custom implementatie van een Federation Service Provider te implementeren, al dan niet aan de hand van libraries zoals OpenSAML. Hierbij kan Fedict geen enkele ondersteuning bieden. 4.2 Migratie van standaard FAS1 implementaties naar FAS+ via Fedlet De Fedlet kan volledig de SAML1 implementatie die voor FAS1 door Fedict werd uitgerold bij klanten, vervangen. Deze SAML1 implementatie leverde een SAML1 consumer pagina waar een applicatie kon op inhaken. De integratiestrategie voor een Fedlet is in lijn met de voorgaande: de FAS+ roept een SAML2 consumer pagina aan waar de applicatielogica van de klant van Fedict op inhaakt om op policy beslissingen te nemen op basis van de geïnterpreteerde informatie uit de SAML2 response. Naast het gebruik van een nieuwe standaard (SAML2) zijn er nog enkele andere verschillen tussen de FAS1 en de FAS+. De volgende sectie (4.2.1) behandelt de voornaamste verschillen. 22

23 4.2.1 Technische verschillen tussen FAS1 en FAS Attribuut mapping De benaming van attributen, die de FAS1 teruggeeft, is veranderd in de FAS+. De FAS+ geeft de attributen onder een ander naam terug. Hiermee dient rekening gehouden te worden indien deze informatie nodig is in de applicatie. De tabel (Tabel 1) geeft het verschil in naamgeving weer. Naam attribuut FAS1 egovuserid SurName FirstName NRN Language AgencyCode AgencyName DepartmentCode DepartmentName Prof Statute Title Category Naam attribuut FAS+ uid surname givenname egovnrn mail PrefLanguage egovagency AgencyName egovdepartment DepartmentName egovprof egovcsstatute egovworktitle Category Tabel 1: Attribuut mapping Merk op dat indien gebruik gemaakt wordt van de integration kit, de mapping van attributen automatisch gebeurd. Gebruikers van de integration kit zullen dus de FAS1 benaming behouden Authenticatie middelen De FAS+ heeft de volgende authenticatie middelen: eid en burgertoken. Authenticatie met gebruikersnaam en paswoord of ambtenarentoken kan enkel nog voor klanten die migreren vanuit de FAS1 (en daar ook die authenticatiemiddelen hadden) of na expliciete goedkeuring van Fedict. Aanvraag kan via de ServiceDesk van Fedict Login scherm Het FAS+ loginscherm (Figuur 5) is opgesmukt en bevat nu rechtstreekse toegang tot het ingeven van gebruikersnaam en wachtwoord. Het bevat ook extra informatie en relevantie verwijzingen naar andere pagina s. De rode rechthoek op Figuur 5 en Figuur 6 kan, indien gewenst, het logo van de klant bevatten. In het geval er in de FAS1 een logo geconfigureerd was, zal dit automatisch overgenomen worden in de FAS+. 23

24 Figuur 5: FAS+ Login scherm Figuur 6: FAS1 Login scherm Single log-out De FAS+ ondersteunt ook Single log-out (SLO). De klant kan een SLO request sturen naar de FAS+. De FAS+ zal dan de sessie die het heeft met de gebruiker beëindigen. Er dienen hiervoor certificaten gebruikt te worden Configuratie Fedict kan indien gewenst aan haar klanten een voorgeconfigureerde Fedlet uitleveren. Op basis van de informatie verzameld in het onboardingsproces vult Fedict de metadata en certificaat informatie van de FAS+ IDP en de Service Provider van de klant in. Fedict levert dan de Fedlet configuratie files. De klant moet in dit geval enkel het integratie gedeelte in de volgende secties uitvoeren en de application server configureren. Er kan ook gebruik gemaakt worden van de FAS+ integration kit. Deze staat uitgebreid beschreven in annex 5.4. Ook in dit geval zullen de aangeleverde configuratiebestanden gekopieerd moeten worden. 24

25 4.3 Overzicht van configuratie en integratie van de OpenAM Fedlet Het is niet de bedoeling in dit document een volledige documentatie van de Fedlet te beschrijven, enkel van de grote lijnen en voorbeelden aan te duiden. De OpenAM Fedlet is een lichtgewicht implementatie van een Service Provider in een Identity Federation context. De Fedlet kan in een web applicatie geïntegreerd worden om toegangscontrole uit te voeren via Federation met een Identity Provider. De Fedlet komt historisch uit de source tree van Sun OpenSSO. OpenAM is een fork van de OpenSSO code sinds begin De Fedlet downloaden De Fedlet is verkrijgbaar in de distributie van OpenAM. De volledige OpenAM code kan gedownload worden via In de OpenAM download file bevindt zich een subdirectory Fedlet. Deze bevat de code voor ASP.NET of Java web containers. Deze Integration Guide focust op de Java deployment Prerequisites Java Servlet container Een Java Servlet container moet geconfigureerd zijn voor communicatie met Fedict: een private key voor https verkeer moet opgeladen zijn in een trust store. Het certificaat moet in de Fedict IDP voor de SP geregistreerd zijn en moet dus doorgegeven worden aan Fedict en correct opgeladen worden door Fedict in de IDP Toegang tot het FedMAN De Fedict Test & Acceptatie omgeving is niet publiek toegankelijk, maar enkel via het FedMAN. Daarom is toegang nodig van de SP op het FedMAN Deployment en configuratie van de Fedlet De Fedlet wordt geleverd als war file die een aantal basisfunctionaliteiten voorziet en testpagina s biedt. Voor test doeleinden kan de installatie van de Fedlet zich beperken tot het deployen van de Fedlet Web application Archive in de Java Servlet container, bvb, voor Tomcat moet fedlet.war in de webapps directory gezet worden. Daarna is de Fedlet bereikbaar op bvb De deployment voor zover ze in deze sectie is beschreven laat enkel toe van een SAML 2.0 koppeling te testen met een IDP en levert op zich geen integratie met een applicatie. Zie daarvoor sectie Fedlet 25

26 integreren in een applicatie beneden. De configuratie richtlijnen blijven echter dezelfde bij een integratie in een bestaande applicatie. Fedict biedt voor Java omgevingen aan van een zover mogelijk geconfigureerde Fedlet aan te leveren aan zijn klanten. Op basis van het boarding document kan de configuratie volledig worden klaargezet, afgezien van de locatie van de Java keystore en de Fedlet home directory die de Fedlet moet gebruiken Fedlet Home directory De Fedlet verwacht de SP en IDP metadata in eenzelfde directory. Deze moet meegegeven worden via de JAVA_OPTS environment variabele naar Tomcat. Volgende optie moet gezet worden in JAVA_OPTS: -Dcom.sun.identity.Fedlet.home=<pad_naar_Fedlet_home_dir> Metadata en Circle of Trust templates aanpassen Voor elk van de sp*.xml en idp*.xml metadata files is een template meegeleverd in de OpenAM Fedlet distributie. Deze templates bevatten placeholders die telkens vervangen moeten worden door een reële waarde specifiek voor de setup. Volgende placeholders moeten vervangen worden in de files: Bestandsnaam Fedlet.cot idp.xml idp-extended.xml sp.xml sp-extended.xml FederationConfig.properties Omschrijving Definitie van de Circle of Trust tussen IDP en Fedlet Entity descriptor, certificaten, url's en services van IDP Entity config. Referenties naar COT's per Federation domein. Entity descriptor, url's en services van SP Entity config. Requirements voor signing, attribute mapping, etc. Configuratie van Fedlet zelf Merk op dat in het kader van een Fedict onboarding de SP entityid moet ingevuld worden met de URL van de applicatie Opladen SP metadata in Fedict IDP De SP moet geregistreerd zijn in de Fedict IDP. Daarom moet de sp.xml file doorgestuurd worden aan Fedict zodat deze in de Test & Acceptatie omgeving kan opgeladen worden. Merk op dat het opladen van SP metadata enkel kan in het kader van de onboarding van een applicatie in het Fedict IAM. Het onboardingsproces kan via de Fedict Service Desk opgestart worden. Indien getest wordt buiten het kader van een onboarding moet lokaal een IDP opgezet worden. 26

27 4.3.5 Fedlet testen Ga met een web browser naar het Fedlet deployment URI. Als de SP metadata correct is doorgegeven aan Fedict en deze is opgeladen in de IDP dan zou de link voor Browser Initiated HTTP Post binding naar het Fedict login scherm (IVP) moeten leiden. Na authenticatie wordt de teruggegeven data uit de SAML 2.0 response van de Fedict IDP weergegeven Fedlet integreren in een applicatie Integratie van de Fedlet in een bestaande Java web applicatie gebeurt door de files in de fedlet.war uit te pakken en samen te voegen met de bestaande applicatie files. Vervolgens moeten de endpoint locations ingesteld worden in sp.xml voor de verschillende services en bindings en moeten deze locations de logica bevatten om de informatie in de responses van de IDP te consumeren Samenvoegen van code De integrale inhoud van de Fedlet war moet eerst uitgepakt worden op een tijdelijke locatie. Volgende bestanden moeten aangepast of verwijderd worden: 1. index.jsp index.jsp bevat het welkomscherm voor de test functionaliteit van de Fedlet. De links in de originele index.jsp geven een voorbeeld hoe de SSO jsp s moeten aangesproken worden. De originele index.jsp moet niet in de bestaande applicatie gevoegd worden. 2. fedletsampleapp.jsp fedletsampleapp.jsp bevat voorbeelden hoe een response verwerkt moet worden. fedletsampleapp.jsp moet niet as-is in de bestaande applicatie gevoegd worden, maar moet aangepast worden om de nodige applicatielogica op te roepen. 3. web.xml en sp.xml fedletsampleapp.jsp wordt gebruikt als jsp file voor servlet fedletapplication in web.xml. Deze fedletapplication servlet is standaard als endpoint location voor de verschillende services en bindings 27