I ethvert stort selskap, og X5 Retail Group er intet unntak, ettersom det utvikler seg, øker antallet prosjekter som krever brukerautorisasjon. Over tid kreves sømløs overgang av brukere fra en applikasjon til en annen, og da er det behov for å bruke en enkelt Single-Sing-On (SSO) server. Men hva med når identitetsleverandører som AD eller andre som ikke har tilleggsattributter allerede brukes i ulike prosjekter. En klasse med systemer kalt "identifikasjonsmeglere" vil komme til unnsetning. De mest funksjonelle er dens representanter, som Keycloak, Gravitee Access management osv. Oftest kan brukstilfeller være forskjellige: maskininteraksjon, brukermedvirkning osv. Løsningen skal støtte fleksibel og skalerbar funksjonalitet som kan kombinere alle krav i ett, og slike løsninger vårt firma har nå en indikasjonsmegler - Keycloak.
Keycloak er et åpen kildekode-identitets- og tilgangskontrollprodukt vedlikeholdt av RedHat. Det er grunnlaget for at selskapets produkter bruker SSO - RH-SSO.
Grunnleggende begreper
Før du begynner å håndtere løsninger og tilnærminger, bør du bestemme deg i termer og rekkefølge av prosesser:
identifikasjon er en prosedyre for å gjenkjenne et subjekt med identifikatoren hans (med andre ord, dette er definisjonen av et navn, pålogging eller nummer).
Autentisering – dette er en autentiseringsprosedyre (brukeren verifiseres ved hjelp av et passord, brevet verifiseres ved hjelp av en elektronisk signatur, etc.)
Autorisasjon – gir tilgang til en ressurs (for eksempel e-post).
Identitetsmegler nøkkelkappe
Nøkkelkappe er en åpen kildekode-løsning for identitets- og tilgangsadministrasjon designet for bruk i IS hvor mikrotjenestearkitekturmønstre kan brukes.
Keycloak tilbyr funksjoner som enkeltpålogging (SSO), meglet identitet og sosial pålogging, brukerføderasjon, klientadaptere, administrasjonskonsoll og kontoadministrasjonskonsoll.
Grunnleggende funksjonalitet støttet av Keycloak:
- Single-Sign On og Single-Sign Out for nettleserapplikasjoner.
- Støtte for OpenID/OAuth 2.0/SAML.
- Identitetsmegling - autentisering ved hjelp av eksterne OpenID Connect- eller SAML-identitetsleverandører.
- Sosial pålogging – Google, GitHub, Facebook, Twitter-støtte for brukeridentifikasjon.
- User Federation - synkronisering av brukere fra LDAP- og Active Directory-servere og andre identitetsleverandører.
- Kerberos-bro - bruker en Kerberos-server for automatisk brukerautentisering.
- Administrasjonskonsoll - for enhetlig administrasjon av innstillinger og løsningsalternativer via nettet.
- Account Management Console - for selvstyring av brukerprofilen.
- Tilpasning av løsningen basert på bedriftens identitet.
- 2FA-autentisering - TOTP/HOTP-støtte ved å bruke Google Authenticator eller FreeOTP.
- Påloggingsflyter - bruker selvregistrering, passordgjenoppretting og tilbakestilling, og andre er mulig.
- Session Management - administratorer kan administrere brukerøkter fra ett enkelt punkt.
- Token Mappers - binder brukerattributter, roller og andre nødvendige attributter til tokens.
- Fleksibel policyadministrasjon på tvers av verden, applikasjoner og brukere.
- CORS-støtte - Klientadaptere har innebygd CORS-støtte.
- Tjenesteleverandørgrensesnitt (SPI) – Et stort antall SPI-er som lar deg tilpasse ulike aspekter av serveren: autentiseringsflyter, identitetsleverandører, protokollkartlegging og mer.
- Klientadaptere for JavaScript-applikasjoner, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Støtte for arbeid med ulike applikasjoner som støtter OpenID Connect Relying Party-biblioteket eller SAML 2.0 Service Provider Library.
- Kan utvides ved hjelp av plugins.
For CI / CD-prosesser, samt automatisering av administrasjonsprosesser i Keycloak, kan REST API / JAVA API brukes. Dokumentasjon er tilgjengelig elektronisk:
REST API
Java API
Enterprise Identity Providers (on-premise)
Evne til å autentisere brukere gjennom User Federation-tjenester.
Pass-through-autentisering kan også brukes - hvis brukere autentiserer mot arbeidsstasjoner med Kerberos (LDAP eller AD), så kan de automatisk autentiseres til Keycloak uten å måtte skrive inn brukernavn og passord på nytt.
For autentisering og videre autorisasjon av brukere er det mulig å bruke en relasjonell DBMS, som er mest anvendelig for utviklingsmiljøer, siden den ikke involverer lange innstillinger og integrasjoner på tidlige stadier av prosjekter. Som standard bruker Keycloak en innebygd DBMS for å lagre innstillinger og brukerdata.
Listen over støttede DBMS-er er omfattende og inkluderer: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle og andre. De mest testede for øyeblikket er Oracle 12C Release1 RAC og Galera 3.12 cluster for MariaDB 10.1.19.
Identitetsleverandører – sosial pålogging
Det er mulig å bruke en pålogging fra sosiale nettverk. For å aktivere muligheten til å autentisere brukere, bruk Keycloack-administrasjonskonsollen. Endringer i applikasjonskoden er ikke nødvendig, og denne funksjonaliteten er tilgjengelig fra esken og kan aktiveres når som helst i prosjektet.
Det er mulig å bruke OpenID/SAML Identity-leverandører for brukerautentisering.
Typiske autorisasjonsscenarier ved bruk av OAuth2 i Keycloak
Autorisasjonskodeflyt - brukes med applikasjoner på serversiden. En av de vanligste typene autorisasjonstillatelser fordi den er godt egnet for applikasjoner på serversiden der applikasjonens kildekode og klientdata ikke er tilgjengelige for andre. Prosessen i dette tilfellet er basert på omdirigering. Applikasjonen må kunne kommunisere med en brukeragent (user-agent), for eksempel en nettleser, for å motta API-autorisasjonskoder videresendt gjennom brukeragenten.
implisitt flyt - brukes av mobil- eller nettapplikasjoner (applikasjoner som kjører på brukerens enhet).
Den implisitte autorisasjonstillatelsestypen brukes av mobil- og nettapplikasjoner der klientkonfidensialitet ikke kan garanteres. Den implisitte tillatelsestypen bruker også brukeragentomdirigering, hvorved tilgangstokenet sendes til brukeragenten for videre bruk i applikasjonen. Dette gjør tokenet tilgjengelig for brukeren og andre applikasjoner på brukerens enhet. Denne typen autorisasjonstillatelse autentiserer ikke applikasjonens identitet, og selve prosessen er avhengig av en omdirigerings-URL (tidligere registrert med tjenesten).
Implicit Flow støtter ikke oppdateringstokener for tilgangstoken.
Kundelegitimasjon Grant Flow – brukes når applikasjonen får tilgang til API. Denne typen autorisasjonstillatelse brukes vanligvis for server-til-server-interaksjoner som må utføres i bakgrunnen uten umiddelbar brukerinteraksjon. Tildelingsflyten for klientlegitimasjon lar en nettjeneste (konfidensiell klient) bruke sin egen legitimasjon i stedet for å etterligne en bruker for å autentisere seg når han ringer en annen nettjeneste. For et høyere sikkerhetsnivå er det mulig for den oppringende tjenesten å bruke et sertifikat (i stedet for en delt hemmelighet) som legitimasjon.
OAuth2-spesifikasjonen er beskrevet i
JWT-token og dens fordeler
JWT (JSON Web Token) er en åpen standard (), som definerer en kompakt og selvstendig måte å sikkert overføre informasjon mellom parter i form av et JSON-objekt.
I følge standarden består tokenet av tre deler i base-64-format, atskilt med prikker. Den første delen kalles overskriften, som inneholder typen token og navnet på hash-algoritmen for å få en digital signatur. Den andre delen lagrer den grunnleggende informasjonen (bruker, attributter, etc.). Den tredje delen er den digitale signaturen.
. .
Oppbevar aldri et token i DB. Fordi et gyldig token tilsvarer et passord, er lagring av token som å lagre passordet i klartekst.
Tilgangstoken er et token som gir eieren tilgang til sikre serverressurser. Den har vanligvis kort levetid og kan inneholde tilleggsinformasjon som IP-adressen til parten som ber om tokenet.
Oppdater token er et token som lar klienter be om nye tilgangstokener etter at levetiden deres har utløpt. Disse tokenene utstedes vanligvis for en lang periode.
De viktigste fordelene ved bruk i mikrotjenestearkitektur:
- Evne til å få tilgang til ulike applikasjoner og tjenester gjennom engangsautentisering.
- I mangel av en rekke nødvendige attributter i brukerprofilen, er det mulig å berike med data som kan legges til nyttelasten, inkludert automatisert og on-the-fly.
- Det er ikke nødvendig å lagre informasjon om aktive økter, serverapplikasjonen trenger bare å bekrefte signaturen.
- Mer fleksibel tilgangskontroll gjennom tilleggsattributter i nyttelasten.
- Bruken av en token-signatur for overskriften og nyttelasten øker sikkerheten til løsningen som helhet.
JWT token - komposisjon
Tittel - som standard inneholder overskriften bare typen token og algoritmen som brukes for kryptering.
Type token er lagret i "typ"-tasten. 'Type'-nøkkelen ignoreres i JWT. Hvis "typ"-nøkkelen er til stede, må verdien være JWT for å indikere at dette objektet er et JSON Web Token.
Den andre nøkkelen "alg" definerer algoritmen som brukes til å kryptere tokenet. Den skal være satt til HS256 som standard. Overskriften er kodet i base64.
{ "alg": "HS256", "type": "JWT"}
nyttelast (innhold) - nyttelasten lagrer all informasjon som må kontrolleres. Hver nøkkel i nyttelasten er kjent som et "krav". For eksempel kan du gå inn i søknaden kun ved invitasjon (lukket promo). Når vi ønsker å invitere noen til å delta, sender vi dem et invitasjonsbrev. Det er viktig å sjekke at e-postadressen tilhører personen som aksepterer invitasjonen, så vi vil inkludere denne adressen i nyttelasten, for dette lagrer vi den i "e-post"-tasten
{ "e-post": "[e-postbeskyttet]"}
Nøkler i nyttelast kan være vilkårlige. Imidlertid er det noen reserverte:
- iss (Utsteder) – Identifiserer applikasjonen som tokenet sendes fra.
- sub (Subject) - definerer emnet for tokenet.
- aud (Audience) er en rekke med store og små bokstaver eller URI-er som er en liste over mottakerne av dette tokenet. Når mottakersiden mottar en JWT med den gitte nøkkelen, må den sjekke for tilstedeværelsen av seg selv i mottakerne - ellers ignorer tokenet.
- exp (Utløpstid) - Indikerer når tokenet utløper. JWT-standarden krever at alle implementeringer avviser utløpte tokens. Exp-nøkkelen må være et tidsstempel i unix-format.
- nbf (Ikke før) er et tidspunkt i unix-format som bestemmer øyeblikket når tokenet blir gyldig.
- iat (Issued At) - Denne nøkkelen representerer tidspunktet tokenet ble utstedt og kan brukes til å bestemme alderen til JWT. iat-nøkkelen må være et tidsstempel i unix-format.
- Jti (JWT ID) - en streng som definerer den unike identifikatoren til dette tokenet, skiller mellom store og små bokstaver.
Det er viktig å forstå at nyttelasten ikke overføres i kryptert form (selv om tokens kan nestes og det er da mulig å overføre krypterte data). Derfor kan den ikke lagre noen hemmelig informasjon. I likhet med overskriften er nyttelasten base64-kodet.
Signatur – når vi har en tittel og nyttelast, kan vi beregne signaturen.
Base64-kodet: header og nyttelast tas, de kombineres til en streng gjennom en prikk. Deretter legges denne strengen og den hemmelige nøkkelen inn til krypteringsalgoritmen spesifisert i overskriften ("alg"-nøkkelen). Nøkkelen kan være hvilken som helst streng. Lengre strenger vil være mest foretrukket, da det vil ta lengre tid å plukke opp.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Bygge en Keycloak Failover Cluster Architecture
Ved bruk av en enkelt klynge for alle prosjekter er det økte krav til en SSO-løsning. Når antallet prosjekter er lite, er ikke disse kravene like merkbare for alle prosjekter, men med en økning i antall brukere og integrasjoner øker kravene til tilgjengelighet og ytelse.
Å øke risikoen for enkelt SSO-feil øker kravene til løsningsarkitekturen og metodene som brukes for redundante komponenter og fører til en svært stram SLA. I denne forbindelse, oftere under utviklingen eller tidlige stadier av implementering av løsninger, har prosjekter sin egen ikke-feiltolerante infrastruktur. Etter hvert som utviklingen skrider frem, kreves det å legge ned muligheter for utvikling og skalering. Det er mest fleksibelt å bygge en failover-klynge ved å bruke containervirtualisering eller en hybrid tilnærming.
For å jobbe i Active/Active og Active/Passive klyngemodusene, er det nødvendig å sikre datakonsistens i en relasjonsdatabase – begge databasenodene må replikeres synkront mellom ulike geo-distribuerte datasentre.
Det enkleste eksempelet på en feiltolerant installasjon.
Hva er fordelene med å bruke en enkelt klynge:
- Høy tilgjengelighet og ytelse.
- Støtte for driftsmoduser: Aktiv / Aktiv, Aktiv / Passiv.
- Evne til dynamisk skalering - ved bruk av containervirtualisering.
- Mulighet for sentralisert styring og overvåking.
- Enhetlig tilnærming for identifikasjon/autentisering/autorisering av brukere i prosjekter.
- Mer transparent samhandling mellom ulike prosjekter uten brukerinvolvering.
- Muligheten til å gjenbruke JWT-tokenet i ulike prosjekter.
- Enkelt tillitspunkt.
- Raskere lansering av prosjekter ved bruk av mikrotjenester/containervirtualisering (ingen grunn til å løfte og konfigurere tilleggskomponenter).
- Det er mulig å kjøpe kommersiell støtte fra leverandøren.
Hva du skal se etter når du planlegger en klynge
DBMS
Keycloak bruker et databasestyringssystem for å lagre: riker, klienter, brukere, etc.
Et bredt spekter av DBMS støttes: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak kommer med sin egen innebygde relasjonsdatabase. Det anbefales å bruke for ikke-lastede miljøer - som utviklingsmiljøer.
For å jobbe i aktiv/aktiv og aktiv/passiv klyngemodus, kreves datakonsistens i en relasjonsdatabase, og begge databaseklyngenodene replikeres synkront mellom datasentre.
Distribuert cache (Infinspan)
For at klyngen skal fungere riktig, kreves ytterligere synkronisering av følgende typer cacher ved å bruke JBoss Data Grid:
Autentiseringsøkter – brukes til å lagre data ved autentisering av en spesifikk bruker. Forespørsler fra denne hurtigbufferen inkluderer vanligvis bare nettleseren og Keycloak-serveren, ikke applikasjonen.
Handlingstokens brukes for scenarier der brukeren må bekrefte en handling asynkront (via e-post). For eksempel, under en glem passordflyt, brukes actionTokens Infinispan-cachen til å holde styr på metadata om tilknyttede handlingstokener som allerede er brukt, så den kan ikke gjenbrukes.
Bufring og ugyldiggjøring av vedvarende data – brukes til å bufre vedvarende data for å unngå unødvendige spørringer til databasen. Når en Keycloak-server oppdaterer dataene, må alle andre Keycloak-servere i alle datasentre vite om det.
Arbeid – Brukes kun til å sende ugyldige meldinger mellom klyngenoder og datasentre.
Brukerøkter – brukes til å lagre data om brukerøkter som er gyldige for varigheten av brukerens nettleserøkt. Cachen må behandle HTTP-forespørsler fra sluttbrukeren og applikasjonen.
Brute force-beskyttelse – brukes til å spore data om mislykkede pålogginger.
Lastbalansering
Lastbalanseren er det eneste inngangspunktet til keycloak og må støtte klissete økter.
Applikasjonsservere
De brukes til å kontrollere interaksjonen av komponenter med hverandre og kan virtualiseres eller containeriseres ved hjelp av eksisterende automatiseringsverktøy og dynamisk skalering av infrastrukturautomatiseringsverktøy. De vanligste utrullingsscenariene i OpenShift, Kubernates, Rancher.
Dette avslutter den første delen - den teoretiske. I neste serie med artikler vil eksempler på integrasjoner med ulike identitetsleverandører og eksempler på innstillinger bli analysert.
Kilde: www.habr.com