Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

DRAFT

Op deze pagina

Op onderliggende pagina’s

1. Introductie

1.1 Doelstelling van deze pagina

Deze pagina beschrijft welke acties klanten (of hun dienstverleners) moeten zetten om zelf een OAuth-Client aan te vragen voor de connectie met de webservices van het Vastgoedintegratieplatform (VIP). Dit proces loopt via het Beheerportaal van het Toegangsbeheer (ACM), een online webtoepassing waar medewerkers van organisaties zelf OAuth-Clients kunnen aanmaken en beheren voor de connecties met API’s van de Vlaamse overheid (die werken met het Toegangsbeheer als Identity Provider).

Naast het Beheerportaal is er ook nog een werkwijze om via een API geautomatiseerd Clients voor de VIP-API aan te maken. Deze werkwijze is buiten scope van deze Confluence-pagina.

1.2 Wat is het Beheerportaal?

Het Beheerportaal is een online webtoepassing van het Toegangsbeheer van de Vlaamse overheid (ACM) die als doel heeft om zoveel mogelijk interacties van klanten met het Toegangsbeheer in selfservice door de klant (of hun dienstverlener) te laten doen. Op termijn willen we zoveel mogelijk componenten van onze dienstverlening (REST-API’s, SOAP-API’s, OpenID Connect-aansluitingen, SAML-aansluitingen, enz.) via dit portaal laten verlopen. Het Beheerportaal moet de doorlooptijd van aansluitingen (b.v. voor het VIP-platform) drastisch verkorten en de zelfredzaamheid van klanten verhogen.

Het Beheerportaal is een gloednieuwe toepassing. Het OAuth-beheer en het VIP-platform zijn onze piloten voor dit project. Vooral op het vlak van User Interface en typische Quality of Life-functionaliteiten is er nog verbetering mogelijk. Feedback of suggesties mogen jullie altijd bezorgen aan sammy.roos@vlaanderen.be.

1.3 Twee verschillende scenario’s…

In de onderstaande handleiding maken we we onderscheid tussen 2 scenario’s:

  • Scenario 1: een klant maakt zelf een OAuth-Client aan voor de eigen organisatie

In dit scenario is het dus de klant zelf die volledig alle handelingen doet. Er is geen dienstverlener in het proces betrokken.

Bijvoorbeeld: een entiteit van de Vlaamse overheid of een lokaal bestuur vraagt volledig zelfstandig een Client aan voor de VIP-API.

  • Scenario 2: een dienstverlener maakt een OAuth-Client aan namens een andere organisatie (haar klant)

In dit scenario ligt de lead volledig bij de dienstverlener. Het is de dienstverlener die de Client zal aanmaken “namens” haar klant. De klant zal enkel eenmalig een goedkeuring moeten geven voor de creatie van de Client (in haar naam).

Bijvoorbeeld: Stad Oudenaarde vraagt aan dienstverlener X om in haar naam een Client aan te vragen voor de VIP-API.

1.4 … in twee verschillende omgevingen

We maken ook een onderscheid tussen 2 verschillende omgevingen, waar de werkwijze (in het bijzonder voor scenario 2) ietwat anders is:

  • Aanmaken van een Client in de T&I-omgeving (testomgeving)

In de testomgeving gebruiken we een vereenvoudigd proces voor scenario 2 (waar geen aparte goedkeuring nodig is van de klant). In beide scenario’s gebeurt ook het instellen van toegang tot het Beheerportaal volgens een vereenvoudigde procedure.

  • Aanmaken van een Client in PRD-omgeving (productieomgeving)

In de productieomgeving gebruiken we het volledige proces voor scenario 2 (waar wél een aparte goedkeuring nodig is van de klant). In beide scenario’s gebeurt ook het instellen van toegang tot het Beheerportaal volgens de officiële procedure.

  • No labels