oauth - Authorisation Server van de Sociale Zekerheid

Overzicht

Systeem gebaseerd op OAuth 2.0 die een beveiligingsprotocol is waarmee een persoon zijn rechten op toegang tot een resource kan delegeren

Met dit protocol kan een toepassing namens iemand optreden zonder de geheime informatie van die persoon te moeten onthullen. Dit protocol wordt bijvoorbeeld gebruikt om REST-services te beveiligen. De client-toepassing haalt een Access Token op bij een authenticatieserver om namens de eigenaar van de resource toegang te krijgen tot een beschermde resource.

De Authorization Server van de sociale zekerheid heeft twee verschillende, complementaire doeleinden:

1. De Authorization Server implementeert de specificaties van OAuth2 om toepassingen (binnen en buiten de vertrouwenscirkel) toegang te geven tot de REST API's van de sociale zekerheid. Dit in overeenstemming met de toegangsregels en, in voorkomend geval, met de tijdelijke toestemming van de geauthentiseerde en geautoriseerde gebruiker.

OAuth2 definieert verschillende autorisatiestromen die in verschillende situaties kunnen worden gebruikt. Elke stroom heeft zijn eigen beveiligingsniveau en elke stroom moet in welbepaalde situaties worden gebruikt. De meest algemene en meest beveiligde stroom is de Authorization Code; de andere zijn optimalisaties van die stroom.

• Authorization Code

In eerste instantie laat deze stroom toe om een Access Token alsook een Refresh Token te verkrijgen. Vervolgens laat deze stroom toe om een Access Token te vernieuwen met behulp van het verkregen Refresh Token. Een Refresh Token heeft een langere levensduur en kan aan de Authorization server verstrekt worden om het Access Token te vernieuwen. Gezien het Refresh Token slechts één maal geldig is, wordt een nieuw Refresh Token verstrekt tijdens deze vernieuwing. Deze werkwijze laat toe om het Access Token te vernieuwen zonder dat de Resource Owner erbij moet zijn.

• Client Credential

Deze stroom laat toe om OAuth2 te gebruiken ingeval een toepassing niet in naam van een derde partij maar in eigen naam handelt. In dit scenario is de klant dus de Resource Owner en is het niet nodig om een Authorization Code uit te wisselen noch om toestemming te geven.
Bij deze stroom is het niet nodig om een Refresh Token te verstrekken, gezien de klant altijd aanwezig is om zich te authentiseren; het Refresh Token verliest zijn nut.

• Implicit

Het sterke punt van de Authorization Code Grant-stroom is dat ze de informatie eigen aan de verschillende componenten gescheiden houdt. Wanneer de Client echter een toepassing is die volledig binnen eenzelfde webpagina draait (in Javascript), is deze scheiding niet mogelijk. De uitwisseling van informatie ter verstrekking van een Authorization Code leidt is dus niet nodig. In de impliciete autorisatiestroom gaat men ervan uit dat de Resource Owner altijd aanwezig is omdat de Client in een webbrowser draait. Indien nodig is het dus altijd mogelijk om het hele proces te herbeginnen. Het hele proces herbeginnen impliceert echter dat men de autorisatie van de Resource Owner moet vragen telkens men een nieuw Access Token wil verkrijgen, wat voor de Resource Owner zeer snel storend kan worden.

2. Hij fungeert als OpenID Provider, zoals gedefinieerd door de OpenID Connect-specificatie, om toepassingen (binnen en buiten de vertrouwenscirkel) toe te laten de identiteits- en contextattributen van een geauthentiseerde gebruiker te verkrijgen, in voorkomend geval met zijn tijdelijke toestemming.

OpenID Connect is een identificatielaag die gebaseerd is op het OAuth 2.0-protocol, die klanten toelaat om de identiteit van een eindgebruiker na te gaan door zich te baseren op de authenticatie die door een autorisatieserver wordt geleverd, door het proces te volgen voor het verkrijgen van eenvoudige informatie van het eindgebruikersprofiel.

OpenID Connect definieert twee nieuwe concepten voor authenticatie:

• ID Token: 

Ten eerste voegt OpenID Connect een ID Token toe aan het Access Token. Dit ID Token laat toe om het authenticatieproces te beschrijven en bevat de gebruikers-ID, het tijdstip van de authenticatie, alsook informatie over de authenticatie zelf.

• UserInfo Endpoint:

In tweede instantie voegt OpenID Connect een Endpoint toe aan de Authorization Server om informatie over de gebruiker te verkrijgen, zoals zijn naam of e-mailadres.

Op het niveau van de OAuth-architectuur worden zo verschillende REST API's geïmplementeerd:

• Authorization Endpoint

Het Authorization Endpoint laat een client-toepassing toe om tijdelijk de toestemming te krijgen van een geauthentiseerde en geautoriseerde gebruiker om toegang te krijgen tot een REST API. Het Authorization Endpoint steunt op de login-webapp (WALI) voor de authenticatie van de gebruiker en op het PDP van UAM om de toegangsregels voor de gevraagde autorisatie te evalueren.

In het geval van OpenID Connect is het Authorization Endpoint ook het punt waarmee de client-toepassing, in de vorm van een ID Token, de identiteits- en contextattributen van de geauthentiseerde gebruiker kan verkrijgen, mits zijn tijdelijke toestemming.

• Token Endpoint

Met het Token Endpoint kan een geauthentiseerde en geautoriseerde client-toepassing een 'Access Token' (en eventueel een 'Refresh Token') verkrijgen om toegang te kunnen krijgen tot een REST API. In het geval van een toepassing die een autorisatie vraagt waar ze recht op heeft (zonder delegatie van een gebruiker), steunt het Token Endpoint op het PDP van UAM om de toegangsregels voor de gevraagde autorisatie te evalueren.

• Introspection Endpoint

Met het Introspection Endpoint kunnen de REST API's en de SOA-infrastructuur de geldigheid van een Access Token verifiëren en de identiteits- en contextattributen van de gebruikers en/of de client-toepassing verkrijgen, alsook de machtigingen die door het Access Token gematerialiseerd worden.

• User Info Endpoint

In het kader van OpenID Connect is het User Info Endpoint het punt waarmee de client-toepassingen die het akkoord van een geauthentiseerde gebruiker hebben gekregen, de identiteits- en contextkattributen van die laatste kunnen verkrijgen.

Doelpubliek

Alle toepassingen en beveiligde services van het portaal van de sociale zekerheid, en feitelijk die die REST-technologieën gebruiken.

De toepassingen en services kunnen betrekking hebben op:

• een burger
• een persoon die voor een onderneming werkt
• een rechtspersoon (onderneming, instelling...)
• een professional

Integratievoorwaarden

Neem contact op met het support-iam team dat je de verschillende te volgen stappen zal uitleggen om je toepassing en/of service te beveiligen.

Documentatie

• Algemene documentatie
• IAM Procedure en Processus

Contact

Contact: ReuseOperational@smals.be