Yn elk grut bedriuw, en X5 Retail Group is gjin útsûndering, sa't it ûntwikkelet, nimt it oantal projekten ta dy't autorisaasje fan brûkers nedich binne. Yn 'e rin fan' e tiid is in naadleaze oergong fan brûkers fan de iene applikaasje nei de oare fereaske, en dan is d'r needsaak om ien Single-Sing-On (SSO) tsjinner te brûken. Mar hoe sit it as identiteitsproviders lykas AD of oaren dy't gjin ekstra attributen hawwe al brûkt wurde yn ferskate projekten. In klasse fan systemen neamd "identifikaasjemakelaars" sil ta de rêding komme. De meast funksjonele binne har fertsjintwurdigers, lykas Keycloak, Gravitee Access behear, ensfh Meast faak, gebrûk gefallen kinne wêze oars: masine ynteraksje, brûkers partisipaasje, ensfh De oplossing moat stypje fleksibele en scalable funksjonaliteit dat kin kombinearje alle easken yn ien, en sokke oplossingen ús bedriuw no hat in oantsjutting makelder - Keycloak.
Keycloak is in iepen boarne identiteit en tagongskontrôleprodukt ûnderhâlden troch RedHat. It is de basis foar de produkten fan it bedriuw mei SSO - RH-SSO.
Basisbegripen
Foardat jo begjinne om te gean mei oplossingen en oanpakken, moatte jo beslute yn termen en folchoarder fan prosessen:
Identifikaasje is in proseduere foar it werkennen fan in ûnderwerp troch syn identifier (mei oare wurden, dit is de definysje fan in namme, oanmelding of nûmer).
Ferifikaasje - dit is in autentikaasjeproseduere (de brûker wurdt kontrolearre mei in wachtwurd, de brief wurdt kontrolearre mei in elektroanyske hantekening, ensfh.)
Oanmelde - dit is it jaan fan tagong ta in boarne (bygelyks ta e-post).
Identiteitsmakelaar Keycloak
keycloak is in oplossing foar iepen boarne identiteit en tagongsbehear ûntworpen foar gebrûk yn IS wêr't mikroservicearsjitektuerpatroanen kinne wurde brûkt.
Keycloak biedt funksjes lykas single sign-on (SSO), brokered identiteit en sosjale oanmelding, brûkersfederaasje, kliïntadapters, adminkonsole en akkountbehearkonsole.
Basisfunksjonaliteit stipe troch Keycloak:
- Single-Sign On en Single-Sign Out foar browserapplikaasjes.
- Stipe foar OpenID / OAuth 2.0 / SAML.
- Identiteitsbrokering - autentikaasje mei eksterne OpenID Connect of SAML-identiteitproviders.
- Sosjaal oanmelde - Google, GitHub, Facebook, Twitter-stipe foar brûkersidentifikaasje.
- Brûkersfederaasje - syngronisaasje fan brûkers fan LDAP- en Active Directory-tsjinners en oare identiteitproviders.
- Kerberos-brêge - mei in Kerberos-tsjinner foar automatyske brûkersferifikaasje.
- Admin Console - foar ienriedich behear fan ynstellingen en oplossingsopsjes fia it web.
- Account Management Console - foar selsbehear fan it brûkersprofyl.
- Oanpassing fan de oplossing basearre op de bedriuwsidentiteit fan it bedriuw.
- 2FA-ferifikaasje - TOTP / HOTP-stipe mei Google Authenticator of FreeOTP.
- Login Flows - brûker selsregistraasje, wachtwurd herstel en reset, en oaren binne mooglik.
- Sesjebehear - behearders kinne brûkerssesjes beheare fanút ien punt.
- Token Mappers - binende brûkersattributen, rollen en oare fereaske attributen oan tokens.
- Fleksibel beliedsbehear oer ryk, applikaasje en brûkers.
- CORS-stipe - Client-adapters hawwe ynboude CORS-stipe.
- Service Provider Interfaces (SPI) - In grut oantal SPI's wêrmei jo ferskate aspekten fan 'e tsjinner kinne oanpasse: autentikaasjestreamen, identiteitproviders, protokolmapping, en mear.
- Kliïntadapters foar JavaScript-applikaasjes, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Stipe foar wurkjen mei ferskate applikaasjes dy't de OpenID Connect Relying Party-biblioteek as SAML 2.0 Service Provider Library stypje.
- Wreidzjen mei plugins.
Foar CI / CD-prosessen, lykas automatisearring fan behearprosessen yn Keycloak, kin de REST API / JAVA API brûkt wurde. Dokumintaasje is elektroanysk beskikber:
REST API
Java API
Enterprise Identity Providers (on-premise)
Mooglikheid om brûkers te ferifiearjen fia User Federation-tsjinsten.
Pass-through-autentikaasje kin ek brûkt wurde - as brûkers ferifiearje op wurkstasjons mei Kerberos (LDAP of AD), dan kinne se automatysk wurde authentisearre nei Keycloak sûnder har brûkersnamme en wachtwurd nochris yn te fieren.
Foar autentikaasje en fierdere autorisaasje fan brûkers is it mooglik om in relasjonele DBMS te brûken, dy't it meast fan tapassing is foar ûntwikkelingsomjouwings, om't it gjin lange ynstellings en yntegraasjes yn 'e iere stadia fan projekten omfettet. Standert brûkt Keycloak in ynboude DBMS om ynstellings en brûkersgegevens op te slaan.
De list mei stipe DBMS is wiidweidich en omfettet: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle en oaren. De meast hifke oant no binne Oracle 12C Release1 RAC en Galera 3.12-kluster foar MariaDB 10.1.19.
Identiteitsproviders - sosjale oanmelding
It is mooglik om in oanmelding te brûken fan sosjale netwurken. Om de mooglikheid te aktivearjen om brûkers te ferifiearjen, brûk de Keycloack admin konsole. Feroarings yn 'e applikaasjekoade binne net fereaske en dizze funksjonaliteit is út' e doaze beskikber en kin yn elke faze fan it projekt aktivearre wurde.
It is mooglik om OpenID / SAML Identity providers te brûken foar brûkersautentikaasje.
Typyske autorisaasjescenario's mei OAuth2 yn Keycloak
Autorisaasje Code Flow - brûkt mei tsjinner-side applikaasjes. Ien fan 'e meast foarkommende soarten tastimming foar autorisaasje, om't it goed geskikt is foar serverapplikaasjes wêr't de boarnekoade en kliïntgegevens fan 'e applikaasje net beskikber binne foar bûtensteanders. It proses yn dit gefal is basearre op omlieding. De applikaasje moat yn steat wêze om te kommunisearjen mei in brûkersagint (brûkersagent), lykas in webblêder - om API-autorisaasjekoades te ûntfangen dy't troch de brûkersagint omlaat wurde.
ymplisite stream - brûkt troch mobile as webapplikaasjes (applikaasjes dy't rinne op it apparaat fan 'e brûker).
It ymplisite tastimmingstype foar autorisaasje wurdt brûkt troch mobile en webapplikaasjes wêr't kliïntfertroulikens net garandearre wurde kin. It ymplisite tastimmingstype brûkt ek trochferwizing fan brûkersagint, wêrby't it tagongstoken wurdt trochjûn oan de brûkersagint foar fierder gebrûk yn 'e applikaasje. Dit makket it token beskikber foar de brûker en oare applikaasjes op it apparaat fan de brûker. Dit soarte fan autorisaasje tastimming net authentisearje de identiteit fan de applikaasje, en it proses sels fertrout op in trochferwizing URL (earder registrearre by de tsjinst).
Implisite Flow stipet gjin ferfarske tokens foar tagongstoken.
Client Credentials Grant Flow - wurde brûkt as de applikaasje tagong hat ta de API. Dit soarte fan autorisaasje tastimming wurdt typysk brûkt foar tsjinner-nei-tsjinner ynteraksjes dy't moatte wurde útfierd op 'e eftergrûn sûnder direkte brûkersynteraksje. De subsydzjestream fan klantgegevens lit in webtsjinst (fertroulike kliïnt) har eigen referinsjes brûke ynstee fan in brûker foar te meitsjen om te autentisearjen by it roppen fan in oare webtsjinst. Foar in heger nivo fan feiligens is it mooglik foar de oproptsjinst in sertifikaat te brûken (ynstee fan in dielde geheim) as bewiisbrief.
De OAuth2-spesifikaasje wurdt beskreaun yn
JWT token en syn foardielen
JWT (JSON Web Token) is in iepen standert () dat in kompakte en selsstannige manier definiearret om ynformaasje feilich oer te bringen tusken partijen as in JSON-objekt.
Neffens de standert bestiet it token út trije dielen yn basis-64-formaat, skieden troch punten. It earste diel wurdt de koptekst neamd, dy't it type token en de namme fan it hash-algoritme befettet foar it krijen fan in digitale hantekening. It twadde diel bewarret de basisynformaasje (brûker, attributen, ensfh.). It tredde diel is de digitale hantekening.
. .
Nea bewarje in token yn jo DB. Om't in jildich token lykweardich is oan in wachtwurd, is it opslaan fan it token as it bewarjen fan it wachtwurd yn dúdlike tekst.
Tagongsbewiis is in token dat syn eigner tagong jout ta feilige serverboarnen. It hat normaal in koart libben en kin ekstra ynformaasje drage lykas it IP-adres fan 'e partij dy't it token freget.
Ferfarskje token is in token wêrmei kliïnten in oanfreegje nije tagong tokens neidat harren libben is ferrûn. Dizze tokens wurde normaal útjûn foar in lange perioade fan tiid.
De wichtichste foardielen fan gebrûk yn mikroservicearsjitektuer:
- Mooglikheid om tagong te krijen ta ferskate applikaasjes en tsjinsten fia ienmalige autentikaasje.
- By it ûntbrekken fan in oantal fereaske attributen yn it brûkersprofyl is it mooglik om te ferrykjen mei gegevens dy't kinne wurde tafoege oan 'e lading, ynklusyf automatisearre en on-the-fly.
- D'r is gjin ferlet om ynformaasje oer aktive sesjes op te slaan, de serverapplikaasje hoecht allinich de hantekening te ferifiearjen.
- Mear fleksibele tagongskontrôle troch ekstra attributen yn 'e lading.
- It brûken fan in token-hântekening foar de koptekst en de lading fergruttet de feiligens fan 'e oplossing as gehiel.
JWT token - komposysje
Header - standert befettet de koptekst allinich it type token en it algoritme dat wurdt brûkt foar fersifering.
It type token wurdt opslein yn 'e "typ" kaai. De 'type' kaai wurdt negearre yn 'e JWT. As de "typ" kaai oanwêzich is, moat de wearde JWT wêze om oan te jaan dat dit objekt in JSON Web Token is.
De twadde kaai "alg" definiearret it algoritme dat wurdt brûkt om it token te fersiferjen. It moat standert wurde ynsteld op HS256. De koptekst is kodearre yn base64.
{ "alg": "HS256", "type": "JWT"}
lading (ynhâld) - de nuttige lading bewarret alle ynformaasje dy't moat wurde kontrolearre. Elke kaai yn 'e lading is bekend as in "claim". Jo kinne bygelyks allinich de applikaasje ynfiere op útnoeging (sletten promo). As wy immen útnoegje om mei te dwaan, stjoere wy dy in útnoegingsbrief. It is wichtich om te kontrolearjen dat it e-postadres heart by de persoan dy't de útnoeging akseptearret, dus sille wy dit adres opnimme yn 'e lading, dêrfoar bewarje wy it yn' e "e-post" kaai
{ "e-post": "[e-post beskerme]"}
Keys yn payload kin wêze willekeurich. D'r binne lykwols in pear reservearre:
- iss (Utjouwer) - Identifisearret de applikaasje wêrfan it token wurdt ferstjoerd.
- sub (ûnderwerp) - definiearret it ûnderwerp fan it token.
- aud (Audience) is in array fan haadlettergefoelige snaren as URI's dy't in list is fan 'e ûntfangers fan dit token. As de ûntfangende kant in JWT ûntfangt mei de opjûne kaai, moat it kontrolearje op de oanwêzigens fan himsels yn 'e ûntfangers - oars negearje it token.
- exp (ferrintiid) - Jout oan wannear't it token ferrint. De JWT-standert fereasket dat al syn ymplemintaasjes ferrûne tokens ôfwize. De exp-kaai moat in tiidstempel wêze yn unix-formaat.
- nbf (Net foar) is in tiid yn unix-formaat dy't it momint bepaalt as it token jildich wurdt.
- iat (Utjûn op) - Dizze kaai stiet foar de tiid dat it token waard útjûn en kin brûkt wurde om de leeftyd fan 'e JWT te bepalen. De iat-kaai moat in tiidstempel wêze yn unix-formaat.
- Jti (JWT ID) - in tekenrige dy't de unike identifier fan dit token definiearret, haadlettergefoelich.
It is wichtich om te begripen dat de loadload net yn fersifere foarm ferstjoerd wurdt (hoewol't tokens kinne wurde nested en it is dan mooglik om fersifere gegevens te ferstjoeren). Dêrom kin it gjin geheime ynformaasje opslaan. Lykas de koptekst is de lading base64 kodearre.
Hantekening - as wy in titel en lading hawwe, kinne wy de hantekening berekkenje.
Base64-kodearre: koptekst en lading wurde nommen, se wurde kombineare yn in tekenrige troch in punt. Dan wurde dizze tekenrige en de geheime kaai ynfierd yn it fersiferingsalgoritme oantsjutte yn 'e kop ("alg" kaai). De kaai kin elke tekenrige wêze. Langere snaren sille it meast foarkommen wurde, om't it langer duorret om op te heljen.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Bouwe in Keycloak Failover Cluster Architecture
By it brûken fan ien kluster foar alle projekten, binne d'r ferhege easken foar in SSO-oplossing. As it tal projekten lyts is, binne dizze easken net sa opfallend foar alle projekten, mar mei in tanimming fan it oantal brûkers en yntegraasjes nimt de easken foar beskikberens en prestaasjes ta.
It fergrutsjen fan it risiko fan ienige SSO-falen fergruttet de easken foar de oplossingsarsjitektuer en de metoaden dy't brûkt wurde foar oerstallige komponinten en liedt ta in heul strakke SLA. Yn dit ferbân hawwe projekten faker yn 'e ûntwikkeling of iere stadia fan it útfieren fan oplossingen har eigen net-fout-tolerante ynfrastruktuer. As ûntwikkeling foarútgiet, is it ferplicht om kânsen te lizzen foar ûntwikkeling en skaalfergrutting. It is it meast fleksibel om in failover-kluster te bouwen mei kontenervirtualisaasje as in hybride oanpak.
Om te wurkjen yn 'e Aktive / Aktive en Aktive / Passive klustermodi, is it ferplicht om gegevenskonsistinsje te garandearjen yn in relasjonele databank - beide databankknooppunten moatte syngroan wurde replikearre tusken ferskate geo-ferdielde datasintra.
It ienfâldichste foarbyld fan in fout-tolerante ynstallaasje.
Wat binne de foardielen fan it brûken fan ien kluster:
- Hege beskikberens en prestaasjes.
- Stipe foar bestjoeringsmodi: Aktyf / Aktyf, Aktyf / Passyf.
- Mooglikheid om dynamysk te skaaljen - by it brûken fan containervirtualisaasje.
- Mooglikheid fan sintralisearre behear en tafersjoch.
- Uniforme oanpak foar identifikaasje / autentikaasje / autorisaasje fan brûkers yn projekten.
- Transparante ynteraksje tusken ferskate projekten sûnder belutsenens fan brûkers.
- De mooglikheid om it JWT-token opnij te brûken yn ferskate projekten.
- Ienfâldich punt fan fertrouwen.
- Snellere lansearring fan projekten mei help fan mikrotsjinsten / container-virtualisaasje (gjin needsaak om ekstra komponinten op te heffen en te konfigurearjen).
- It is mooglik om kommersjele stipe te keapjen fan 'e ferkeaper.
Wat te sykjen by it plannen fan in kluster
DBMS
Keycloak brûkt in databankbehearsysteem om te bewarjen: ryken, kliïnten, brûkers, ensfh.
In breed oanbod fan DBMS wurdt stipe: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak komt mei in eigen ynboude relaasjedatabase. It is oan te rieden om te brûken foar net-laden omjouwings - lykas ûntwikkelingsomjouwings.
Om te wurkjen yn Aktive / Aktive en Aktive / Passive klustermodi, is gegevenskonsistinsje yn in relasjonele databank fereaske, en beide databankklusterknooppunten wurde syngroan replikearre tusken datasintra.
Distribuearre cache (Infinspan)
Foar it kluster om goed te wurkjen, is ekstra syngronisaasje fan de folgjende soarten caches mei it JBoss Data Grid fereaske:
Autentikaasje-sesjes - brûkt om gegevens te bewarjen by it autentisearjen fan in spesifike brûker. Fersiken fan dizze cache befetsje typysk allinich de browser en de Keycloak-tsjinner, net de applikaasje.
Aksjetokens wurde brûkt foar senario's wêr't de brûker in aksje asynchronysk moat befêstigje (fia e-post). Bygelyks, tidens in ferjitten wachtwurdstream wurdt de actionTokens Infinispan-cache brûkt om metadata te folgjen oer assosjearre aksjetokens dy't al brûkt binne, sadat it net opnij brûkt wurde kin.
Caching en ynvalidaasje fan persistente gegevens - brûkt om persistente gegevens te cache om ûnnedige fragen nei de databank te foarkommen. As elke Keycloak-tsjinner de gegevens bywurket, moatte alle oare Keycloak-tsjinners yn alle datasintra derfan witte.
Wurk - Allinnich brûkt om ûnjildige berjochten te ferstjoeren tusken klusterknooppunten en datasintra.
Brûkersesjes - brûkt om gegevens oer brûkerssesjes op te slaan dy't jildich binne foar de doer fan 'e browsersesje fan 'e brûker. De cache moat HTTP-oanfragen ferwurkje fan 'e ein brûker en de applikaasje.
Brute force beskerming - brûkt om gegevens te folgjen oer mislearre oanmeldingen.
Load balancing
De load balancer is it ienige yngongspunt foar keycloak en moat kleverige sesjes stypje.
Applikaasje tsjinners
Se wurde brûkt om de ynteraksje fan komponinten mei elkoar te kontrolearjen en kinne virtualisearre of kontenerisearre wurde mei besteande automatisearringsark en dynamyske skaalfergrutting fan ynfrastruktuerautomatisearringsark. De meast foarkommende ynsetsenario's yn OpenShift, Kubernates, Rancher.
Dit konkludearret it earste diel - it teoretyske. Yn 'e folgjende searje artikels sille foarbylden fan yntegraasjes mei ferskate identiteitsproviders en foarbylden fan ynstellings wurde analysearre.
Boarne: www.habr.com