SSO i mikrotjänstarkitektur. Använder Keycloak. Del 1

I vilken storföretag, och X5 Retail Group är inget undantag, ökar antalet projekt där användarautentisering krävs i takt med utvecklingen. Med tiden blir det nödvändigt med en sömlös övergång för användare mellan olika applikationer, vilket leder till behovet av en enhetlig server för Single-Sign-On (SSO). Men hur ska man gå tillväga när identitetsleverantörer som AD eller andra, utan ytterligare attribuer, redan används i olika projekt? Här kommer systemklassen som kallas "identitetsmäklare" till hjälp. De mest funktionella representanterna är sådana som Keycloak, Gravitee Access management med flera. Användningsscenarierna kan oftast variera: maskininteraktion, användarengagemang med mera. Lösningen bör stödja en flexibel och skalbar funktionalitet som kan förena alla krav i ett, och den lösningen i vårt företag just nu är identitetsmäklaren – Keycloak.

Keycloak är en öppen källkodsprodukt avsedd för identifikation och åtkomstkontroll, och stöds av företaget RedHat. Det är grunden för företagets produkter som använder SSO – RH-SSO.

Grundläggande begrepp

Innan man börjar förstå sig på lösningar och tillvägagångssätt bör man definiera termer och sekvenser av processer:

Identifiering — detta är proceduren för att identifiera subjektet utifrån dess identifierare (enkelt uttryckt, att fastställa namn, login eller nummer).

Autentisering – detta är proceduren för autentisering (användaren verifieras med hjälp av lösenord, brevet verifieras med elektronisk signatur etc.)

Behörighet – detta är tillhandahållandet av åtkomst till någon resurs (till exempel e-post).

Identitetsmäklaren Keycloak

Keycloak — är en lösning för hantering av identitet och åtkomst med öppen källkod, avsedd att användas inom informationssystem där mönster för mikrotjänstarkitektur kan förekomma.

Keycloak erbjuder funktioner som enhetlig inloggning (SSO), identifieringsmäkling och social inloggning, användarfederation, klientadaptrar, administrationskonsol och användarkontrollkonsol.

Grundläggande funktionalitet som stöds i Keycloak:

• Single-Sign On och Single-Sign Out för webbaserade applikationer.
• Stöd för OpenID/OAuth 2.0/SAML.
• Identitetsbrokering – autentisering med externa OpenID Connect eller SAML identitetsleverantörer.
• Social inloggning – stöd för Google, GitHub, Facebook, Twitter för användaridentifiering.
• Användarfederation – synkronisering av användare från LDAP och Active Directory-servrar samt andra identitetsleverantörer.
• Kerberos-brygga – användning av Kerberos-server för automatisk autentisering av användare.
• Admin Console – för central hantering av inställningar och parametrar via webben.
• Konto förvaltningskonsol – för självständig hantering av användarprofiler.
• Anpassning av lösningen baserat på företagets varumärkesstil.
• 2FA autentisering – stöd för TOTP/HOTP med Google Authenticator eller FreeOTP.
• Inloggningsflöden – självregistrering av användare, återställning och återställning av lösenord och mer.
• Sessionhantering – administratörer kan hantera användarsessioner från en och samma punkt.
• Token-mappare – koppling av användarattribut, roller och andra nödvändiga attribut till tokens.
• Flexibel hantering av policys via realm, applikation och användare.
• CORS-stöd – klientadapter har inbyggt stöd för CORS.
• Service Provider Interfaces (SPI) – ett stort antal SPI för att konfigurera olika aspekter av serverns arbete: autentiseringsflöden, identitetsleverantörer, protokollmappning och mycket mer.
• Klientadapter för JavaScript-applikationer, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
• Stöd för arbete med olika applikationer som stöder OpenID Connect Relying Party-bibliotek eller SAML 2.0 Service Provider-bibliotek.
• Möjlighet till utvidgning med hjälp av plugins.

För CI/CD-processer samt automatisering av hanteringsprocesser i Keycloak kan REST API/JAVA API användas. Dokumentation finns tillgänglig elektroniskt:

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

Företagsnivå identitetsleverantörer (On-Premise)

Möjlighet till autentisering av användare via User Federation-tjänster.

Genomgående autentisering kan också användas – om användare autentiseras på arbetsstationer med Kerberos (LDAP eller AD), kan de automatiskt autentiseras på Keycloak utan att behöva ange sitt användarnamn och lösenord igen.

För autentisering och vidare auktorisering av användare kan en relationsdatabas användas, vilket är mest tillämpligt för utvecklingsmiljöer, eftersom det inte kräver långa inställningar och integrationer i de tidiga stadierna av projekten. Som standard används en inbyggd databas i Keycloak för att lagra inställningar och användardata.

Listan över stödda databaser är omfattande och inkluderar: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle och andra. De mest testade hittills är Oracle 12C Release1 RAC och Galera 3.12-klustret för MariaDB 10.1.19.

Identifieringsleverantörer – social inloggning

Det är möjligt att använda inloggning från sociala medier. För att aktivera möjligheten att autentisera användare används administrationskonsolen i Keycloak. Ingen kodändring i applikationerna krävs och denna funktionalitet är tillgänglig 'ur lådan' och kan aktiveras i vilket skede av projektgenomförandet som helst.

För användarautentisering kan OpenID/SAML-identitetsleverantörer användas.

Typiska auktoriseringsscenarier med användning av OAuth2 i Keycloak

Authorization Code Flow – används med serverapplikationer (server-side applications). En av de mest utbredda typerna av auktorisation eftersom den passar bra för serverapplikationer där applikationens källkod och kunddata inte är tillgängliga för utomstående. Processen bygger här på omdirigering (redirection). Applikationen måste kunna interagera med användaragenten (user-agent), såsom en webbläsare – för att ta emot auktoriseringskoder via omdirigering genom användaragenten.

Implicit Flow – används av mobila eller webbapplikationer (applikationer som körs på användarens enhet).

Implicit auktorisation används av mobila och webbapplikationer där kundens integritet inte kan garanteras. Implicit auktorisation använder också omdirigering av användaragenten, där åtkomsttokenen skickas till användaragenten för vidare användning i applikationen. Detta gör token tillgänglig för användaren och andra applikationer på användarens enhet. Med denna typ av auktorisation genomförs ingen autentisering av applikationen, och processen förlitar sig på omdirigerings-URL:en (registrerad tidigare i tjänsten).

Implicit Flow stödjer inte uppfriskningstokens (refresh tokens).

Client Credentials Grant Flow — används när applikationen får tillgång till API:er. Denna typ av auktorisation används vanligtvis för "server-till-server"-interaktioner som ska utföras i bakgrunden utan omedelbar användarinteraktion. Client Credentials Grant Flow gör det möjligt för en webbtjänst (hemlig klient) att använda sina egna referenser istället för att autentisera en användare när den anropar en annan webbtjänst. För högre säkerhet kan den anropande tjänsten använda ett certifikat (istället för en hemlig nyckel) som referens.

OAuth2-specifikationen beskrivs i
RFC-6749
RFC-8252
RFC-6819

JWT-token och dess fördelar

JWT (JSON Web Token) är en öppen standard (https://tools.ietf.org/html/rfc7519), som definierar ett kompakt och självständigt sätt att säkerställa trygg överföring av information mellan parter i form av JSON-objekt.

Enligt standarden består token av tre delar i base-64-format, åtskilda av punkter. Den första delen kallas header och innehåller typ av token och namnet på hash-algoritmen för att skapa digital signatur. Den andra delen lagrar huvudinformationen (användare, attribut, etc.). Den tredje delen är den digitala signaturen.

..
Spara aldrig token i din databas. En giltig token är motsvarande ett lösenord, att lagra token är som att lagra ett lösenord i klartext.
Åtkomsttoken — det är en token som ger dess ägare tillgång till skyddade serverresurser. Den har vanligtvis en kort livslängd och kan innehålla ytterligare information, såsom IP-adressen till den part som begär denna token.

Refresh-token — det är en token som gör det möjligt för kunder att begära nya access-token efter att deras livstid har gått ut. Dessa tokens utfärdas vanligtvis för en lång period.

De viktigaste fördelarna med användning i mikroservicearkitektur:

• Möjlighet att få tillgång till olika applikationer och tjänster genom en engångsautentisering.
• Om det saknas vissa nödvändiga attribut i användarprofiler kan data berikas med information som kan läggas till i nyttolasten, även automatiserat och "i farten".
• Det finns inget behov av att lagra information om aktiva sessioner, serverapplikationen behöver bara verifiera signaturen.
• Mer flexibel åtkomsthantering genom ytterligare attribut i nyttolasten.
• Användningen av signatur för token för både header och nyttolast ökar säkerheten för lösningen som helhet.

JWT-token — struktur

Rubrik — som standard innehåller headern endast typ av token och algoritm som används för kryptering.

Typen av token lagras i nyckeln "typ". Nyckeln "typ" ignoreras i JWT. Om nyckeln "typ" finns, ska dess värde vara JWT för att ange att detta objekt är en JSON Web Token.

Den andra nyckeln "alg" definierar algoritmen som används för att kryptera token. Som standard bör den vara inställd på HS256. Headern kodas i base64.

{ "alg": "HS256", "typ": "JWT"}
Payload (innehåll) — i nyttolasten lagras all information som behöver verifieras. Varje nyckel i nyttolasten kallas "påstående". Till exempel kan man gå in i en applikation endast via inbjudan (sluten promo). När vi vill bjuda in någon att delta skickar vi henne ett e-postmeddelande med en inbjudan. Det är viktigt att verifiera att e-postadressen tillhör personen som accepterar inbjudan, så vi inkluderar denna adress i nyttolasten, därför sparar vi den i nyckeln "e-mail"

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

Nycklar i payload kan vara valfria. Det finns dock flera reserverade:

• iss (Utfärdare) — definierar applikationen från vilken token skickas.
• sub (Ämne) — definierar tokenets ämne.
• aud (Målgrupp) – en array med skiftlägeskänsliga strängar eller URI:er som utgör listan över mottagare av detta token. När mottagande part får JWT med denna nyckel måste de kontrollera att de finns bland mottagarna — annars ska token ignoreras.
• exp (Utgångstid) — anger när tokenet löper ut. JWT-standarden kräver att alla implementationer av token med utgången tid avvisas. Exp-nyckeln ska vara en tidsstämpel i Unix-format.
• nbf (Giltig inte före) — detta är tiden i Unix-format som definierar när tokenet blir giltigt.
• iat (Utfärdat vid) — denna nyckel representerar tiden när tokenet utfärdades och kan användas för att bestämma åldern på JWT. iat-nyckeln ska vara en tidsstämpel i Unix-format.
• Jti (JWT ID) — en sträng som definierar det unika identifieringsnumret för detta token, skiftlägeskänsligt.

Det är viktigt att förstå att nyttolasten inte sänds i krypterad form (även om tokens kan vara inbäddade och därmed kan överföra krypterad data). Därför bör ingen känslig information lagras i den. Precis som i rubriken kodas nyttolasten i base64.
Signatur — när vi har rubriken och nyttolasten kan vi beräkna signaturen.

De base64-kodade: rubriken och nyttolasten tas, de slås samman till en sträng via punkten. Denna sträng och hemliga nyckeln matas in i krypteringsalgoritmen som anges i rubriken (nyckeln „alg”). Nyckeln kan vara vilken sträng som helst. Längre strängar är att föredra, eftersom de tar längre tid att knäcka.

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

Byggande av arkitekturen för ett felresistent Keycloak-kluster

När man använder ett enda kluster för alla projekt ökar kraven på lösningen för SSO. När antalet projekt är litet känns dessa krav inte så starkt för alla projekt, men när antalet användare och integrationer ökar ökar kraven på tillgänglighet och prestanda.

Ökningen av riskerna för att det enhetliga SSO-systemet ska falla ökar kraven på lösningens arkitektur och de metoder som används för att säkra komponenterna, vilket leder till en mycket strikt SLA. Därför har projekt ofta en egen icke-felresistent infrastruktur under utvecklingen eller i de tidiga faserna av implementationen. Allteftersom utvecklingen fortskrider krävs det att möjligheter för vidareutveckling och skalbarhet läggs in. Den mest flexibla lösningen för att bygga en felresistent klusterbildning är att använda containerbaserad virtualisering eller en hybridansats.

För att arbeta i ett Active/Active och Active/Passive-kluster krävs det att datakonsistens säkerställs i den relationsdatabas - båda databasnoderna måste synkront replikeras mellan olika geodistribuerade datacenter.

Det enklaste exemplet på en felresistent installation.

Vilka fördelar ger användningen av ett enhetligt kluster:

• Hög tillgänglighet och prestanda.
• Stöd för driftslägen: Active/Active, Active/Passive.
• Möjlighet till dynamisk skalning – vid användning av containerbaserad virtualisering.
• Möjlighet till centraliserad hantering och övervakning.
• Enhetlig strategi för identifiering/autentisering/bemyndigande av användare i projekten.
• Mer transparent samarbete mellan olika projekt utan användarengagemang.
• Möjlighet att återanvända JWT-token i olika projekt.
• En enda förtroendepunkt.
• Snabbare projektstart med användning av mikrotjänster/containerbaserad virtualisering (inga ytterligare komponenter behöver sättas upp och konfigureras).
• Möjlighet till kommersiellt stöd från leverantören.

Vad man bör tänka på vid planering av klustret

DBMS

Keycloak använder ett databasadministrationssystem för att lagra: realms, clients, users och mer.
Stöder ett brett spektrum av databaslösningar: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak levereras med en egen inbyggd relationsdatabas. Det rekommenderas att använda den för icke-belastade miljöer – som utvecklingsmiljöer.

För att arbeta i ett Active/Active och Active/Passive-kluster krävs datakonsistens i den relationsdatabas och båda noderna i databasklustret replikerar synkront mellan datacenter.

Distributerad cache (Infinspan)

För korrekt drift av klustret krävs ytterligare synkronisering av följande typer av cache med hjälp av JBoss Data Grid:

Autentisering sessioner – används för att spara data vid autentisering av en viss användare. Begärningar från denna cache innehåller vanligtvis endast webbläsaren och Keycloak-servern, men inte applikationen.

Action tokens – används för scenarier där användaren behöver bekräfta en åtgärd asynkront (via e-post). Till exempel, under flödet för glömt lösenord används cachen actionTokens Infinispan för att spåra metadata om relaterade åtgärdsmärken som redan har använts, så att de inte kan återanvändas.

Caching och ogiltigförklaring av beständig data – används för att cacha beständig data för att undvika onödiga frågor mot databasen. När en Keycloak-server uppdaterar data, måste alla andra Keycloak-servrar i alla datacenter vara medvetna om detta.

Arbete – används endast för att skicka meddelanden om ogiltigförklaring mellan klusternoder och datacenter.

Användarsessioner – används för att spara data om användarsessioner som är giltiga under användarens webbläsarsession. Cachen måste hantera HTTP-begärningar från slutkunden och applikationen.

Skydd mot brute force – används för att spåra data om misslyckade inloggningar.

Lastbalansering

Lastbalanseraren är en enda ingångspunkt till Keycloak och måste stödja sticky sessions.

Applikationsservrar

Används för att kontrollera interaktionen mellan komponenterna och kan virtualiseras eller containeriseras med hjälp av befintliga automatiseringsverktyg och dynamisk skalning av infrastrukturautomatisering. De mest förekommande distributionscenarierna är i OpenShift, Kubernetes, Rancher.

Den första delen – den teoretiska – är nu avslutad. I följande artiklar kommer exempel på integrationer med olika identifieringsleverantörer och exempel på inställningar att diskuteras.

Källa: habr.com