I enhver stor virksomhed, og X5 Retail Group er ingen undtagelse, da den udvikler sig, stiger antallet af projekter, der kræver brugerautorisation. Over tid kræves der problemfri overgang af brugere fra en applikation til en anden, og så er der behov for at bruge en enkelt Single-Sing-On (SSO) server. Men hvad med når identitetsudbydere som AD eller andre, der ikke har yderligere attributter, allerede bruges i forskellige projekter. En klasse af systemer kaldet "identifikationsmæglere" vil komme til undsætning. De mest funktionelle er dens repræsentanter, såsom Keycloak, Gravitee Access management osv. Oftest kan use cases være forskellige: maskininteraktion, brugerdeltagelse osv. Løsningen skal understøtte fleksibel og skalerbar funktionalitet, der kan kombinere alle krav i ét, og sådanne løsninger har vores virksomhed nu en indikationsmægler - Keycloak.
Keycloak er et open source-identitets- og adgangskontrolprodukt, der vedligeholdes af RedHat. Det er grundlaget for, at virksomhedens produkter anvender SSO - RH-SSO.
Grundlæggende begreber
Før du begynder at beskæftige dig med løsninger og tilgange, bør du beslutte dig for i vilkår og rækkefølge af processer:
identifikation er en procedure til at genkende et emne ved hans identifikator (med andre ord, dette er definitionen af et navn, login eller nummer).
autentificering - dette er en godkendelsesprocedure (brugeren kontrolleres med en adgangskode, brevet kontrolleres med en elektronisk signatur osv.)
Tilladelse - dette er levering af adgang til en ressource (for eksempel til e-mail).
Identitetsmægler nøglekappe
Nøglekappe er en open source identitets- og adgangsstyringsløsning designet til brug i IS, hvor mikroservicearkitekturmønstre kan bruges.
Keycloak tilbyder funktioner såsom single sign-on (SSO), brokered identitet og socialt login, brugerføderation, klientadaptere, administrationskonsol og kontoadministrationskonsol.
Grundlæggende funktionalitet understøttet af Keycloak:
- Single-Sign On og Single-Sign Out til browserapplikationer.
- Understøttelse af OpenID/OAuth 2.0/SAML.
- Identitetsmæglervirksomhed - autentificering ved hjælp af eksterne OpenID Connect eller SAML identitetsudbydere.
- Socialt login - Google, GitHub, Facebook, Twitter support til brugeridentifikation.
- User Federation - synkronisering af brugere fra LDAP- og Active Directory-servere og andre identitetsudbydere.
- Kerberos-bro - ved hjælp af en Kerberos-server til automatisk brugergodkendelse.
- Admin Console - til samlet styring af indstillinger og løsningsmuligheder via internettet.
- Account Management Console - til selvstyring af brugerprofilen.
- Tilpasning af løsningen baseret på virksomhedens identitet.
- 2FA-godkendelse - TOTP/HOTP-understøttelse ved hjælp af Google Authenticator eller FreeOTP.
- Login flows - bruger selvregistrering, adgangskodegendannelse og nulstilling, og andre er mulige.
- Sessionsstyring - administratorer kan administrere brugersessioner fra et enkelt punkt.
- Token Mappers - binder brugerattributter, roller og andre nødvendige attributter til tokens.
- Fleksibel politikstyring på tværs af verden, applikationer og brugere.
- CORS-understøttelse - Klientadaptere har indbygget CORS-understøttelse.
- Service Provider Interfaces (SPI) - Et stort antal SPI'er, der giver dig mulighed for at tilpasse forskellige aspekter af serveren: autentificeringsflows, identitetsudbydere, protokolmapping og mere.
- Klientadaptere til JavaScript-applikationer, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Support til at arbejde med forskellige applikationer, der understøtter OpenID Connect Relying Party-biblioteket eller SAML 2.0 Service Provider Library.
- Kan udvides ved hjælp af plugins.
Til CI / CD processer, samt automatisering af styringsprocesser i Keycloak, kan REST API / JAVA API anvendes. Dokumentation er tilgængelig elektronisk:
REST-API
Java API
Enterprise Identity Providers (On-Premise)
Mulighed for at godkende brugere gennem User Federation-tjenester.
Pass-through-autentificering kan også bruges - hvis brugere autentificerer mod arbejdsstationer med Kerberos (LDAP eller AD), så kan de automatisk autentificeres til Keycloak uden at skulle indtaste deres brugernavn og adgangskode igen.
Til autentificering og yderligere autorisation af brugere er det muligt at bruge et relationelt DBMS, som er mest anvendeligt til udviklingsmiljøer, da det ikke involverer lange indstillinger og integrationer i de tidlige stadier af projekter. Som standard bruger Keycloak en indbygget DBMS til at gemme indstillinger og brugerdata.
Listen over understøttede DBMS 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.
Identitetsudbydere - socialt login
Det er muligt at bruge et login fra sociale netværk. For at aktivere muligheden for at godkende brugere skal du bruge Keycloack-administrationskonsollen. Ændringer i applikationskoden er ikke påkrævet, og denne funktionalitet er tilgængelig ud af æsken og kan aktiveres på ethvert stadie af projektet.
Det er muligt at bruge OpenID/SAML Identity-udbydere til brugergodkendelse.
Typiske autorisationsscenarier ved hjælp af OAuth2 i Keycloak
Autorisationskodeflow - bruges sammen med applikationer på serversiden. En af de mest almindelige typer autorisationstilladelser, fordi den er velegnet til serverapplikationer, hvor applikationens kildekode og klientdata ikke er tilgængelige for udenforstående. Processen i dette tilfælde er baseret på omdirigering. Applikationen skal være i stand til at interagere med en brugeragent (user-agent), såsom en webbrowser - for at modtage API-autorisationskoder omdirigeret gennem brugeragenten.
implicit flow - bruges af mobil- eller webapplikationer (applikationer, der kører på brugerens enhed).
Den implicitte autorisationstilladelsestype bruges af mobil- og webapplikationer, hvor klientens fortrolighed ikke kan garanteres. Den implicitte tilladelsestype bruger også brugeragentomdirigering, hvorved adgangstokenet videregives til brugeragenten til videre brug i applikationen. Dette gør tokenet tilgængeligt for brugeren og andre applikationer på brugerens enhed. Denne type godkendelsestilladelse godkender ikke applikationens identitet, og selve processen er afhængig af en omdirigerings-URL (tidligere registreret med tjenesten).
Implicit Flow understøtter ikke opdateringstokens for adgangstoken.
Kundeoplysninger Grant Flow — bruges, når applikationen får adgang til API'en. Denne type godkendelsestilladelse bruges typisk til server-til-server-interaktioner, der skal udføres i baggrunden uden øjeblikkelig brugerinteraktion. Tildelingsflowet for klientlegitimationsoplysninger gør det muligt for en webtjeneste (fortrolig klient) at bruge sine egne legitimationsoplysninger i stedet for at efterligne en bruger til at godkende, når den ringer til en anden webtjeneste. For et højere sikkerhedsniveau er det muligt for den opkaldende tjeneste at bruge et certifikat (i stedet for en delt hemmelighed) som legitimationsoplysninger.
OAuth2-specifikationen er beskrevet i
JWT-token og dets fordele
JWT (JSON Web Token) er en åben standard (), der definerer en kompakt og selvstændig måde til sikker overførsel af information mellem parter som et JSON-objekt.
Ifølge standarden består tokenet af tre dele i base-64-format, adskilt af prikker. Den første del kaldes headeren, som indeholder typen af token og navnet på hash-algoritmen til at opnå en digital signatur. Den anden del gemmer de grundlæggende oplysninger (bruger, attributter osv.). Den tredje del er den digitale signatur.
. .
Gem aldrig et token i din DB. Fordi et gyldigt token svarer til en adgangskode, er lagring af token som at gemme adgangskoden i klartekst.
Adgangstoken er et token, der giver sin ejer adgang til sikre serverressourcer. Det har normalt en kort levetid og kan indeholde yderligere oplysninger, såsom IP-adressen på den part, der anmoder om tokenet.
Opdater token er et token, der giver klienter mulighed for at anmode om nye adgangstokens, efter deres levetid er udløbet. Disse tokens udstedes normalt i en lang periode.
De vigtigste fordele ved at bruge i mikroservicearkitektur:
- Mulighed for at få adgang til forskellige applikationer og tjenester gennem engangsgodkendelse.
- I mangel af en række påkrævede attributter i brugerprofilen er det muligt at berige med data, der kan tilføjes til nyttelasten, herunder automatiseret og on-the-fly.
- Der er ingen grund til at gemme oplysninger om aktive sessioner, serverapplikationen skal kun bekræfte signaturen.
- Mere fleksibel adgangskontrol gennem yderligere attributter i nyttelasten.
- Brugen af en token-signatur til headeren og nyttelasten øger sikkerheden for løsningen som helhed.
JWT token - sammensætning
Titel - som standard indeholder overskriften kun den type token og den algoritme, der bruges til kryptering.
Typen af token er gemt i "typ"-tasten. 'Type'-nøglen ignoreres i JWT. Hvis "typ"-nøglen er til stede, skal dens værdi være JWT for at indikere, at dette objekt er et JSON Web Token.
Den anden nøgle "alg" definerer den algoritme, der bruges til at kryptere tokenet. Den skal som standard være indstillet til HS256. Headeren er kodet i base64.
{ "alg": "HS256", "type": "JWT"}
nyttelast (indhold) - nyttelasten gemmer enhver information, der skal kontrolleres. Hver nøgle i nyttelasten er kendt som et "krav". For eksempel kan du kun indtaste ansøgningen ved invitation (lukket promo). Når vi ønsker at invitere nogen til at deltage, sender vi dem et invitationsbrev. Det er vigtigt at tjekke, at e-mailadressen tilhører den person, der accepterer invitationen, så vi vil inkludere denne adresse i nyttelasten, til dette gemmer vi den i "e-mail"-tasten
{ "e-mail": "[e-mail beskyttet]" }
Nøgler i nyttelast kan være vilkårlige. Der er dog et par forbehold:
- iss (udsteder) - Identificerer den applikation, som tokenet sendes fra.
- sub (Subject) - definerer emnet for tokenet.
- aud (Audience) er en række af store og små bogstaver eller URI'er, der er en liste over modtagerne af dette token. Når den modtagende side modtager en JWT med den givne nøgle, skal den tjekke for tilstedeværelsen af sig selv i modtagerne - ellers ignorer tokenet.
- exp (Udløbstid) - Indikerer, hvornår tokenet udløber. JWT-standarden kræver, at alle dens implementeringer afviser udløbne tokens. Exp-nøglen skal være et tidsstempel i unix-format.
- nbf (Not Before) er et tidspunkt i unix-format, der bestemmer det øjeblik, hvor tokenet bliver gyldigt.
- iat (Udstedt på) - Denne nøgle repræsenterer det tidspunkt, tokenet blev udstedt og kan bruges til at bestemme alderen på JWT. iat-nøglen skal være et tidsstempel i unix-format.
- Jti (JWT ID) — en streng, der definerer den unikke identifikator for dette token, der skelner mellem store og små bogstaver.
Det er vigtigt at forstå, at nyttelasten ikke transmitteres i krypteret form (selvom tokens kan indlejres, og det er derefter muligt at transmittere krypterede data). Derfor kan den ikke gemme hemmelige oplysninger. Ligesom headeren er nyttelasten base64-kodet.
underskrift - når vi har en titel og nyttelast, kan vi beregne signaturen.
Base64-kodet: header og nyttelast er taget, de kombineres til en streng gennem en prik. Derefter er denne streng og den hemmelige nøgle input til krypteringsalgoritmen angivet i headeren ("alg"-nøglen). Nøglen kan være en hvilken som helst streng. Længere strenge vil være mest foretrukket, da det vil tage længere tid at samle op.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Opbygning af en Keycloak Failover Cluster Architecture
Ved brug af en enkelt klynge til alle projekter er der øgede krav til en SSO-løsning. Når antallet af projekter er lille, 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.
Forøgelse af risikoen for enkelt SSO-fejl øger kravene til løsningsarkitekturen og de anvendte metoder til redundante komponenter og fører til en meget stram SLA. I denne henseende har projekter oftere under udviklingen eller de tidlige stadier af implementering af løsninger deres egen ikke-fejltolerante infrastruktur. Efterhånden som udviklingen skrider frem, er det påkrævet at fastlægge muligheder for udvikling og skalering. Det er mest fleksibelt at bygge en failover-klynge ved hjælp af containervirtualisering eller en hybrid tilgang.
For at arbejde i Active/Active og Active/Passive cluster modes, er det nødvendigt at sikre datakonsistens i en relationel database - begge databasenoder skal replikeres synkront mellem forskellige geo-distribuerede datacentre.
Det enkleste eksempel på en fejltolerant installation.
Hvad er fordelene ved at bruge en enkelt klynge:
- Høj tilgængelighed og ydeevne.
- Understøttelse af driftstilstande: Aktiv / Aktiv, Aktiv / Passiv.
- Mulighed for dynamisk skalering - ved brug af containervirtualisering.
- Mulighed for centraliseret styring og overvågning.
- Ensartet tilgang til identifikation/godkendelse/godkendelse af brugere i projekter.
- Mere gennemsigtigt samspil mellem forskellige projekter uden brugerinddragelse.
- Evnen til at genbruge JWT-tokenet i forskellige projekter.
- Enkelt tillidspunkt.
- Hurtigere lancering af projekter ved hjælp af mikrotjenester/containervirtualisering (ingen grund til at løfte og konfigurere yderligere komponenter).
- Det er muligt at købe kommerciel support fra leverandøren.
Hvad skal du kigge efter, når du planlægger en klynge
DBMS
Keycloak bruger et databasestyringssystem til at gemme: riger, klienter, brugere osv.
En bred vifte af DBMS understøttes: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak kommer med sin egen indbyggede relationsdatabase. Det anbefales at bruge til ikke-belastede miljøer - såsom udviklingsmiljøer.
For at arbejde i aktiv/aktiv og aktiv/passiv klyngetilstande kræves datakonsistens i en relationsdatabase, og begge databaseklyndeknuder replikeres synkront mellem datacentre.
Distribueret cache (Infinspan)
For at klyngen skal fungere korrekt, kræves yderligere synkronisering af følgende typer caches ved hjælp af JBoss Data Grid:
Autentificeringssessioner - bruges til at gemme data ved godkendelse af en bestemt bruger. Anmodninger fra denne cache omfatter typisk kun browseren og Keycloak-serveren, ikke applikationen.
Handlingstokens bruges til scenarier, hvor brugeren skal bekræfte en handling asynkront (via e-mail). For eksempel, under et glem adgangskode-flow, bruges actionTokens Infinispan-cachen til at holde styr på metadata om tilknyttede handlingstokens, der allerede er blevet brugt, så det ikke kan genbruges.
Caching og invalidering af persistente data - bruges til at cache persistente data for at undgå unødvendige forespørgsler til databasen. Når en Keycloak-server opdaterer dataene, skal alle andre Keycloak-servere i alle datacentre vide om det.
Arbejde - Bruges kun til at sende ugyldige beskeder mellem klynge noder og datacentre.
Brugersessioner - bruges til at gemme data om brugersessioner, der er gyldige i varigheden af brugerens browsersession. Cachen skal behandle HTTP-anmodninger fra slutbrugeren og applikationen.
Brute force-beskyttelse - bruges til at spore data om mislykkede logins.
Lastbalancering
Loadbalanceren er det enkelte indgangspunkt til keycloak og skal understøtte klæbrige sessioner.
Applikationsservere
De bruges til at kontrollere komponenternes interaktion med hinanden og kan virtualiseres eller containeriseres ved hjælp af eksisterende automatiseringsværktøjer og dynamisk skalering af infrastrukturautomatiseringsværktøjer. De mest almindelige implementeringsscenarier i OpenShift, Kubernates, Rancher.
Dette afslutter den første del - den teoretiske. I næste serie af artikler vil eksempler på integrationer med forskellige identitetsudbydere og eksempler på indstillinger blive analyseret.
Kilde: www.habr.com