Bij JIDOKA geloven we sterk in open source, maar dit betekent niet dat we niet geloven in commerciële software. Het merendeel van de projecten die we uitvoeren resulteert in software waar eindgebruikers voor moeten betalen, dit is natuurlijk de keuze van de klant. Indien de gebouwde software een differentiator in de markt is, heeft het geen zin om de investering weg te geven.
Langs de andere kant bestaan er voldoende software onderdelen die niet bijdragen aan een concurentieel voordeel. Een probleem waarmee elk bedrijf te maken heeft is authenticatie en autorisatie. Binnen JIDOKA gebruiken we Keycloak als ons GOTO product. Het is een geweldig product dat zich goed integreert binnen vele oplossingen en het ondersteunt de meest voorkomende standaarden.
Bij tal van applicaties hebben we twee verbeteringen vastgesteld ten opzichte van het gangbare gebruik van Keycloak.
De eerste verbetering is de automatische configuratie van Keycloak clients en rollen binnen de applicatie. Wanneer we onze applicatie opstarten in een nieuwe omgeving met een nieuwe Keycloak instantie hoeft deze Keycloak instantie niet apart geconfigureerd te worden. Dit heeft als voordeel dat de rollen voor Keycloak gedefinieerd worden op de plaats waar ze worden gebruikt, in de applicatie. Verder is het niet nodig dat de klant Keycloak beheert. Met weinig setup zijn er geen wijzigingen nodig wanneer nieuwe versies van de applicatie worden uitgerold.
De tweede verbetering is user management vanuit de applicatie. Dit wil zeggen dat de applicatie zelf haar eigen REST-endpoints kan voorzien om gebruikers aan te maken in Keycloak en het beheer van de rollen voor deze gebruikers. Dit heeft als voordeel dat de klant niet hoeft te weten hoe Keycloak werkt en dat je een gebruiksvriendelijke, vereenvoudigde UI kunt aanbieden voor het beheer van gebruikers en gebruikersrollen binnen de applicatie.
Destijds hadden we kunnen kiezen voor een BDUF (Big Design Up Front), (bijvoorbeeld het creëren van een speciale integratie service voor het beheer van de rollen en gebruikers. Change requests zouden binnen kunnen komen via Rabbit/Kafka. Deze oplossing zou tegemoetkomen aan toekomstige toepassingen die via dit integratie patroon worden geïntegreerd). Dit leek echter een beetje overdreven, dus hebben we besloten voor de KISS (Keep It Simple Stupid) aanpak. Het resultaat kan je hier vinden.
Hoe werkt het functioneel?
Het laat je toe om het domein te beheren
Clients
- Het ophalen van clients binnen het domein
- Het aanmaken van clients binnen het domein
- Het toevoegen van client rollen
- Het verwijderen client rollen
Gebruikers
- Het aanmaken van een gebruiker
- Het ophalen van alle gebruikers
- Een gebruiker ophalen met client rollen
- Het toewijzen van een client rol aan een gebruiker
- Het verwijderen van een client rol van een gebruiker
Hoe werkt het technisch?
We moeten een Keycloak admin client opzetten. Deze client heeft de noodzakelijke rechten voor het beheer van je domein. Deze client zal communiceren met de Keycloak API en het zware werk voor ons verrichten. We hoeven enkel deze service te gebruiken dewelke een groot deel van de compliciteit in de omgang met de API abstraheert.
Waarom hebben we dit open source gezet?
Een aantal van onze klanten gebruikt zelf ook Keycloak. Door het open sourcen van deze library, kunnen ze deze library gebruiken zonder dat ze afhankelijk zijn van JIDOKA. Dit betekent ook dat we geen private builds moeten creëren die gehost worden op private repositories. Hierdoor is de distributie van libraries veel eenvoudiger in een open source oplossing dan in een gesloten library. In het verleden hebben we veel bedrijven gezien die geprobeerd hebben om vendor lock-in situaties te creëren met hun eigen private software. Wij bij JIDOKA zijn fans van open communicatie en open oplossingen die goed werken.
