Wat is het? 

Webservice die IDM toelaat om rollen dynamisch op te halen van jouw toepassing.

Wanneer heb je het nodig? 

Wanneer de fijnmazige rollen van jouw toepassing dynamisch zijn en een statische lijst niet voldoet aan je vereisten, bijvoorbeeld omdat er wekelijks rollen bijkomen of wegvallen.

Het principe van dynamische provisionering 

In een aantal situaties is het mogelijk dat een statisch rechten- en rollenmodel in IDM niet volstaat voor de gekoppelde toepassing, of wegen de beperkingen van deze eenmalige vertaling te zwaar door:

• Je wenst zelf in staat te zijn om op een eenvoudige, dynamische manier nieuwe rollen toe te voegen aan je rechtenmodel in IDM. De gangbare doorlooptijden voor wijzigingen door je dossierbeheerder, worden niet voldoende kort geacht en je wenst steeds snel te kunnen schakelen.

• Het aantal rollen in je applicatie is te hoog om manueel gedefinieerd te worden door je dossierbeheerder, of de rollen in je applicatie zijn bijzonder organisatie-specifiek. Veronderstel bijvoorbeeld dat je applicatie uitvoerig gebruikt wordt door alle Vlaamse lokale besturen, en dat elk van de 300 Vlaamse gemeentes binnen je applicatie autonoom nieuwe rollen kan definiëren. Als de te definiëren rollen tussen de gemeentes daarenboven onderling sterk afwijken, is de keuze voor een statisch rollenmodel in IDM voor jouw applicatie geen al te best idee. 

Digitaal Vlaanderen erkent in deze situaties de nood aan het dynamisch ophalen van de rollen van je toepassing, en biedt in die optiek een standaardPlus-integratie met IDM aan. 

In een standaardPlus-context integreert je toepassing niet enkel rechtstreeks met ACM (via OpenID Connect of SAML 2.0), maar ook rechtstreeks met IDM. Wanneer een gebruikersrecht binnen een bepaalde organisatie (bijv. Stad Gent) wordt toegekend, zal IDM in je toepassing de rollen dynamisch gaan ophalen die binnen deze organisatie gedefinieerd zijn. De rollen worden dan, in-real-time, getoond in de IDM-schermen, alwaar de lokale beheerder van de organisatie de organisatie-specifieke rollen kan zien en toekennen. 

Op deze manier kan je een fijnmazigheid introduceren in IDM die in een standaard-context niet realiseerbaar is: binnen elke organisatie zullen in IDM exact die rollen zicht- en toekenbaar zijn die de toepassing doorgeeft aan IDM. Binnen Stad Gent zal men dan bijvoorbeeld enkel de rollen kunnen zien en toekennen die in je toepassing specifiek voor Stad Gent gedefinieerd zijn. Daarenboven kan je aan je eigen tempo nieuwe rollen introduceren zonder dat dit kenbaar dient te worden gemaakt aan je dossierbeheerder. 

De External Artefact Webservices (EAWS) 

De communicatie tussen IDM en je toepassing, meestal 'doelsysteem' of 'target system' genoemd, zal tot stand komen via webservice calls, met name via een External Artefact Webservice of EAWS. Via deze webservice zal IDM, bij het toekennen of wijzigen van het gebruikersrecht dat toegang geeft tot je toepassing, de rollen dynamisch ophalen via het SOAP-protocol. SOAP (Simple Object Access Protocol) is een protocol dat gebruikt wordt voor het uitwisselen van gestructureerde informatie tussen IT-systemen en daarbij een beroep doet op de XML Information Set-specificatie.

IDM initieert voor een goed begrip steeds de communicatie en stuurt de organisatiecode van de werkrelatie die het voorwerp is van de rechtentoekenning, naar de EAWS. Het antwoord van de EAWS naar IDM dient opnieuw de gekozen organisatiecode te bevatten, én de rollen die IDM mag weergeven aan de lokale beheerder van de organisatie.

De technische EAWS-documentatie - alsook een voorbeeld-implementatie in Java - kunnen op onderstaande link geraadpleegd worden:

• EAWS Web Service

Op deze locatie kan men ook het XSD-schema raadplegen, alsook de technische beschrijving van de webservice (WSDL).

Met het oog op een veilige connectie tussen IDM en de webservice, is Mutual SSL verplicht. Om dit af te kunnen dwingen, zal de connectie steeds beveiligd worden via Datapower: op die manier kan gegarandeerd worden dat Mutual SSL correct geïmplementeerd is. Dat resulteert met andere woorden in volgende toekenningsflow:

Open

Op Datapower zullen de inkomende berichten van je toepassing steeds gecontroleerd worden oftewel zijn deze effectief wel afkomstig van de toepassing? Daartoe zullen wij bij een standaardPlus-integratie ook moeten kunnen beschikken over de server certificaten van je webservices. Andersom is het ook zaak dat langs toepassingszijde gevalideerd wordt dat de ontvangen berichten effectief van Datapower afkomstig zijn. Hiervoor bezorgen we jullie tijdens de integratie graag de client certificaten van Datapower.

Hou rekening met beperkingen

Via de EAWS zal IDM dus bij het toekennen binnen een bepaalde organisatie van het gebruikersrecht dat toegang geeft tot je toepassing, de rollen dynamisch ophalen die op jouw toepassing gedefinieerd zijn voor deze organisatie. De rollen worden dan, in-real-time, getoond in de IDM-schermen, alwaar de lokale beheerder van de organisatie de organisatie-specifieke rollen kan zien en toekennen. Deze procesflow geldt tevens wanneer een beheerder het gebruikersrecht wenst aan te passen: ook in zo'n scenario zal IDM de rollen dynamisch ophalen, en tonen aan de beheerder. 

In onderstaande scenario's dien je evenwel met volgende beperkingen van de EAWS rekening te houden:

• Je verwijdert intern, in je toepassing, binnen een bepaalde organisatie een rol die reeds is toegekend in IDM. De toekenningen van deze rol in IDM zullen niet verwijderd worden wanneer deze langs toepassingszijde verwijderd worden. Deze rol zal weliswaar niet meer opnieuw kunnen toegekend worden in IDM, maar de bestaande toekenningen persisteren. Er is een manuele actie van de lokale beheerder(s) van de resp. organisatie vereist, om deze rol in IDM volledig uit roulatie te halen. Vindt deze actie niet plaats, dan zal de vervallen rol wel nog steeds begrepen zijn in de ID-token (OpenID Connect) of SAML-respons (SAML 2.0) die door ACM uitgeleverd wordt aan de toepassing wanneer een gebruiker van deze organisatie zich aanmeldt op de toepassing.

• Je wijzigt intern, in je toepassing, binnen een bepaalde organisatie de technische naam van een rol die reeds toegekend is in IDM. De toekenningen van deze rol zullen in IDM niet automatisch geüpdatet worden wanneer deze wijziging plaatsvindt langs toepassingszijde. Wanneer de achterliggende, technische naam van een rol wijzigt, wordt dit door IDM gepercipieerd als de toevoeging van een nieuwe rol (met de geüpdatete technische naam) en het vervallen van de corresponderende oude rol (met de achterhaalde technische naam). Ook in dit scenario zal een manuele actie van de lokale beheerder(s) van de resp. organisatie vereist zijn, om enerzijds de nieuwe rol toe te kennen en anderzijds de oude rol uit roulatie te halen - dat kan voor een goed begrip wel simultaan. Vindt deze actie niet plaats, dan zal de achterhaalde oude rol nog steeds begrepen zijn in de ID-token (OpenID Connect) of SAML-respons (SAML 2.0) die door ACM uitgeleverd wordt aan de toepassing wanneer een gebruiker van deze organisatie zich aanmeldt op de toepassing.

Ons advies bestaat er in om voldoende duidelijk te communiceren over het verwijderen/wijzigen van rollen die reeds toegekend zijn in IDM, en zelfs te anticiperen op ID-tokens of SAML-responses die mogelijks sporen bevatten van de verwijderde rol(len). Voor een goed begrip: als toepassingseigenaar zal je in IDM wel over monitorrechten kunnen beschikken teneinde na te kunnen gaan of er eventueel achterhaalde rollen persisteren. Op basis van deze informatie kan je desgewenst gericht gaan communiceren naar de beheerders van de organisaties waarbinnen één of meerdere oude rollen toegekend zijn, en deze beheerders aansporen tot een correctie.