Inleiding
Op deze pagina staan de diagrammen behorende bij de functie Authenticeren. De diagrammen tonen alleen de situatie waarin alle acties slagen tot en met dat de Persoon zich heeft laten authenticeren (de zogenaamde happy flow). De oranje banen horen (conform de MedMij-huisstijl) tot het Persoonsdomein, de blauwe tot het Aanbiedersdomein en de grijze tot externe domeinen.
| Drawio | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
In elke voltrekking van de in het diagram beschreven flow is steeds sprake van één van elk van de genoemde rollen.
- De Dienstverlener aanbieder laat de Persoonzich authenticeren.
- Wanneer de Persoon de authenticatie heeft afgebroken geeft de Dienstverlener aanbiederde mogelijkheid alsnog te authenticeren of de flow af te breken.
Uitzonderingen op de Happy flow van de functie Authenticeren
In onderstaande tabel staan de uitzonderingssituaties beschreven. Alle worden door de Dienstverlener aanbieder ontdekt.
| nr. | uitzondering | actie | vervolg |
|---|---|---|---|
| Authenticeren 1 | Dienstverlener aanbieder kan de identiteit van de Persoon niet vaststellen. | Dienstverlener aanbieder informeert Dienstverlener persoon dat verzoek niet wordt ingewilligd. | Allen stoppen de flow onmiddellijk na geïnformeerd te zijn over de uitzondering. |
| Authenticeren 2 | Persoon annuleert het inloggen. | Dienstverlener aanbieder presenteert een annuleringspagina en biedt Persoon de optie om toch in te loggen. | Indien Persoon kiest niet in te willen loggen, kan het scherm gesloten worden. Hiermee wordt de flow gestopt. Persoon kan er ook voor kiezen toch in te loggen. In dat geval vraagt Dienstverlener aanbieder weer om credentials. |
Applicatielaag
Verantwoordelijkheden inzake uitzonderingen op de happy flow zijn opgenomen bij de respectievelijke interface, waar de uitzonderingen bij de functies zijn genoemd.
| Inc drawio | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
In elke voltrekking van de in het diagram beschreven flow is steeds sprake van één van elk van de bovenaan genoemde rollen.
De flow kent de volgende stappen:
de User Agent stuurt een authorization request naar de Authorization Server. Het adres van het authorization endpoint komt uit de Aanbiederslijst. De
redirect_urigeeft aan waarnaartoe de Authorization Server de User Agent verderop moet redirecten (met de authorization code). Het authorization request mag desgewenst, onder voorwaarden, meerdere Gegevensdiensten van de Aanbieder bevatten.Info icon false title Toestemming voor meerdere Gegevensdiensten van een Aanbieder In een authorization request mogen meerdere Gegevensdiensten van eenzelfde Aanbieder worden gecombineerd wanneer:
- de gegevensdiensten worden aangeboden binnen één zelfde interfaceversie, EN
- de FQDN van de in de ZAL, voor deze gegevensdiensten, opgenomen AuthorizationEndpoints met elkaar overeenkomen, EN
- de FQDN van de in de ZAL, voor deze gegevensdiensten, opgenomen TokenEndpoints met elkaar overeenkomen.
- Daarop begint de Authorization Server de OAuth-flow (in zijn rol als OAuth Authorization Server) door een sessie te creëren.
- De Authorization Server vraagt de Persoon via zijn User Agent om credentials.
- Dan start de Authorization Server (nu in de rol van Authentication Client) de authenticatieflow door de User Agent naar de Authentication Server te redirecten, onder meegeven van een
redirect_uri, die aangeeft waarnaartoe de Authentication Server straks de User Agent moet terugsturen, na het inloggen van de Persoon. - De Authentication Server vraagt de Persoon via zijn User Agent om inloggegevens.
- Wanneer deze juist zijn, redirect de Authentication Server de User Agent terug naar de Authorization Server, onder meegeven van een ophaalbewijs. Wanneer het inloggen is afgebroken geeft de Authorization Server de Persoon alsnog de mogelijkheid via zijn User Agent in te loggen.
- Met dit ophaalbewijs haalt de Authorization Server rechtstreeks bij de Authentication Server het BSN op.