SSO på mikroservice-arkitektur. Vi bruger Keycloak. Del #1

I enhver stor virksomhed, inklusive X5 Retail Group, stiger antallet af projekter, hvor brugerautorisering er nødvendig, i takt med udviklingen. Over tid er der behov for en sømløs overgang for brugerne fra én applikation til en anden, hvilket skaber behovet for en fælles server til Single-Sign-On (SSO). Men hvordan håndterer man det, når identifikationsudbydere såsom AD eller andre, der ikke har yderligere attributter, allerede anvendes i forskellige projekter? Her kommer en klasse af systemer kaldet 'identifikationsbrokers' til undsætning. De mest funktionelle repræsentanter herfor er såsom Keycloak, Gravitee Access management osv. Ofte kan anvendelsesscenarierne være forskellige: maskinel interaktion, brugerdeltagelse osv. Løsningen skal støtte et fleksibelt og skalerbart funktionalitetsniveau, der kan samle alle krav i én løsning, og denne løsning i vores virksomhed er i øjeblikket identifikationsbrokeren – Keycloak.

Keycloak er et open source-produkt designet til identifikation og adgangskontrol, understøttet af RedHat. Det er fundamentet for virksomhedens produkter, der anvender SSO – RH-SSO.

Grundlæggende begreber

Før vi begynder at undersøge løsninger og tilgange, skal vi først definere termerne og sekvensen af processer:

Identifikation — det er en procedure for genkendelse af en enhed baseret på dens identifikator (simplere sagt, det er definitionen af navn, login eller nummer).

Godkendelse – det er en procedure til autentificering (brugeren bliver verificeret med en adgangskode, brev bliver verificeret med en elektronisk signatur osv.)

Godkendelse – det er at give adgang til en ressource (for eksempel til e-mail).

Identifikationsbrokeren Keycloak

Keycloak — det er en open source-løsning til styring af identifikation og adgang, beregnet til brug i informationssystemer, hvor mikroservice-arkitekturmønstre kan anvendes.

Keycloak tilbyder funktioner såsom enkeltlogon (SSO), broker-identifikation og social login, brugerfederation, klientsystemer, administrationskonsol og konto- og managementkonsol.

Den grundlæggende funktionalitet, der understøttes i Keycloak:

• Single-Sign On og Single-Sign Out til browserbaserede applikationer.
• Understøttelse af OpenID/OAuth 2.0/SAML.
• Identitetsbrokering – autentificering via eksterne OpenID Connect eller SAML-identitetsudbydere.
• Social Login – støtte til Google, GitHub, Facebook, Twitter til brugeridentifikation.
• Brugerfederation – synkronisering af brugere fra LDAP- og Active Directory-servere samt andre identitetsudbydere.
• Kerberos-bro – brug af Kerberos-server til automatisk autentificering af brugere.
• Admin Console – til centraliseret styring af indstillinger og parametre via Web.
• Account Management Console – til selvbetjening med brugerprofiler.
• Tilpasning af løsningen baseret på virksomhedens branding.
• 2FA-autentificering – støtte til TOTP/HOTP med Google Authenticator eller FreeOTP.
• Login Flow – brugere kan selvregistreres, genoprette og nulstille deres adgangskoder m.m.
• Session Management – administratorer kan styre brugersessioner fra et centralt sted.
• Token Mappers – binding af brugerattributter, roller og andre nødvendige attributter i tokens.
• Fleksibel politikstyring via realm, applikation og brugere.
• CORS Support – klientadaptere har indbygget CORS-støtte.
• Service Provider Interfaces (SPI) – et stort antal SPI'er, der muliggør opsætning af forskellige aspekter af serverens drift: autentificeringsstrømme, identitetsudbydere, protokolmapping og meget mere.
• Klientadaptere til JavaScript-applikationer, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
• Støtte til arbejde med forskellige applikationer, der understøtter OpenID Connect Relying Party-library eller SAML 2.0 Service Provider Library.
• Mulighed for udvidelse ved hjælp af plugins.

Til CI/CD-processer samt automatisering af administrationsprocesser i Keycloak kan REST API / JAVA API bruges. Dokumentation er tilgængelig elektronisk:

REST API https://www.keycloak.org/docs-api/8.0/rest-api/index.html
JAVA API https://www.keycloak.org/docs-api/8.0/javadocs/index.html

Enterprise-level identitetsudbydere (On-Premise)

Mulighed for autentificering af brugere via User Federation-tjenester.

End-to-end autentificering kan også anvendes – hvis brugere autentificeres på arbejdsstationer med Kerberos (LDAP eller AD), kan de automatisk autentificeres på Keycloak uden at skulle indtaste deres brugernavn og adgangskode igen.

Til autentificering og efterfølgende brugergodkendelse kan der anvendes en relationel database, hvilket er mest anvendeligt i udviklingsmiljøer, da det ikke medfører langvarige indstillinger og integrationer i de tidlige stadier af projekterne. Som standard bruger Keycloak en indbygget database til opbevaring af indstillinger og brugerdata.

Listen over understøttede databaser er omfattende og inkluderer: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle og andre. De mest testede indtil videre er Oracle 12C Release1 RAC og Galera 3.12 cluster til MariaDB 10.1.19.

Identifikationsudbydere — social login

Brug af login fra sociale medier er muligt. For at aktivere muligheden for at autentificere brugere bruges Keycloaks administratorpanel. Der kræves ingen ændringer i applikationernes kode, og denne funktionalitet er tilgængelig "ud af boksen" og kan aktiveres på enhver fase af projektimplementeringen.

For brugergodkendelse kan OpenID/SAML identitetsudbydere anvendes.

Typiske autoriseringsscenarier ved hjælp af OAuth2 i Keycloak

Authorization Code Flow — bruges med serverapplikationer (server-side applications). En af de mest udbredte typer af autorisation, da den passer godt til serverapplikationer, hvor kildekoden og klientdataene ikke er tilgængelige for tredjeparter. Processen er i dette tilfælde bygget op omkring omdirigering (redirection). Applikationen skal være i stand til at interagere med brugeragenten (user-agent), såsom en webbrowser — for at modtage autoriseringskoder via API, der omdirigeres gennem brugeragenten.

Implicit Flow — bruges af mobile eller webapplikationer (applikationer, der kører på brugerens enhed).

Den implicit tilladelsestype anvendes af mobile og webapplikationer, hvor kundens fortrolighed ikke kan garanteres. Denne type tilladelse bruger også omdirigering af brugeragenten, hvor adgangstokenen sendes til brugeragenten for videre brug i applikationen. Dette gør tokenen tilgængelig for brugeren og andre applikationer på brugerens enhed. Med denne tilladelsestype udføres der ikke autentificering af applikationens legitimitet; i stedet er processen afhængig af omdirigerings-URL'en (som tidligere er registreret i tjenesten).

Implicit Flow understøtter ikke opdateringstokens (refresh tokens).

Client Credentials Grant Flow — bruges når en applikation får adgang til API'en. Denne tilladelsestype anvendes normalt til "server-til-server" interaktioner, der skal udføres i baggrunden uden øjeblikkelig brugerinteraktion. Client Credentials Flow tillader en webtjeneste (fortrolig klient) at anvende sine egne legitimationsoplysninger i stedet for at repræsentere brugeren for autentificering ved opkald af en anden webtjeneste. For et højere sikkerhedsniveau kan den kaldende tjeneste bruge et certifikat (i stedet for et delt hemmelighed) som legitimationsoplysninger.

OAuth2 specifikationen er beskrevet i
RFC-6749
RFC-8252
RFC-6819

JWT token og dets fordele

JWT (JSON Web Token) — en åben standard (https://tools.ietf.org/html/rfc7519), der definerer en kompakt og selvstændig metode til sikker overførsel af information mellem parter i form af et JSON-objekt.

I henhold til standarden består tokenen af tre dele i base-64 format, adskilt af punkter. Den første del kaldes header og indeholder type token og navnet på hash-algoritmen til beregning af den digitale signatur. Den anden del gemmer den primære information (bruger, attributter osv.). Tredje del er den digitale signatur.

..
Gem aldrig tokenen i din database. For en gyldig token svarer til et kodeord; at gemme tokenen er det samme som at gemme kodeordet i klar tekst.
Adgangstoken — er et token, der giver ejeren adgang til serverens beskyttede ressourcer. Det har typisk en kort livscyklus og kan indeholde yderligere information, såsom IP-adressen på den part, der anmoder om dette token.

Refresh-token — er et token, der gør det muligt for klienter at anmode om nye access-tokens, når deres levetid er udløbet. Disse tokens gives typisk for en længere periode.

De vigtigste fordele ved at anvende i mikroservicearkitektur:

• Muligheden for at tilgå forskellige applikationer og tjenester gennem én enkelt godkendelse.
• Hvis der mangler en række nødvendige attributter i brugerprofilen, kan data beriges med oplysninger, der kan tilføjes til payloaden, både automatisk og "on the fly".
• Ingen behov for at opbevare oplysninger om aktive sessioner, det serverbaserede applikation skal kun kontrollere signaturen.
• Mere fleksibel adgangsstyring takket være yderligere attributter i payloaden.
• Brugen af signatur på tokenet til headeren og payloaden øger sikkerheden i løsningen generelt.

JWT-token — sammensætning

Overskrift — som standard indeholder headeren kun tokenets type og den algoritme, der anvendes til kryptering.

Tokenets type opbevares i nøglen "typ". Nøglen "typ" ignoreres i JWT. Hvis nøglen "typ" er til stede, skal dens værdi være JWT for at angive, at dette objekt er et JSON Web Token.

Den anden nøgle "alg" bestemmer den algoritme, der anvendes til at kryptere tokenet. Som standard bør den være indstillet til HS256. Headeren kodet i base64.

{ "alg": "HS256", "typ": "JWT"}
Payload (indhold) — i payloaden opbevares enhver information, der skal verificeres. Hver nøgle i payloaden kaldes en "påstand". For eksempel kan man kun logge ind på applikationen ved invitation (lukket promo). Når vi ønsker at invitere nogen til at deltage, sender vi dem en invitation via e-mail. Det er vigtigt at kontrollere, at e-mailadressen tilhører den person, der accepterer invitationen, så vi inkluderer denne adresse i payloaden, ved at gemme den i nøglen "e-mail".

{ "email": "example@x5.ru" }

Nøglerne i payload kan være vilkårlige. Der er dog flere reserverede:

• iss (Issuer) — angiver applikationen, som tokenet sendes fra.
• sub (Emne) — definerer emnet for tokens.
• aud (Målgruppe) – et array af casesensitive strenge eller URI'er, der udgør en liste over modtagere af dette token. Når den modtagende part modtager en JWT med denne nøgle, skal den kontrollere, om den selv er blandt modtagerne — ellers skal token ignoreres.
• exp (Udløbstid) — angiver, hvornår tokenet udløber. JWT-standard kræver, at tokens med udløbet tid afvises i alle implementeringer. Exp-nøglen skal være en tidsstempel i unix-format.
• nbf (Ikke Før) — det er et tidspunkt i unix-format, der definerer, hvornår tokenet bliver gyldigt.
• iat (Udstedt Tidsstempel) — denne nøgle repræsenterer det tidspunkt, hvor tokenet blev udstedt, og kan bruges til at bestemme alderen af JWT. Iat-nøglen skal være et tidsstempel i unix-format.
• Jti (JWT ID) — en streng, der definerer en unik identifikator for dette token med hensyn til store og små bogstaver.

Det er vigtigt at forstå, at nyttelasten ikke overføres i krypteret form (selvom tokens kan være indlejrede og krypterede data kan overføres derinde). Derfor kan man ikke gemme nogen hemmelige oplysninger i den. Ligesom headeren, er nyttelasten kodet i base64.
Signatur — når vi har header og payload, kan vi beregne signaturen.

De base64-kodede header og payload tages og sammenføjes til en streng adskilt af et punktum. Derefter gives denne streng og den hemmelige nøgle som input til den krypteringsalgoritme, der er angivet i headeren (nøgle "alg"). Nøglen kan være enhver streng. Længere strenge vil være at foretrække, da de kræver længere tid at knække.

{"alg":"RSA1_5", "payload":"A128CBC-HS256"}

Opbygning af en failover-arkitektur for Keycloak-klusteret

Når der bruges et enkelt kluster til alle projekter, opstår der øgede krav til SSO-løsningen. Når antallet af projekter ikke er stort, er disse krav ikke så mærkbare for alle projekter, men med en stigning i antallet af brugere og integrationer stiger kravene til tilgængelighed og ydeevne.

Øget risiko for nedetid for den centrale SSO øger kravene til architecture og de metoder, der anvendes til reservesystemer, og fører til meget strenge SLA'er. Som følge heraf har projekter ofte deres egen ikke-fejltolerante infrastruktur i udviklings- eller tidlige implementeringsfaser af løsninger. Efterhånden som udviklingen skrider frem, skal der tænkes på muligheder for udvikling og skalering. Det er mest fleksibelt at bygge et fejltolerant cluster ved brug af container-virtualisering eller en hybrid tilgang.

For at arbejde i Active/Active og Active/Passive cluster-tilstande er det nødvendigt at sikre datakonsistens i den relationelle database — begge databasenoder skal synkroniseres i realtid mellem forskellige geografisk fordelte datacentre.

Det enkleste eksempel på en fejltolerant installation.

Hvilke fordele giver brugen af et enkelt cluster:

• Høj tilgængelighed og ydeevne.
• Understøttelse af driftsformer: Active/Active, Active/Passive.
• Mulighed for dynamisk skalering — ved brug af container-virtualisering.
• Mulighed for centraliseret styring og overvågning.
• En fælles tilgang til identifikation/authentifikation/autorisation af brugere i projekter.
• Mere gennemsigtig interaktion mellem forskellige projekter uden brugerinddragelse.
• Mulighed for genbrug af JWT-token i forskellige projekter.
• En enkelt tillidspunkt.
• Hurtigere opstart af projekter ved at bruge microservices/container-virtualisering (uden behov for at opsætte og konfigurere yderligere komponenter).
• Mulighed for at købe kommerciel support fra leverandøren.

Hvad man skal være opmærksom på ved planlægning af clusteret

DBMS

Keycloak bruger et databasehåndteringssystem til at gemme: realms, clients, users mv.
Et stort udvalg af databasesystemer understøttes: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak leveres med en indbygget relationel database. Det anbefales at bruge den til let belastede miljøer, såsom udviklingsmiljøer.

For at arbejde i Active/Active og Active/Passive cluster-tilstande er det nødvendigt at sikre datakonsistens i den relationelle database, og begge databasenoder er synkront replikerede mellem datacentre.

Distribueret cache (Infinspan)

For the proper operation of the cluster, additional synchronization of the following cache types is required using JBoss Data Grid:

Authentication sessions — used to retain data during the authentication of a specific user. Requests from this cache usually involve only the browser and the Keycloak server, not the application.

Action tokens — are used for scenarios where a user must confirm an action asynchronously (via email). For example, during the forget password flow, the actionTokens cache in Infinispan is used to track metadata about related action tokens that have already been used, so they cannot be reused.

Caching and invalidation of persistent data – is used for caching persistent data to avoid unnecessary database queries. When any Keycloak server updates data, all other Keycloak servers in all data centers must be aware of this.

Work — is used only to send messages about invalidation between cluster nodes and data centers.

User sessions — are used to retain data about user sessions that are valid during the user's browser session. The cache must handle HTTP requests from end users and applications.

Brute force protection — is used to track data about failed login attempts.

Load Balancing

The load balancer serves as the single entry point into Keycloak and must support sticky sessions.

Application servers

Are used to control the interaction between components and can be virtualized or containerized using existing automation tools and dynamic scaling of infrastructure automation tools. The most common deployment scenarios are in OpenShift, Kubernetes, and Rancher.

This concludes the first part — the theoretical one. The following cycles of articles will cover examples of integrations with various identity providers and setup examples.

Kilde: habr.com