Azure AD B2C lukker i 2030

De fleste organisationer tænker ikke over identitetslaget, før noget tvinger dem til det. En Azure B2C-platform der skal udfases inden 2030.

Skrevet af: Christian Mørup
Managing Architect

En compliance-revision der spørger ind til dataplacering. En multi-cloud-strategi der støder på en managed CIAM bundet til én cloud. Eller et login-flow der ikke kan bygges i Entra External ID's user flows.

I de situationer bliver Keycloak ofte vurderet som alternativ. Denne artikel er en gennemgang af, hvornår det giver mening - og hvornår en managed CIAM stadig er det rigtige svar.

Keycloak er en open source-platform for identitet og adgangsstyring med over et årti i enterprise-produktion. Den fungerer som upstream for Red Hat Build of Keycloak (tidligere Red Hat SSO), og blev i 2023 doneret til CNCF som incubating project under en uafhængig governance-model.

Den passer ikke til alle organisationer.

Platformen kort fortalt

Keycloak er en standardbaseret IAM-platform, der dækker både customer-vendte (CIAM) og medarbejdervendte scenarier. Den kan bruges på to måder, der ofte kombineres. Som identity broker står Keycloak foran eksisterende identity providers - MitID, Microsoft Entra ID, Google, sociale logins, LDAP/AD og andre OIDC/SAML-providere - og giver jeres applikationer ét konsistent lag at integrere mod, uanset hvilken IdP der står bag.

Som authentication-platform i egen ret ejer Keycloak selv brugerne og leverer registrering, login-flows, MFA, password-reset, account linking og session-håndtering ud af boksen. I begge tilfælde fungerer den som OAuth 2.0/OIDC-compliant autorisationsserver med token-issuance, claims-mapping og fine-grained policies.

Forskellen til managed CIAM mærkes tydeligst i flow-engine'en: authentication- og registration-flows er programmerbare, så custom steps, integration mod eksterne services og betingede regler kan ligge i platformen frem for at sprede sig ud i hver enkelt applikation.

Protokolfladen er standard: OpenID Connect, OAuth 2.0, SAML 2.0.

Fire scenarier hvor Keycloak er det rigtige valg

1

Konsolidering af mange identity providers bag ét lag

Mange organisationer har sammensatte identitetsbehov: MitID for borgere, Entra ID for medarbejdere, sociale logins for kunder, måske en partner-IdP via SAML.
Hvis hver applikation integrerer direkte mod hver IdP, vokser kompleksiteten lineært med antallet af kombinationer. I stedet bør Keycloak placeres som central broker: applikationerne integrerer kun mod platformen, og når en ny IdP skal tilføjes - eller en gammel udskiftes - sker det ét sted uden at applikationerne mærker det.
Det er en arkitektur, der bliver mere værdifuld, jo flere IdP'er og applikationer der er i porteføljen.
2

Compliance og dataejerskab

I sektorer hvor regulering kræver dokumenteret kontrol over hvor identitetsdata befinder sig, hvem der har adgang, og hvordan flows er konfigureret, kan Keycloak placeres præcis, hvor compliance-rammen kræver det - on-prem, i jeres egen cloud-tenant eller i en specifik region.
I ejer både kode, drift og datastier selv, hvilket gør det enklere at dokumentere reel kontrol frem for at arve leverandørens compliance-posture.
3

Login-flows som managed CIAM ikke kan levere

Login-flows kan blive komplekse: betingede registreringstrin, custom claims-transformationer, opslag i interne legacy-systemer som del af login'et, orkestrering mod flere eksterne services i samme flow. Den slags støder hurtigt på grænserne for, hvad managed CIAM kan opnå. Mange Azure AD B2C-kunder har bygget netop denne logik i custom policies og står nu med et problem, fordi Entra External IDs user flows ikke understøtter den.
Keycloak håndterer komplekse flows primært gennem konfiguration. Authentication- og registration-flows bygges op af genbrugelige steps og betingelser i admin-UI'et, og det dækker langt de fleste praktiske scenarier. Hvor konfigurationen ikke rækker, kan flows udvides med custom code via Keycloaks SPI'er, men det er undtagelsen.
4

Cloud-agnostisk og multi-cloud arkitektur

Strategier der eksplicit søger uafhængighed af én cloud-leverandør, kører ofte ind i identitetslaget som et af de stærkeste lock-in-punkter. Managed CIAM lever per definition i én cloud. Keycloak kører hvor I vil køre det: Kubernetes (AKS, EKS, GKE, OpenShift), containere uden K8s, VM'er eller bare metal - on-prem, i én cloud eller på tværs af flere.

Hvor migreringen ikke er et 1:1-skift

Keycloak er ikke svaret på alle identitetsbehov. Er I fuldt investeret i Microsoft-stakken uden planer om at bevæge jer ud af den, giver Entra External ID typisk en mere sammenhængende drift og enklere integration med resten af jeres Microsoft-platform.

Har I standard login-behov - én applikation, MFA, password-reset, måske social login - og begrænset teknisk kapacitet til at drifte en platform selv eller styre et managed Keycloak-engagement, er en managed CIAM som Entra External ID eller Auth0 enklere at få i drift.

Keycloak er heller ikke et "set-and-forget"-produkt. Det kræver løbende vedligehold, opgraderingsdisciplin og en model for incident response - internt eller hos en partner. Uden den kapacitet kommer platformen til at koste mere end den giver.

Hvis identitetslaget ikke er strategisk for jer, vejer driftsansvaret tungere end fleksibiliteten.

Drift: tre modeller

Valget mellem de tre er ikke endeligt - mange starter på managed og bevæger sig mod selvdrift, efterhånden som kompetencen modnes internt.

Open source betyder ikke "selvbyg fra bunden". Der findes tre driftsmodeller, der dækker spektret fra fuld kontrol til managed:

1

Selvhostet community-build

Maksimal fleksibilitet, ingen licensomkostninger, fuldt ansvar for opgraderinger, patching og support. Forudsætter et team med identitetsekspertise eller en partner med samme. Egner sig bedst, hvis I har en stærk platformsorganisation og en eksisterende Kubernetes-praksis.
2

Red Hat Build of Keycloak (RHBK)

Red Hats kommercielle distribution med testede builds, sikkerhedspatches og enterprise-support med SLA. RHBK er inkluderet i Red Hat-abonnementer som Red Hat Runtimes og OpenShift Container Platform, så hvis I allerede er Red Hat-kunder, har I muligvis adgang i forvejen. Egner sig, hvis I vil have community-arkitekturen, men ikke supportrisikoen.
3

Managed Keycloak-hosting

Dedikerede udbydere driver platformen for jer: HA-clustering, patching, monitoring, opgraderinger. I beholder fuld kontrol over konfiguration, flows og data, men slipper for den operationelle byrde. Egner sig, hvis I vil have arkitekturen og kontrollen, men ikke ønsker at bygge driften op selv.

Hvornår skal I sætte gang i det?

Når en man overvejer Keycloak, går samtalen typisk gennem fire spørgsmål:

Strategisk rolle.
Er identitetslaget en kapabilitet I vil eje, eller en infrastrukturkomponent I helst ikke vil bruge tid på?
Kompleksitet i flows.
Har I login-flows eller integrationer, der ligger ud over hvad managed CIAM kan håndtere?
Cloud- og compliance-rammer.
Stiller jeres cloud-strategi eller compliance-krav forhindringer for en managed CIAM
Operationel modenhed.
Har I - eller kan I etablere - kompetencen til at drifte en kritisk platform, enten selv eller via en partner?

Beslutningen ligger i hvilke af de fire spørgsmål, der vejer tungest hos jer.

Næste skridt

Hos Immeo har vi erfaring med identitetsarkitekturer på både managed CIAM-platforme og Keycloak-baserede løsninger. Står I med et identitetsspørgsmål uden et oplagt svar - fx B2C-udfasning, compliance-pres, multi-cloud-strategi eller MitID-integration - tager vi gerne en konkret arkitekturvurdering med jer.

Det er et afgrænset forløb, der leverer en anbefaling som I kan tage videre - uanset om det peger mod Keycloak, en managed platform eller en hybrid.