Hvad er Keycloak, og hvordan installeres det trin for trin

I næsten alle moderne apps, du bruger dagligt (e-mail, sociale medier, virksomhedens intranet, kundens dashboards osv.) Bag kulisserne er der et system, der bestemmer, hvem du er, og hvad du har adgang til. Når virksomheder begynder at samle applikationer, tjenester og API'er, bliver manuel administration af brugere, adgangskoder, tilladelser og sessioner en reel hovedpine.

Keycloak dukker op lige i tide til at løse det rodKeycloak er en platform til identitets- og adgangsstyring, der centraliserer godkendelse, autorisation og single sign-on for flere applikationer. I stedet for at hver applikation implementerer sit eget login-, rolle- og adgangskodegendannelsessystem, håndterer Keycloak alt dette, og applikationer stoler simpelthen på det ved hjælp af standarder som OAuth 2.0, OpenID Connect eller SAML 2.0.

Hvad er Keycloak, og hvilken rolle spiller det i IAM-sikkerhed?

Keycloak er en open source IdP (identitetsudbyder)Den er skrevet i Java og vedligeholdt af Red Hat (tidligere JBoss), og er licenseret under Apache 2.0, så den kan frit bruges og tilpasses selv i kommercielle miljøer. Der findes en betalt version på virksomhedsniveau kaldet Red Hat Single Sign-On, men kernefunktionaliteten er den samme.

Denne identitetsserver tilbyder SSO, federation og multitenancyDet giver en bruger mulighed for at logge ind én gang og få adgang til flere applikationer, hvor disse applikationer delegerer godkendelse til Keycloak, og administrationen af ​​brugere, grupper, attributter og tilladelser sker centralt uden at skulle implementere hjulet igen i hvert projekt.

Keycloak skiller sig ud fra andre IAM-løsninger (gratis, open source eller proprietære) baseret på deres modenhed, implementering og kompatibilitet med standardprotokoller. Alligevel vil den rigtige løsning for hver organisation afhænge af dens behov (kommerciel support, SLA, specifikke funktioner, on-premise versus SaaS-implementering osv.).

En af Keycloaks styrker Den kombinerer flere komponenter: OAuth 2.0- og OpenID Connect-baseret godkendelse, SAML 2.0-understøttelse, login på sociale medier (Google, Facebook, GitHub osv.), integration med LDAP og Active Directory, administration via webkonsol, CLI og REST API, samt en fleksibel model af brugere, grupper og roller, der afspejles i de tokens, der udstedes til applikationerne.

Nødvendige fundamenter: OAuth 2.0, OpenID Connect og JWT

For fuldt ud at forstå, hvad Keycloak gør, er det nyttigt at have tre koncepter klare.OAuth 2.0, OpenID Connect (OIDC) og JSON Web Tokens (JWT). Du behøver ikke at blive ekspert, men du skal forstå det generelle koncept, fordi alt drejer sig om dem.

OAuth 2.0 som et autorisationsrammeværk

OAuth 2.0 er et standard API-godkendelsesrammeværkDen bruges af giganter som Google, Facebook, Microsoft, GitHub og LinkedIn, og dens primære funktion er at give en applikation (klient) adgang til en brugers ressourcer i en anden applikation eller API med brugerens udtrykkelige tilladelse uden konstant at dele legitimationsoplysninger.

I stedet for at sende brugernavn og adgangskode i hver anmodningOAuth 2.0 introducerer konceptet med et adgangstoken: et kortlivet adgangstoken, der sendes i HTTP-kald til API'en og valideres af API'en. IdP'en (f.eks. Keycloak) udsteder dette token efter at have verificeret brugerens identitet og samtykke.

Standarden definerer flere autorisationsflows (bevillingstyper) at tilpasse processen til klienttypen: sikre backend-applikationer, browserbaserede SPA'er, apps mobile enheder, begrænsede enheder, maskine-til-maskine-kommunikation osv. Hvert flow markerer, hvad der udveksles i hvert trin (autorisationskoder, tokens, legitimationsoplysninger osv.).

De fire grundlæggende roller i OAuth 2.0 lyd:

• Ressourceejer: normalt den bruger, hvis data du ønsker at konsultere eller ændre.
• Klient: applikationen (web, mobil, IoT, backend…) der ønsker at handle på brugerens vegne.
• ressourceserver: API'en, der eksponerer dataene og validerer adgangstokenserne.
• Autorisationsserver: IdP'en (Keycloak), der autentificerer brugeren og udsteder tokens.

Derudover introducerer OAuth 2.0 konceptet med scopesDisse definerer omfanget af den tilladelse, som brugeren giver applikationen: læse e-mail, poste på et socialt netværk, få adgang til en basisprofil osv. Det udstedte token koder, hvilke tilladelser der rent faktisk er givet til klienten.

OpenID Connect: et identitetslag oven på OAuth 2.0

OpenID Connect (OIDC) tilføjer identitet til OAuth 2.0Mens OAuth omhandler autorisation (hvad en applikation kan gøre), omhandler OIDC standardiseret identifikation af, hvem den autentificerede bruger er, og hvordan man indhenter deres grundlæggende data.

OIDC definerer velkendte slutpunkter og metadata, såsom det opdagelsesdokument, der er offentliggjort på ruten /.well-known/openid-configuration hvor udbyderen angiver godkendelses-URL'er, token, offentlige nøgler, brugeroplysninger osv. Dette gør det muligt at konfigurere applikationer næsten automatisk.

Den leverer også UserInfo-slutpunktet.Dette bruges til at hente oplysninger fra den godkendte bruger (navn, e-mail osv.) ved hjælp af et gyldigt adgangstoken. Det er meget almindeligt i Keycloak-baserede integrationer at læse disse data efter login for at udfylde brugerprofiler i applikationen.

Access_token og JSON Web Tokens (JWT)

I mange moderne implementeringer er access_token et JWT (JSON Web Token). Dette er en standard (RFC 7519) til at repræsentere krav som en digitalt signeret JSON, i tre dele adskilt af punktummer: header, payload og signatur, alle kodet i Base64URL.

Overskriften angiver tekniske oplysninger om tokenet. (signaturalgoritme, tokentype og ofte identifikatoren for den anvendte nøgle, kidNyttelasten indeholder påstande, såsom:

• expudløbsdato.
• IAT: udstedelsestidspunkt.
• iss: udsteder, normalt IdP-URL'en.
• nedenforunik brugeridentifikator.
• aud: målgruppe, som tokenet er rettet mod.
• jti: unik identifikator for tokenet.

Signaturen genereres med en privat eller hemmelig nøgle.Derfor ødelægger enhver ændring af tokenet signaturen og registreres under validering. API'en henter den offentlige nøgle fra IdP'en takket være egenskaben jwks_uri fra opdagelsesdokumentet, som peger på en JSON-fil, der indeholder listen over offentlige nøgler og deres kid.

Keycloak tillader også tilpasning af de udstedte tokensYderligere krav kan tilføjes baseret på brugerattributter, grupper, roller eller endda faste værdier. Dette gøres ved hjælp af mappere konfigureret pr. klient eller pr. klient-scope, hvilket gør det nemt for API'er at modtage præcis de oplysninger, de har brug for.

Keycloak-arkitektur: Realms, brugere, grupper og roller

Keycloak organiserer sin konfiguration i RealmsDisse er som "virtuelle identitetsservere" i en enkelt installation. Andre leverandører kalder noget lignende en lejer eller et bibliotek. Hvert realm har sine egne uafhængige brugere, grupper, klienter, politikker og indstillinger.

Som standard er der et særligt realm kaldet masterDenne konto bør reserveres til globale administrative opgaver, såsom oprettelse og administration af andre realms. Administratorbrugeren kan administrere flere realms fra den samme konsol uden at skulle logge ind med forskellige konti for hver enkelt.

Lokale brugere kan defineres inden for et realmved at tildele dem brugerdefinerede attributter, gruppere dem og relatere dem til roller. Modellen er omhyggeligt designet, så relevante oplysninger i sidste ende afspejles i de tokens, der forbruges af applikationen (roller, grupper, profildata, sikkerhedsflag osv.).

Grupper giver brugerne mulighed for at organisere sig hierarkisk.En gruppe kan have undergrupper (undergrupper), og en bruger arver attributterne og rollerne fra alle de grupper, de tilhører, inklusive deres forældre. Dette giver mulighed for meget fleksible autorisationsmodeller uden at skulle gentage konfigurationer for hver bruger.

Med hensyn til roller er der to hovedniveauer:

• Realm-roller: globaler inden for realmen, bruges meget til tilladelser på tværs af ejendomme.
• Klientroller: specifik for en bestemt applikation, hvilket giver mulighed for fin granularitet for hver tjeneste.

Keycloak understøtter sammensatte rollerDet vil sige roller, der igen inkluderer andre roller. Dette hjælper med at gruppere tilladelser og tildele dem alle på én gang til brugere eller grupper, selvom det er bedst ikke at overbruge det for at undgå at komplicere administrationen eller påvirke ydeevnen.

Installation af Keycloak i udviklingstilstand: Docker, Kubernetes og VM

Sådan opsætter du et laboratoriemiljø med Keycloak Der er flere simple muligheder: Docker-container, implementering på Kubernetes (for eksempel med Minikube) eller klassisk installation på en virtuel maskine med Linux og OpenJDK.

Nøgleskjul i Docker

Den hurtigste måde at starte Keycloak til testning Det involverer at køre en container med det officielle image, eksponere port 8080 og sende administratorbrugernavn og adgangskode gennem miljøvariabler, og opstarte i tilstand start-dev (uden HTTPS og med integreret H2-database):

Med en enkelt Docker-kommando en funktionel server opnås i http://localhost:8080, nok til at rode med administrationskonsollen, oprette realms, brugere, klienter og teste grundlæggende integrationer.

Keycloak i Kubernetes med Minikube

Hvis du allerede arbejder med Kubernetes, kan du nemt implementere Keycloak. Ved hjælp af eksempelmanifesterne fra det officielle repository opretter du en Deployment og en Service, og åbner derefter en tunnel med Minikube for at få adgang til tjenesten fra din maskine, normalt igen på port 8080.

Denne tilgang er ideel til simulering af miljøer tættere på produktion. (med pods, tjenester, ekstern konfiguration osv.) og at eksperimentere med kontrollerede implementeringer, skalering og opgraderinger af Keycloak på K8s-klynger.

Keycloak på Ubuntu med OpenJDK og PostgreSQL (avanceret udviklertilstand)

En anden mulighed er at installere Keycloak på en Ubuntu VM Bruger OpenJDK og en lokal PostgreSQL-database med et selvsigneret certifikat og et brugerdefineret værtsnavn. Selvom det stadig er et testscenarie, nærmer det sig en produktionstopologi.

Typiske trin inkluderer:

• Opdater operativsystemet, og installer Java (f.eks. OpenJDK 11 eller nyere).
• Installer PostgreSQL (ideelt set på en separat server, men i et laboratorium kan det være på den samme maskine).
• Opret en specifik bruger og database til Keycloak, og giv de nødvendige rettigheder.
• Opret en systembruger uden rettigheder (f.eks. keycloak) for at køre tjenesten.
• Download den officielle Keycloak-distribution, pak den ud i /opt/keycloak og justere tilladelser.
• Generer et selvsigneret X.509-certifikat med openssl og indstil det keycloak.conf sammen med PostgreSQL-forbindelsesparametrene og hostname ønskes.
• Definer en enhed systemd For at starte Keycloak i udviklingstilstand ved systemstart skal du angive administratoroplysninger via miljøvariabler.

Når tjenesten er oppe at køreDen tilgås normalt via HTTPS på port 8443 med det konfigurerede værtsnavn. Hvis der bruges et selvsigneret certifikat, skal det have tillid til det i browseren (ved at importere CA'en eller selve certifikatet til maskinens betroede certifikatlager).

Avancerede implementeringer: høj tilgængelighed, PostgreSQL og reverse proxy

Når vi går fra laboratorium til produktionBilledet ændrer sig: du er nødt til at tænke på høj tilgængelighed, robust datapersistens, gyldige certifikater og ofte en reverse proxy, der centraliserer HTTPS-adgang og load balancing.

Et ret almindeligt mønster er at implementere flere Keycloat-noder bag en load balancer (f.eks. Nginx) og ved hjælp af en PostgreSQL-database i HA-tilstand som persistens-backend. Målet er at eliminere single points of failure for både applikations- og datalagene.

I denne type arkitektur følges trin som følger normalt::

• Forbered opdaterede Linux-servere (Debian/Ubuntu) og installer afhængigheder: unzip, wget, openjdk, opensslOsv
• Opret en systembruger keycloak med hjem i /opt/keycloak og uden privilegerede interaktive login-tilladelser.
• Download den ønskede version af Keycloak, udpak den, og tildel ejerskab til den dedikerede bruger.
• Opret en specifik database i PostgreSQL med den relevante bruger og de relevante rettigheder, og juster også skemaejeren og standardtilladelserne for tabeller.
• Generer selvsignerede certifikater (eller brug certifikater fra en intern CA) til Keycloak-noder, og konfigurer HTTPS på applikationsserveren.
• Justere keycloak.conf For at oprette forbindelse til PostgreSQL VIP skal du definere HTTP/HTTPS-porte, certifikater, proxyparametre, værtsnavn, klyngestak (f.eks. UDP) og logniveauer.
• Definer en tjeneste systemd simpelt det støvle Nøglekappe med kc.sh start o kc.sh start --optimizedhåndtering af automatiske genstarter i tilfælde af fejl.

Nginx implementeres normalt oven på publicerings- og load balancing-laget. som en HTTPS reverse proxy, med sit eget TLS-certifikat og en upstream-konfiguration, der peger på Keycloak-noder på dens backend-porte (normalt 8080, hvis TLS afsluttes i Nginx).

For at eliminere enkeltstående fejlpunkter i balancerenDet er almindeligt at konfigurere to Nginx-noder i høj tilgængelighed ved hjælp af Keepalived. Dette værktøj administrerer en flydende virtuel IP (VIP), der annonceres på en af ​​serverne som master, og i tilfælde af fejl skifter til backup-noden, hvilket opretholder servicekontinuitet.

Opsætning af en Realm-, bruger- og applikations- (klient-) registrering

Når vi har Keycloak oppe at køre, er det næste logiske skridt Det indebærer at oprette et realm for vores brugere og applikationer, og derfra definere brugere, grupper, roller og klienter (de applikationer, der vil delegere godkendelse til Keycloak).

Et nyt realm oprettes fra administrationskonsollen. Du skal blot indtaste navnet. Fra det øjeblik har vi et isoleret område med sine egne indstillinger. Blandt de første justeringer er følgende normalt nyttige:

• Konfigurer SMTP til afsendelse af e-mails (e-mailbekræftelse, adgangskodegendannelse, notifikationer).
• Aktivér hvis det ønskes Deklarativ brugerprofil, som giver dig mulighed for deklarativt at definere, hvilke attributter en bruger vil have, hvilke valideringer der gælder, og om de kan redigeres af brugeren.
• Juster loginparametre: tillad eller deaktiver selvregistrering, husk session mellem browsergenstarter, tillad gendannelse af adgangskode osv.

Det er lige så simpelt at oprette en bruger i et realm som at udfylde en formular Du skal bruge et brugernavn, en e-mailadresse, et fornavn og et efternavn. Derefter angiver du din adgangskode (midlertidig eller permanent) fra fanen Loginoplysninger. Derfra kan du tildele grupper, roller og yderligere attributter.

Keycloak tilbyder en dedikeret kontokonsol til slutbrugere.hvor de kan se og ændre deres profildata, ændre deres adgangskode, gennemgå aktive sessioner eller administrere yderligere godkendelsesfaktorer. Det er en meget bekvem måde at delegere noget af den grundlæggende administration af deres konto til brugeren.

Personificering er en anden interessant funktion.En administrator med tilladelse kan "efterligne" en bruger fra konsollen for at reproducere problemer, verificere tilladelser osv. uden at skulle bruge brugerens adgangskode.

For at en applikation kan bruge Keycloak som en IdPDen skal registreres som en klient. I afsnittet Klienter oprettes et nyt klient-ID, typen angives som OpenID Connect (medmindre SAML skal bruges), og de tilladte OAuth 2.0-flows vælges: Standardflow (godkendelseskode), Direkte adgangstilladelser (adgangskode), Implicit, Klientlegitimationsoplysninger (servicekonti), Enhedskode, CIBA osv.

Klientkonfigurationen bestemmer også Hvis klientgodkendelse (klienthemmelighed eller certifikater) er påkrævet, hvilke omdirigerings-URI'er er gyldige, og hvilke weboprindelsessteder er tilladt (meget vigtigt i SPA'er på grund af CORS-politikker). Derfra kan applikationen bruge officielle eller tredjepartsbiblioteker til at delegere godkendelse til Keycloak via OIDC.

Integration med eksterne mapper og andre identitetsudbydere

Keycloak kan fungere som en lokal identitetskilde (brugere, grupper og roller defineret i sin egen database) eller den kan fungere som identitetsmægler for en eller flere eksterne udbydere.

En meget almindelig integration er med Azure Active DirectoryAzure AD gemmer virksomhedsbrugere og -grupper, og Keycloak opretter forbindelse som en OIDC-klient for at downloade identiteter og grupper og knytte dem til lokale brugere og roller. Dette undgår duplikering af identiteter og administrative opgaver på tværs af flere websteder.

Generelt set, at bruge Azure AD som en ekstern IdP følgende gøres:

• Registrer en applikation i Azure AD, hent dens klient-id og opret en klienthemmelighed.
• Konfigurer omdirigerings-URI'erne til Keycloak (OIDC-mæglerens slutpunkt i det tilsvarende realm) i Azure AD.
• Juster de krav, der vil blive udstedt i tokenet i Azure AD-applikationen, for eksempel ved at inkludere brugergrupperne.
• I Keycloak skal du oprette en OpenID Connect Identity Provider, der peger på Azure-slutpunkterne (godkendelse, token, logout, brugerinfo) og konfigurere klient-ID, klienthemmelighed og de ønskede loginparametre.

Når der er opbygget tillid mellem demNår en bruger logger ind via Azure AD, opretter (eller synkroniserer) Keycloak brugeren lokalt og kan knytte Azure-grupper til Keycloak-roller ved hjælp af avancerede knyttere. For eksempel kan gruppen "Udviklere" i Azure oversættes til rollen "Udviklere" i Keycloak, som derefter rulles ud til integrerede applikationer og tjenester (f.eks. Jenkins).

Ud over Azure AD tillader Keycloak identitetsføderation med LDAP, klassisk Active Directory, andre OIDC IdP'er, sociale udbydere (Google, Facebook, GitHub osv.) og mere, så man kan blande flere kilder samtidigt inden for samme domæne.

Yderligere sikkerhed: bots, CAPTCHA og bedste praksis

Selvom Keycloak i høj grad styrker godkendelsessikkerheden (MFA, adgangskodepolitikker, kontospærring, sessionskontrol osv.) er login-, registrerings- og adgangskodegendannelsessider fortsat klare mål for bots og automatiserede angreb.

For at afbøde disse typer truslerDet anbefales at kombinere Keycloak med anti-bot-mekanismer såsom GDPR-kompatible CAPTCHA-løsninger, der skelner mellem menneskelig og automatiseret trafik uden at gå på kompromis med brugeroplevelsen. Disse løsninger er typisk integreret i login- og registreringsformularer og tilføjer et ekstra lag af forsvar mod angreb med legitimationsoplysninger, masseoprettelse af konti eller misbrug af adgangskodegendannelsesflows.

Ud over CAPTCHA omfatter andre gode fremgangsmåder overvåge logs For adgang, opsæt advarsler for unormale stigninger i mislykkede forsøg, gennemgå periodisk udstedte tokens og deres varighed, sørg for, at kun nødvendige slutpunkter eksponeres for omverdenen, og hold Keycloak og dets afhængigheder opdateret med de seneste sikkerhedsrettelser.

Hele dette økosystem af funktionaliteter (SSO, multi-tenancy, integration med eksterne mapper, konfigurerbare tokens, implementeringer med høj tilgængelighed og botbeskyttelse) gør Keycloak til et meget kraftfuldt værktøj til centralisering af godkendelse og autorisation til moderne applikationer, hvilket hjælper virksomheder med at styrke deres sikkerhedsposition uden at ofre brugeroplevelsen eller løbende at genopfinde identitetsstyring.