Auteur: Danny Holstein

Sinds eind vorig jaar maakt de Bee organisatie gebruik van een ander systeem om in te loggen voor een aantal applicaties. Een probleem waar de organisatie tegenaan liep dat was dat iedere applicatie zijn eigen inlogsysteem had. Door middel van Keycloak is dit laatste probleem verholpen en er is nu een centraal inlogsysteem dat in een Docker container wordt uitgevoerd.

Bovendien is het maken van een eigen inlogsysteem lastig en moeilijk om op de juiste manier te doen.  Vooral als het gaat om de beste praktijken wat betreft beveiliging. Hierdoor kan er beter gebruik worden gemaakt van een bestaand systeem.

Keycloak is een IAM (Identity and Access Management) tool met een focus op moderne applicaties en dit geldt voor zowel Frontend- als Backend-applicaties. Keycloak is geschreven in OpenJDK – dat is een opensource-implementatie van Java – en maakt grofweg gebruik van de drie technieken: OAuth 2.0, OpenID Connect en JWT.

Keycloak maakt het mogelijk voor gebruikers om zelf een account te beheren. Verder biedt dit systeem: aanpasbare loginpagina’s, ondersteuning voor sterke authenticatie en ingebouwde mogelijkheden zoals: herstel van wachtwoorden, het updaten van wachtwoorden, het accepteren van algemene voorwaarden en andere zaken die nodig zijn voor een inlogsysteem, zoals Multi-Factor Authentication (MFA).

Het autoriseren – dat wil zeggen of iemand toegang heeft tot een bepaalde bron op een server – gebeurt in Keycloak met OAuth 2.0. Met OAuth 2.0 wordt de toegang tot een bron in de vorm van een access token verleend.

Gebruikers worden daarentegen geauthentiseerd – dit wil zeggen dat de identiteit van een gebruiker wordt vastgesteld. In Keycloak wordt dit gedaan met OpenID Connect. De identiteit van een gebruiker wordt met OpenID Connect in een id token opgeslagen.

De uitwisseling van informatie gebeurt door middel van JSON Web Tokens (afgekort JWT). Hierbij is JSON weer een afkorting voor JavaScript Object Notation en dit uitwisselingsformaat wordt begrepen door vrijwel iedere programmeertaal. De JWT’s bevatten informatie over de issuer (uitgever, dat is Keycloak), verloopdatum, datum van inloggen, rol van de gebruiker, het toegestane bereik, etc.

De werking van Keycloak met bovenstaande 3 industrie-standaarden is als volgt: wanneer een gebruiker inlogt, dan geeft Keycloak aanvankelijk een authorization code terug. Een applicatie wisselt deze code in op Keycloak en krijgt hiervoor de 3 tokens terug: access token, id token en refresh tokens (waarmee een ingelogde gebruiker niet opnieuw hoeft in te loggen).

Voor iedere applicatie kan een Realm worden aangemaakt. Een Realm is volledig geïsoleerd van andere Realms. Het heeft zijn eigen configuratie, zijn eigen set van applicaties en gebruikers. Dankzij geïsoleerde Realms kan een enkele installatie van Keycloak worden gebruikt voor meerdere doelen.

Binnen een Realm zijn er rollen (Realm Roles) en dat is gewoonlijk een rol die een gebruiker binnen een organisatie vertegenwoordigt, zoals Admin, Manager of User. Met de Admin-rol wordt erop gewezen dat deze gebruiker toegang heeft tot iedere bron op een server en alle acties kan ondernemen. Iemand met een User-rol heeft daarentegen gelimiteerde toegang en kan alleen zijn eigen data bekijken en veranderen.

Een groep (Group) vertegenwoordigt in Keycloak een relatie met een specifieke business unit in een organisatie. Op zijn beurt kunnen Realm Roles toegewezen worden aan Groups waardoor personen binnen de Group automatisch een rol wordt verleend op basis van de Group waartoe zij behoren. Het voordeel hiervan is dat er alleen rechten verleend hoeven te worden aan een Group in plaats van aan vele individuele gebruikers.

In Keycloak dienen Groups ervoor om gebruikers/Users te organiseren. Keycloak biedt voor gebruikers de mogelijkheid om accounts inclusief credentials te beheren. Voor onze organisatie is gebruik gemaakt van de identity store: Microsoft Entra Id waardoor gebruikers met een bestaand emailadres van de organisatie kunnen inloggen via Keycloak. Maar er kan ook gebruik worden gemaakt van andere identity stores zoals: LinkedIn, GitHub, Google, etc.

Wanneer Keycloak lokaal wordt uitgevoerd in een Docker container dan is Keycloak standaard geconfigureerd met een simpele op bestanden gebaseerde H2-database. Dit moet niet in een productie-omgeving worden gebruikt, vanwege concurrency (bijvoorbeeld wanneer 2 schrijfprocessen tegelijkertijd plaatsvinden) en het daarmee gepaard gaande risico op datacorruptie.

Het is aanbevolen om een meer robuustere database te gebruiken. Officieel ondersteunt Keycloak PostgreSQL als database, maar het kan ook gebruik maken van: MariaDB, MySQL, Oracle en Microsoft SQL Server. Onze organisatie heeft voor een MSSQL database gekozen omdat deze goedkoper was.

Om Keycloak van een database gebruik te laten maken, is de documentatie erop nageslagen (https://www.keycloak.org/server/db). Het bleek in de praktijk dat er nog een parameter aan de connection-string toegevoegd moest worden (namelijk: sendStringParametersAsUnicode=false). Toen Keycloak verbinding kon maken met de database, werden alle benodigde tabellen succesvol gemaakt.

Een andere waardevolle optie is door de optie KC_HOSTNAME_DEBUG in te schakelen. Hiermee is in één oogopslag te zien of HTTPS is ingeschakeld, welke poorten er worden gebruikt en op welk domein (inclusief protocol) Keycloak actief is. Wanneer Keycloak online wordt uitgevoerd, dan staat dit systeem het standaard niet toe om verbindingen te maken over normale HTTP (waar end-to-end encryptie niet mogelijk is).

Het maken van een eigen theme voor de loginpagina en het account console voor gebruikers is relatief eenvoudig, waarbij gebruik gemaakt kan worden van Bootstrap 5. In het admin console is er via Realm Settings het aangepaste theme in te stellen.

Wanneer er met Keycloak wordt begonnen, dan is het lastig om bepaalde functionaliteit in het admin console te vinden in de UI (vooral in menu’s met triangels zitten bepaalde opties goed verstopt). De UI van het admin console is wel aan verandering onderhevig en wordt geüpdatet met iedere nieuwe versie.