I vilket stort företag som helst, och X5 Retail Group är inget undantag, allt eftersom utvecklingen fortskrider ökar antalet projekt som kräver användarbehörighet. Med tiden krävs en sömlös övergång av användare från en applikation till en annan och då finns det ett behov av att använda en enda Single-Sing-On (SSO)-server. Men vad ska man göra när identitetsleverantörer som AD eller andra som inte har ytterligare attribut redan används i olika projekt. En klass av system som kallas "identitetsmäklare" kommer till undsättning. De mest funktionella är dess representanter, såsom Keycloak, Gravitee Access management etc. Oftast kan användningsscenarier vara olika: maskininteraktion, användarmedverkan etc. Lösningen ska stödja flexibel och skalbar funktionalitet som kan kombinera alla krav i ett, och en sådan lösning Vårt företag har nu en indikationsmäklare – Keycloak.
Keycloak är en identitets- och åtkomstkontrollprodukt med öppen källkod som underhålls av RedHat. Det är grunden för att företagets produkter använder SSO - RH-SSO.
Grundläggande begrepp
Innan du börjar ta itu med lösningar och tillvägagångssätt bör du bestämma dig i termer och sekvens av processer:
identifiering är en procedur för att känna igen en subjekt med sin identifierare (med andra ord, detta är definitionen av ett namn, inloggning eller nummer).
autentisering – detta är en autentiseringsprocedur (användaren verifieras med ett lösenord, brevet verifieras med en elektronisk signatur, etc.)
Bemyndigande – ger tillgång till en resurs (till exempel e-post).
Identitetsmäklare Keycloak
nyckelmantel är en identitets- och åtkomsthanteringslösning med öppen källkod designad för användning i informationssystem där mikrotjänstarkitekturmönster kan användas.
Keycloak erbjuder funktioner som Single Sign-On (SSO), Brokered Identity and Social Login, User Federation, Client Adapters, Admin Console och Account Management Console.
Grundläggande funktionalitet som stöds av Keycloak:
- Single-Sign On och Single-Sign Out för webbläsarapplikationer.
- Stöd för OpenID/OAuth 2.0/SAML.
- Identitetsförmedling - autentisering med hjälp av externa OpenID Connect- eller SAML-identitetsleverantörer.
- Social Login – stöd för Google, GitHub, Facebook, Twitter för användaridentifiering.
- User Federation – synkronisering av användare från LDAP- och Active Directory-servrar och andra identitetsleverantörer.
- Kerberos-brygga - använder en Kerberos-server för automatisk användarautentisering.
- Admin Console - för enhetlig hantering av inställningar och lösningsparametrar via webben.
- Account Management Console – för oberoende hantering av användarprofiler.
- Anpassning av lösningen utifrån företagets företagsidentitet.
- 2FA-autentisering – TOTP/HOTP-stöd med Google Authenticator eller FreeOTP.
- Inloggningsflöden – självregistrering av användare, återställning och återställning av lösenord och annat är möjligt.
- Sessionshantering – administratörer kan hantera användarsessioner från en enda punkt.
- Token Mappers – bindning av användarattribut, roller och andra nödvändiga attribut till tokens.
- Flexibel policyhantering över hela världen, applikationer och användare.
- CORS-stöd – Klientadaptrar har inbyggt CORS-stöd.
- Service Provider Interfaces (SPI) – Ett stort antal SPI:er som låter dig anpassa olika aspekter av servern: autentiseringsflöden, identitetsleverantörer, protokollmappning och mer.
- Klientadaptrar för JavaScript-applikationer, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Stöd för att arbeta med olika applikationer som stöder OpenID Connect Relying Party-biblioteket eller SAML 2.0 Service Provider Library.
- Kan utökas med 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
JAVA API
Företagsidentitetsleverantörer (på plats)
Möjlighet att autentisera användare genom User Federation-tjänster.
Pass-through-autentisering kan också användas - om användare autentiserar mot arbetsstationer med Kerberos (LDAP eller AD), så kan de automatiskt autentiseras till Keycloak utan att behöva ange sitt användarnamn och lösenord igen.
För autentisering och ytterligare auktorisering av användare är det möjligt att använda ett relationellt DBMS, vilket är mest tillämpbart för utvecklingsmiljöer, eftersom det inte innebär långa inställningar och integrationer i tidiga skeden av projekt. Som standard använder Keycloak en inbyggd DBMS för att lagra inställningar och användardata.
Listan över DBMS som stöds ä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-kluster för MariaDB 10.1.19.
Identitetsleverantörer - social inloggning
Det är möjligt att använda en inloggning från sociala nätverk. För att aktivera möjligheten att autentisera användare, använd Keycloack administratörskonsol. Ändringar i applikationskoden krävs inte och denna funktion är tillgänglig direkt och kan aktiveras när som helst i projektet.
Det är möjligt att använda OpenID/SAML-identitetsleverantörer för användarautentisering.
Typiska auktoriseringsscenarier med OAuth2 i Keycloak
Auktoriseringskod Flöde - används med applikationer på serversidan. En av de vanligaste typerna av auktoriseringsbehörighet eftersom den är väl lämpad för serverapplikationer där applikationens källkod och klientdata inte är tillgängliga för utomstående. Processen i detta fall är baserad på omdirigering. Applikationen måste kunna interagera med en användaragent (user-agent), såsom en webbläsare - för att ta emot API-auktoriseringskoder som omdirigeras via användaragenten.
Implicit flöde - används av mobil- eller webbapplikationer (applikationer som körs på användarens enhet).
Den implicita auktoriseringstillståndstypen används av mobil- och webbapplikationer där klienternas integritet inte kan garanteras. Den implicita behörighetstypen använder också omdirigering av användaragent, där åtkomsttoken skickas till användaragenten för senare användning i applikationen. Detta gör token tillgänglig för användaren och andra applikationer på användarens enhet. Denna typ av auktoriseringsbehörighet autentiserar inte applikationens identitet, och själva processen förlitar sig på omdirigeringsadressen (tidigare registrerad med tjänsten).
Implicit Flow stöder inte uppdateringstoken för åtkomsttoken.
Kunduppgifter Grant Flow — används när applikationen får åtkomst till API:et. Denna typ av auktoriseringsbehörighet används vanligtvis för server-till-server-interaktioner som måste utföras i bakgrunden utan omedelbar användarinteraktion. Flödet för beviljande av klientuppgifter tillåter en webbtjänst (konfidentiell klient) att använda sina egna autentiseringsuppgifter istället för att imitera en användare för att autentisera sig när en annan webbtjänst ringer. För en högre säkerhetsnivå är det möjligt för den uppringande tjänsten att använda ett certifikat (istället för en delad hemlighet) som en legitimation.
OAuth2-specifikationen beskrivs i
JWT-token och dess fördelar
JWT (JSON Web Token) är en öppen standard () som definierar ett kompakt och fristående sätt att säkert överföra information mellan parter som ett JSON-objekt.
Enligt standarden består poletten av tre delar i bas-64-format, åtskilda av prickar. Den första delen kallas rubriken, som innehåller typen av token och namnet på hashalgoritmen för att erhålla en digital signatur. Den andra delen lagrar den grundläggande informationen (användare, attribut, etc.). Den tredje delen är den digitala signaturen.
. .
Lagra aldrig en token i din DB. Eftersom en giltig token motsvarar ett lösenord, är att lagra token som att lagra lösenordet i klartext.
Tillgångstoken är en token som ger sin ägare tillgång till säkra serverresurser. Den har vanligtvis en kort livslängd och kan innehålla ytterligare information såsom IP-adressen till den part som begär token.
Uppdatera token är en token som tillåter klienter att begära nya åtkomsttokens efter att deras livstid löper ut. Dessa tokens utfärdas vanligtvis under en lång period.
De främsta fördelarna med att använda i mikrotjänstarkitektur:
- Möjlighet att komma åt olika applikationer och tjänster genom engångsautentisering.
- I avsaknad av ett antal obligatoriska attribut i användarprofilen är det möjligt att berika med data som kan läggas till nyttolasten, inklusive automatiserad och on-the-fly.
- Det finns ingen anledning att lagra information om aktiva sessioner, serverapplikationen behöver bara verifiera signaturen.
- Mer flexibel åtkomstkontroll genom ytterligare attribut i nyttolasten.
- Användningen av en tokensignatur för headern och nyttolasten ökar säkerheten för lösningen som helhet.
JWT-token - komposition
Titel — som standard innehåller rubriken endast tokentypen och algoritmen som används för kryptering.
Typen av token lagras i "typ"-tangenten. 'Typ'-nyckeln ignoreras i JWT. Om "typ"-nyckeln finns måste dess värde vara JWT för att indikera att detta objekt är en JSON Web Token.
Den andra nyckeln "alg" specificerar algoritmen som används för att kryptera token. Som standard ska den vara inställd på HS256. Rubriken är kodad i base64.
{ "alg": "HS256", "type": "JWT"}
Nyttolast (innehåll) - nyttolasten lagrar all information som behöver kontrolleras. Varje nyckel i nyttolasten är känd som ett "krav". Till exempel kan du endast gå in i ansökan genom inbjudan (stängd kampanj). När vi vill bjuda in någon att delta skickar vi dem ett inbjudningsmail. Det är viktigt att verifiera att e-postadressen tillhör personen som accepterar inbjudan, så vi tar med den här adressen i nyttolasten genom att lagra den i "e-post"-nyckeln.
{ "e-post": "[e-postskyddad]"}
Nycklar i nyttolasten kan vara godtyckliga. Det finns dock några reserverade:
- iss (Utfärdare) - bestämmer från vilken applikation token skickas.
- sub (Ämne) - definierar ämnet för token.
- aud (Målgrupp) är en rad skiftlägeskänsliga strängar eller URI:er som är en lista över mottagarna av denna token. När den mottagande sidan tar emot en JWT med den givna nyckeln måste den kontrollera om det finns sig själv i mottagarna - annars ignorera token.
- exp (Utgångstid) - Indikerar när tokenet går ut. JWT-standarden kräver att alla implementeringar avvisar utgångna tokens. Exp-nyckeln måste vara en tidsstämpel i unix-format.
- nbf (Not Before) är en tid i unix-format som bestämmer när token blir giltig.
- iat (Issued At) - Den här nyckeln representerar tiden då token utfärdades och kan användas för att bestämma åldern på JWT. iat-nyckeln måste vara en tidsstämpel i unix-format.
- Jti (JWT ID) är en sträng som definierar en unik skiftlägeskänslig identifierare för denna token.
Det är viktigt att förstå att nyttolasten inte överförs krypterad (även om tokens kan kapslas och då är det möjligt att överföra krypterad data). Därför kan du inte lagra någon hemlig information i den. Liksom rubriken är nyttolasten base64-kodad.
namnteckning – när vi har en titel och nyttolast kan vi räkna ut signaturen.
Base64-kodad: header och nyttolast tas, de kombineras till en sträng genom en punkt. Sedan matas denna sträng och den hemliga nyckeln till krypteringsalgoritmen som anges i rubriken ("alg"-nyckeln). Nyckeln kan vara vilken sträng som helst. Längre strängar är mest att föredra eftersom det tar längre tid att plocka upp.
{"alg":"RSA1_5","nyttolast":"A128CBC-HS256"}
Bygga en Keycloak Failover Cluster Architecture
När man använder ett enda kluster för alla projekt ställs ökade krav på en SSO-lösning. När antalet projekt är litet är dessa krav inte så betydande för alla projekt, men eftersom antalet användare och integrationer ökar ökar kraven på tillgänglighet och prestanda.
Ökande risker för fel på en enskild SSO ökar kraven på lösningsarkitekturen och de metoder som används för redundans av komponenter och leder till en mycket strikt SLA. I detta avseende, oftare under utvecklingen eller tidiga skeden av implementering av lösningar, har projekt sin egen icke-feltoleranta infrastruktur. Allt eftersom utvecklingen fortskrider är det nödvändigt att bygga in möjligheter till utveckling och skalning. Det mest flexibla sättet att bygga ett failover-kluster är att använda containervirtualisering eller en hybridmetod.
För att arbeta i klusterlägena Aktiv/Aktiv och Aktiv/Passiv krävs det att datakonsistensen säkerställs i en relationsdatabas - båda databasnoderna måste replikeras synkront mellan olika geodistribuerade datacenter.
Det enklaste exemplet på en feltålig installation.
Vilka är fördelarna med att använda ett enda kluster:
- Hög tillgänglighet och prestanda.
- Stöd för driftlägen: Aktiv/Aktiv, Aktiv/Passiv.
- Möjlighet att dynamiskt skala - vid användning av containervirtualisering.
- Möjlighet till centraliserad ledning och övervakning.
- En enhetlig metod för att identifiera/autentisera/auktorisera användare i projekt.
- Mer transparent interaktion mellan olika projekt utan användarinblandning.
- Möjligheten att återanvända JWT-token i olika projekt.
- Enskild förtroendepunkt.
- Snabbare lansering av projekt med hjälp av mikrotjänster/containervirtualisering (inget behov av att installera och konfigurera ytterligare komponenter).
- Det är möjligt att köpa kommersiell support från leverantören.
Vad du ska titta efter när du planerar ett kluster
DBMS
Keycloak använder ett databashanteringssystem för att lagra: världar, klienter, användare, etc.
Ett brett utbud av DBMS:er stöds: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak kommer med en egen inbyggd relationsdatabas. Rekommenderas för användning i lätta miljöer, såsom utvecklingsmiljöer.
För att arbeta i aktiva/aktiva och aktiva/passiva klusterlägen krävs datakonsistens i en relationsdatabas, och båda databasklusternoderna replikeras synkront mellan datacenter.
Distribuerad cache (Infinspan)
För att klustret ska fungera korrekt krävs ytterligare synkronisering av följande typer av cachar med JBoss Data Grid:
Autentiseringssessioner - används för att spara data vid autentisering av en specifik användare. Förfrågningar från denna cache inkluderar vanligtvis bara webbläsaren och Keycloak-servern, inte applikationen.
Åtgärdstokens används för scenarier där användaren behöver bekräfta en åtgärd asynkront (via e-post). Till exempel, under ett glömt lösenordsflöde, används actionTokens Infinispan-cache för att hålla reda på metadata om associerade åtgärdstokens som redan har använts, så den kan inte återanvändas.
Cachning och ogiltigförklaring av beständiga data - används för att cachelagra beständiga data för att undvika onödiga frågor till databasen. När någon Keycloak-server uppdaterar data måste alla andra Keycloak-servrar i alla datacenter veta om det.
Arbete - Används endast för att skicka ogiltiga meddelanden mellan klusternoder och datacenter.
Användarsessioner - används för att lagra användarsessionsdata som är giltiga under användarens webbläsarsession. Cachen måste hantera HTTP-förfrågningar från slutanvändaren och applikationen.
Brute force-skydd - används för att spåra data om misslyckade inloggningar.
Lastbalansering
Lastbalanseraren är den enda ingången till keycloak och måste stödja klibbiga sessioner.
Applikationsservrar
De används för att styra komponenternas interaktion med varandra och kan virtualiseras eller containeriseras med hjälp av befintliga automationsverktyg och dynamisk skalning av infrastrukturautomationsverktyg. De vanligaste distributionsscenarierna i OpenShift, Kubernates, Rancher.
Detta avslutar den första delen – den teoretiska. I följande artikelserie kommer exempel på integrationer med olika identifieringsleverantörer och exempel på inställningar att diskuteras.
Källa: will.com