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.
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.
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.
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:
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.
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:
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.
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.
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.
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.
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:
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.
Contact : ReuseOperational@smals.be
Heb je een herbruikbare component die voor een andere instelling van pas kan komen?
Ideeën uitwisselen over hergebruik? Dat kan op onze evenementen. We organiseren er regelmatig!
Schrijf je in op onze nieuwsbrief en blijf op de hoogte van de laatste ontwikkelingen in hergebruik.
Is jouw project een succes geworden dankzij een hergebruikte component?