Identity & access management
Concept
Standaard is authenticatie vereist om een aanvraag (dossier) op te starten in de frontoffice alsook om de backoffice te betreden. Authenticatie gebeurt via een vertrouwde identity provider. Deze externe provider verifieert de identiteit en hoedanigheid van de gebruiker, en speelt die informatie vervolgens via een JWT-token door aan de Skryv applicatie. In het token kunnen bijkomende claims over de gebruiker vervat zitten zoals bijvoorbeeld rijksregisternummer of e-mailadres. Het voordeel is dat gebruikersbeheer binnen de Skryv applicatie zo beperkt mogelijk blijft en dat de gebruiker zich kan authenticeren in een vertrouwde omgeving.
Diagram
Onderstaand schema toont hoe identity & access management gebeurt binnen de scope van een Skryv applicatie.
Inlogprocedure
De gebruiker wil inloggen en wordt automatisch, eventueel via een tussenliggende pagina, doorgestuurd naar een vertrouwde identity provider zoals ACM/IDM (Vlaamse overheid), CSAM (federale overheid) of Vanden Broele MyAccount (specifiek voor dossierbeheerders van lokale besturen die willen inloggen op de backoffice). Voor test- en acceptatieomgevingen fungeert Keycloak als identity provider.
De gebruiker authenticeert zich bij de identity provider. Dit gebeurt op vertrouwde wijze via eID, itsMe of de myGov app. Voor gebruikers in de test- en acceptatieomgevingen is dit op basis van gebruikersnaam en wachtwoord.
De identity provider valideert de gebruiker en verstrekt een JWT-token. Deze wordt naar de Skryv applicatie gestuurd via het Open ID Connect protocol.
De Skryv applicatie weet nu op basis van de informatie in het JWT-token over welke gebruiker het gaat en start de juiste sessie op.
Meer info over inloggen op de frontoffice en op de backoffice.
Rechten & rollen
Voor elke gebruiker moeten er rechten en rollen ingesteld worden. Voor gebruikers die vanuit de frontoffice een dossier opstarten, gebeurt dit automatisch (rol ‘aanvrager’). Voor backofficemedewerkers gebeurt dit manueel vanuit het backoffice admin scherm.
Eén persoon, meerdere gebruikers
Het is mogelijk dat één en dezelfde persoon onder verschillende hoedanigheden kan inloggen op de applicatie (bijvoorbeeld als natuurlijk persoon of als bestuurder van een onderneming of vereniging). Dit resulteert dan in aparte gebruikers, elk met een eigen unieke ID.

Wanneer een persoon voor de eerste keer aanmeldt als bestuurder van een onderneming of vereniging, dan wordt meteen ook een organisatie ID aangemaakt.
Team functionaliteit
Gebruikers kunnen gegroepeerd worden in een team. Deze functionaliteit heeft een andere use case in de frontoffice en de backoffice.
Frontoffice: gebruikers gerelateerd aan dezelfde organisatie ID vormen een team.
Backoffice: teams worden manueel vanuit het backoffice admin scherm samengesteld.
Klik hier voor meer informatie.
Instellingen
Volgende applicatie eigenschappen regelen de identity & access management.
Eigenschap | Beschrijving |
|---|---|
| Authenticatieprotocol. Voorbeeld: |
Inloggen op de frontoffice (eportal) | |
| Naam of unieke id van de applicatie zoals gekend bij de identity provider. |
| Geheime sleutel die de applicatie moet gebruiken om zich te authenticeren bij de identity provider. |
| Voorbeeld: De De Tijdens de authenticatieprocedure zal de gebruiker zijn of haar toestemming moeten geven om deze informatie vrij te geven aan de applicatie. |
| Adres waar de identity provider de gebruiker naar terugstuurt na login (redirect). |
| Endpoint van de identity provider waar de applicatie een access token kan ophalen. |
| Endpoint van de identity provider voor start van de login flow. Dit is waar de gebruiker naartoe geleid wordt nadat hij of zij op login of aanmelden klikt. |
| JSON Web Key Set (JWKS) van de identity provider. Gebruikt door de applicatie om de handtekening in de JWT-token te valideren. |
| Adres waar de gebruiker terechtkomt na uitloggen uit de applicatie. |
Inloggen op de backoffice | |
| Naam of unieke id van de applicatie zoals gekend bij de identity provider. |
| Geheime sleutel die de applicatie moet gebruiken om zich te authenticeren bij de identity provider. |
| Voorbeeld: De openid scope activeert de OpenID Connect uitbreiding op OAuthr. De Tijdens de authenticatieprocedure zal de gebruiker zijn of haar toestemming moeten geven om deze informatie vrij te geven aan de applicatie. |
| Adres waar de identity provider de gebruiker naar terugstuurt na login (redirect). |
| Endpoint van de identity provider waar de applicatie een access token kan ophalen. |
| Endpoint van de identity provider voor start van de login flow. Dit is waar de gebruiker naartoe geleid wordt nadat hij of zij op login of aanmelden klikt. |
| JSON Web Key Set (JWKS) van de identity provider. Gebruikt door de applicatie om de handtekening in de JWT-token te valideren. |
| Adres waar de gebruiker terechtkomt na uitloggen uit de applicatie. |
| Boolean. Indien |
| Boolean. Indien |
