SBB Keycloak

Solution architect: Erik Cheizoo

Diensten informatie

Het portfoliomanagement vult deze informatie aan.

Doel van dit SBB

Dit Solution Bouwblok beschrijft de inzet van Keycloak als centrale federatieve voorziening binnen IRN IAM. De oplossing geeft invulling aan de ABB Federative Authentication en ondersteunt de transitie van bestaande federatieve oplossingen naar een centrale, gestandaardiseerde federatieve bouwsteen.

De oplossing is bedoeld om:

• Federatieve authenticatie centraal aan te bieden;
• Trustrelaties met interne en externe Identity Providers te beheren;
• Applicaties via standaardprotocollen te laten aansluiten;

De oplossing is nadrukkelijk niet bedoeld als applicatiespecifieke federatieve implementatie per afzonderlijke toepassing, maar als generieke IAM-voorziening waarop applicaties aansluiten. Keycloak wordt binnen dit SBB gepositioneerd als federatieve authenticatiebroker en niet als centrale identity store, IGA-oplossing of applicatie-autorisatievoorziening. Keycloak verzorgt federatie, protocolafhandeling, tokenuitgifte, claimtransformatie, sessie-afhandeling en aansluiting van applicaties op interne en externe Identity Providers. Lifecyclebeheer, rollenbeheer, autorisatiebeheer en provisioning vallen buiten Keycloak en worden ingevuld door daarvoor bedoelde IAM-bouwstenen, waaronder MidPoint en onderliggende bronsystemen.

Kosten en verantwoordelijkheden

Aan elk SBB zitten kosten aan verbonden. Dit gaat hierover. Daarnaast moet er worden uitgelegd aan de afnemer welke taken zelf moeten worden gedaan en welke taken bij de beherende partij liggen.

Kosten

Additionele specificaties:

Mogelijk zijn er nog bijzondere regels, neem deze op.

Bijvoorbeeld: kosten worden 2 jaar doorbelast en daarna door de beherende partij opgenomen in de instandhouding of bijvoorbeeld dat kosten per maand worden doorbelast

Verantwoordelijkheden

Beherende partij

De beherende partij is verantwoordelijk voor:

• het beheer van het Keycloak-platform als centrale federatieve voorziening;
• het borgen dat Keycloak geen applicatiespecifieke businesslogica of autorisatiebeslissingen bevat.
• beschikbaarheid, lifecycle management en beveiliging van de oplossing;
• configuratie en beheer van generieke federatieve functionaliteiten;
• beheer van trustrelaties met interne en externe Identity Providers;
• standaardisatie van federatieve aansluitpatronen;
• logging, auditing en aansluiting op beheer- en monitoringsvoorzieningen.
• generieke claimtransformatie en protocolmappers conform de centrale claimstandaard;
• het beheren van gestandaardiseerde aansluitpatronen voor OIDC en SAML;
• IdP-routering en Home Realm Discovery-patronen;

Je kan hier verwijzen naar ander bouwblokken die onderliggend zijn aan deze SBB. Bijvoorbeeld het beheer van hardware in het datacenter. Dan valt dat ook onder deze stap.

Afnemende partij 

De afnemende partij is verantwoordelijk voor:

• het aansluiten van applicaties op de centrale federatieve voorziening conform de vastgestelde standaarden;
• het inrichten en beheren van applicatiespecifieke configuratie aan de applicatiezijde;
• de verwerking van ontvangen tokens, claims of assertions in de applicatie;
• applicatiespecifieke autorisatie en businesslogica;
• tijdig betrekken van IAM bij nieuwe of gewijzigde federatieve aansluitbehoeften.
• pecificeren van applicatiespecifieke autorisatie-eisen;
• afdwingen van applicatiespecifieke autorisatie op basis van ontvangen claims;
• tijdig aanleveren van benodigde clientconfiguratie, redirect URI’s, logout URI’s en gewenste claims;
• het accepteren en correct verwerken van de centrale claimstandaard.

Deze oplossing ontzorgt afnemende partijen in generieke federatieve functionaliteit, maar neemt geen volledige applicatiespecifieke implementatieverantwoordelijkheid over.

Roadmap en Lifecycle

Het productmanagement, dus de productowner of productmanager, vult deze informatie aan.

Roadmap en lifecycle planning zijn twee verschillende dingen. In de lifecycle wordt aangegeven wat de beschikbare versies zijn en tot wanneer deze worden ondersteund en de roadmap toont wanneer nieuwe functionaliteiten worden aangeboden door deze oplossing. Nieuwe functionaliteit is altijd gekoppeld aan een ABB. 

Lifecycle

De lifecycle van dit SBB volgt de gekozen, ondersteunde Keycloak-distributie en de supporttermijnen van de onderliggende platformcomponenten, waaronder containerplatform, databaseplatform, Java/runtime, operator en integratiecomponenten. De exacte distributiekeuze, bijvoorbeeld Red Hat build of community Keycloak, wordt als architectuur-/solutionbesluit vastgelegd en bepaalt het formele patch-, support- en upgradebeleid.

Roadmap

Plan voor 2026202x

• Functionaliteiten die worden toegevoegd

  De oplossing is gericht op consolidatie van bestaande federatieve functionaliteiten uit ADFS en PingAM.

Architectuur

Architectuur vult deze informatie aan, dit is de taak van de solution architect.Keycloak wordt binnen deze oplossing ingezet als centrale federatieve bouwsteen voor het applicatielandschap. Het SBB geeft invulling aan de ABB Federative Authentication door federatieve authenticatie centraal aan te bieden als gedeelde IAM-capability. De oplossing ondersteunt standaardisatie op federatieprotocollen zoals OpenID Connect en SAML 2.0 en maakt het mogelijk om applicaties op een uniforme wijze aan te sluiten. Daarnaast ondersteunt de oplossing trustrelaties met interne en externe Identity Providers, waaronder publieke en interbestuurlijke partijen. 

Uitgangspunt is een centrale, generieke voorziening en niet een model waarbij per applicatie afzonderlijke Keycloak-instanties als standaard worden ingericht. Afwijkingen op dit uitgangspunt zijn alleen toegestaan indien daar een expliciet architectuurbesluit aan ten grondslag ligt, bijvoorbeeld vanwege eisen op het gebied van isolatie, wet- en regelgeving of zwaarwegende technische randvoorwaarden.

Voor aangesloten Identity Providers geldt dat zij een stabiele identifier en de minimaal benodigde attributen moeten leveren. Keycloak transformeert bronattributen naar de centrale claimstandaard. De inhoudelijke juistheid, lifecycle en governance van identiteiten en autorisaties worden niet door Keycloak bepaald, maar door de daarvoor verantwoordelijke bronsystemen en IAM-bouwstenen.

Het voorkeursmodel is een centrale, generieke Keycloak-voorziening. Afzonderlijke realms of instances worden alleen toegepast wanneer daar aantoonbare redenen voor zijn, zoals beheerisolatie, afwijkende beschikbaarheidseisen, data-isolatie, wettelijke vereisten, piekbelastingisolatie of sterk afwijkende branding/UX. De keuze voor shared, realm- of instance-separatie wordt per implementatie vastgelegd in het HLD en, indien besluitwaardig, in de decision log.

Afhankelijkheden

Geef aan welke technische afhankelijkheden er zijn voor deze SBB. Dit is enkel een lijst met links naar andere SBBs met een beschrijving wat de afhankelijkheid is. Dit hoeft maar 1 laag diep, dus een directe afhankelijkheid. Door gebruik te maken van links ontstaat er vanzelf een ketenoverzicht.

Presentatie positionering van dit SBB binnen de IAM doelarchitectuur:

Deze presentatie licht toe hoe dit SBB invulling geeft aan de IAM-doelarchitectuur en de ABB Federative Authentication, en welk sturend beeld dit geeft voor projecten en afnemers.

• Titel Presentatie: Keycloak als centrale federatieve voorziening binnen IAM
• Doelgroep: Product Owner, projecten, afnemers, architecten, engineers
• Status: Toelichtend document bij dit SBB

Technische architectuur

De technische inrichting van dit SBB gaat uit van een centraal Keycloak-platform op een ondersteund containerplatform. De oplossing wordt geautomatiseerd uitgerold en beheerd via een GitOps-werkwijze en omvat in de basis:

• Een centraal Keycloak-platform;
• Integratie met een ondersteund databaseplatform;
• Ontsluiting via ingress/load balancing;
• Aansluiting op interne en externe Identity Providers;
• Cientregistraties voor aangesloten applicaties.

De technische architectuur gaat uit van GitOps als beheerstandaard. Deployment en configuratie worden waar mogelijk als code beheerd. GitOps is het voorkeursmechanisme voor wijzigingen in platform- en Keycloak-configuratie. Secrets, signing keys en client secrets worden niet hardcoded vastgelegd, maar beheerd via een daarvoor aangewezen secret management voorziening.

Voor IdP-routering ondersteunt dit SBB een gelaagd patroon: routering op een vooraf bekend attribuut, aanvullende routering op domein/UPN-suffix waar toepasbaar, en een WAYF-scherm uitsluitend als fallback. De exacte inrichting hiervan wordt per implementatie uitgewerkt in het HLD/LLD.

De oplossing moet authenticatie-events, beheerwijzigingen, foutmeldingen en beschikbaarheidsinformatie vastleggen en ontsluiten naar centrale logging- en monitoringvoorzieningen. Auditlogging is randvoorwaardelijk voor beheer, compliance en incidentanalyse.

Technische documentatie

Om gedurende de levenscyclus van een bouwsteen te meten of deze blijft voldoen aan de requirements en andere doelstellingen, wordt gebruikgemaakt van een Requirements Traceability Matrix.

Voor iedere implementatie van dit SBB hoort de volgende documentatie up-to-date aanwezig te zijn:

• High Level Design (HLD) op basis van ARC42 template;
• Low Level Design (LLD);
• Installatie Handleiding;
• Beheer Handleiding;
• Recovery- en restoreprocedures;
• Hardening-baseline CIS;
• Patch- en lifecycle-overzicht;
• Logging- en monitoringinrichting;
• Overzicht van trusts, koppelingen en afhankelijkheden;
• Testplan
• Eventueel Infrastructure as Code-documentatie indien van toepassing.

Maak een HLD: