In enige groot maatskappy, en X5 Retail Group is geen uitsondering nie, aangesien dit ontwikkel, neem die aantal projekte toe wat gebruikersmagtiging vereis. Met verloop van tyd word naatlose oorgang van gebruikers van een toepassing na 'n ander vereis, en dan is daar 'n behoefte om 'n enkele Single-Sing-On (SSO) bediener te gebruik. Maar wat van wanneer identiteitsverskaffers soos AD of ander wat nie bykomende eienskappe het nie, reeds in verskeie projekte gebruik word. 'n Klas stelsels genaamd "identifikasiemakelaars" sal tot die redding kom. Die mees funksionele is sy verteenwoordigers, soos Keycloak, Gravitee Access-bestuur, ens. Meestal kan gebruiksgevalle anders wees: masjieninteraksie, gebruikersdeelname, ens. Die oplossing moet buigsame en skaalbare funksionaliteit ondersteun wat alle vereistes in een kan kombineer, en sulke oplossings ons maatskappy het nou 'n aanduiding makelaar - Keycloak.
Keycloak is 'n oopbron-identiteit en toegangsbeheerproduk wat deur RedHat onderhou word. Dit is die basis vir die maatskappy se produkte wat SSO - RH-SSO gebruik.
Basiese konsepte
Voordat jy begin om oplossings en benaderings te hanteer, moet jy in terme en volgorde van prosesse besluit:
identifikasie is 'n prosedure om 'n subjek aan die hand van sy identifiseerder te herken (met ander woorde, dit is die definisie van 'n naam, login of nommer).
verifikasie - dit is 'n verifikasieprosedure (die gebruiker word gekontroleer met 'n wagwoord, die brief word nagegaan met 'n elektroniese handtekening, ens.)
magtiging - dit is die verskaffing van toegang tot 'n hulpbron (byvoorbeeld tot e-pos).
Identiteitsmakelaar Sleutelmantel
Sleutelmantel is 'n oopbron identiteit- en toegangsbestuuroplossing wat ontwerp is vir gebruik in IS waar mikrodiensargitektuurpatrone gebruik kan word.
Keycloak bied kenmerke soos enkelaanmelding (SSO), bemiddelde identiteit en sosiale aanmelding, gebruikersfederasie, kliëntadapters, administrasiekonsole en rekeningbestuurkonsole.
Basiese funksionaliteit ondersteun deur Keycloak:
- Enkel-aanmeld en enkel-afmeld vir blaaiertoepassings.
- Ondersteuning vir OpenID/OAuth 2.0/SAML.
- Identiteitsmakelaars - verifikasie met behulp van eksterne OpenID Connect of SAML identiteitsverskaffers.
- Sosiale aanmelding - Google, GitHub, Facebook, Twitter ondersteuning vir gebruiker identifikasie.
- Gebruikersfederasie - sinchronisasie van gebruikers vanaf LDAP- en Active Directory-bedieners en ander identiteitsverskaffers.
- Kerberos-brug - gebruik 'n Kerberos-bediener vir outomatiese gebruikersverifikasie.
- Admin Console - vir verenigde bestuur van instellings en oplossing opsies via die web.
- Rekeningbestuurkonsole - vir selfbestuur van die gebruikersprofiel.
- Aanpassing van die oplossing gebaseer op die korporatiewe identiteit van die maatskappy.
- 2FA-verifikasie - TOTP/HOTP-ondersteuning met behulp van Google Authenticator of FreeOTP.
- Login Flows - gebruiker self-registrasie, wagwoord herstel en herstel, en ander is moontlik.
- Sessiebestuur - administrateurs kan gebruikersessies vanaf 'n enkele punt bestuur.
- Token Mappers - bind gebruikerskenmerke, rolle en ander vereiste eienskappe aan tokens.
- Buigsame beleidsbestuur oor gebied, toepassing en gebruikers.
- CORS-ondersteuning - Kliëntadapters het ingeboude CORS-ondersteuning.
- Diensverskaffer-koppelvlakke (SPI) - 'n Groot aantal SPI's wat jou toelaat om verskeie aspekte van die bediener aan te pas: stawingvloeie, identiteitsverskaffers, protokolkartering, en meer.
- Kliëntadapters vir JavaScript-toepassings, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Ondersteuning om met verskeie toepassings te werk wat die OpenID Connect Relying Party-biblioteek of SAML 2.0-diensverskafferbiblioteek ondersteun.
- Uitbreidbaar met inproppe.
Vir CI / CD-prosesse, sowel as outomatisering van bestuursprosesse in Keycloak, kan die REST API / JAVA API gebruik word. Dokumentasie is elektronies beskikbaar:
REST API
Java API
Ondernemingsidentiteitverskaffers (op die perseel)
Vermoë om gebruikers te verifieer deur User Federation-dienste.
Deur-verifikasie kan ook gebruik word - as gebruikers stawing op werkstasies met Kerberos (LDAP of AD), dan kan hulle outomaties aan Keycloak geverifieer word sonder om hul gebruikersnaam en wagwoord weer in te voer.
Vir verifikasie en verdere magtiging van gebruikers is dit moontlik om 'n relasionele DBBS te gebruik, wat die meeste van toepassing is vir ontwikkelingsomgewings, aangesien dit nie lang instellings en integrasies in die vroeë stadiums van projekte behels nie. Keycloak gebruik standaard 'n ingeboude DBBS om instellings en gebruikersdata te stoor.
Die lys van ondersteunde DBMS is omvattend en sluit in: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle en ander. Die meeste getoets tot dusver is Oracle 12C Release1 RAC en Galera 3.12 cluster vir MariaDB 10.1.19.
Identiteitsverskaffers - sosiale aanmelding
Dit is moontlik om 'n aanmelding vanaf sosiale netwerke te gebruik. Gebruik die Keycloack-administrasiekonsole om die vermoë om gebruikers te verifieer, te aktiveer. Veranderinge in die toepassingskode word nie vereis nie en hierdie funksionaliteit is uit die boks beskikbaar en kan in enige stadium van die projek geaktiveer word.
Dit is moontlik om OpenID/SAML-identiteitverskaffers te gebruik vir gebruikersverifikasie.
Tipiese magtigingscenario's wat OAuth2 in Keycloak gebruik
Magtigingskodevloei - gebruik met bediener-kant toepassings. Een van die mees algemene tipes magtigingstoestemmings omdat dit goed geskik is vir bedienertoepassings waar die toepassing se bronkode en kliëntdata nie vir buitestanders beskikbaar is nie. Die proses in hierdie geval is gebaseer op herleiding. Die toepassing moet in staat wees om met 'n gebruikersagent (gebruikersagent), soos 'n webblaaier, te kommunikeer - om API-magtigingskodes te ontvang wat deur die gebruikersagent herlei word.
implisiete vloei - gebruik deur mobiele of webtoepassings (toepassings wat op die gebruiker se toestel loop).
Die implisiete magtigingstoestemmingstipe word deur mobiele en webtoepassings gebruik waar kliëntvertroulikheid nie gewaarborg kan word nie. Die implisiete toestemmingstipe gebruik ook gebruikeragentherleiding, waardeur die toegangtoken aan die gebruikeragent oorgedra word vir verdere gebruik in die toepassing. Dit maak die teken beskikbaar vir die gebruiker en ander toepassings op die gebruiker se toestel. Hierdie tipe magtigingstoestemming staaf nie die identiteit van die toepassing nie, en die proses self maak staat op 'n herleiding-URL (voorheen by die diens geregistreer).
Implisiete vloei ondersteun nie toegangstokenverversingtokens nie.
Kliëntgeloofsbriewe verleen vloei - word gebruik wanneer die toepassing toegang tot die API verkry. Hierdie tipe magtigingstoestemming word tipies gebruik vir bediener-tot-bediener-interaksies wat op die agtergrond uitgevoer moet word sonder onmiddellike gebruikerinteraksie. Die kliënt geloofsbriewe toelae-vloei laat 'n webdiens (vertroulike kliënt) toe om sy eie geloofsbriewe te gebruik in plaas daarvan om 'n gebruiker te verpersoonlik om te verifieer wanneer 'n ander webdiens gebel word. Vir 'n hoër vlak van sekuriteit is dit moontlik vir die oproepdiens om 'n sertifikaat (in plaas van 'n gedeelde geheim) as 'n geloofsbrief te gebruik.
Die OAuth2-spesifikasie word beskryf in
JWT-token en die voordele daarvan
JWT (JSON Web Token) is 'n oop standaard () wat 'n kompakte en selfstandige manier definieer om inligting veilig tussen partye oor te dra as 'n JSON-objek.
Volgens die standaard bestaan die teken uit drie dele in basis-64-formaat, geskei deur kolletjies. Die eerste deel word die kop genoem, wat die tipe teken en die naam van die hash-algoritme bevat vir die verkryging van 'n digitale handtekening. Die tweede deel stoor die basiese inligting (gebruiker, eienskappe, ens.). Die derde deel is die digitale handtekening.
. .
Moet nooit 'n teken in jou DB stoor nie. Omdat 'n geldige teken gelykstaande is aan 'n wagwoord, is die stoor van die teken soos om die wagwoord in duidelike teks te stoor.
Toegangstoken is 'n teken wat sy eienaar toegang verleen tot veilige bedienerhulpbronne. Dit het gewoonlik 'n kort leeftyd en kan bykomende inligting bevat, soos die IP-adres van die party wat die token versoek.
Herlaai teken is 'n teken wat kliënte toelaat om nuwe toegangstekens aan te vra nadat hul leeftyd verstryk het. Hierdie tokens word gewoonlik vir 'n lang tydperk uitgereik.
Die belangrikste voordele van die gebruik in mikrodiensargitektuur:
- Vermoë om toegang te verkry tot verskeie toepassings en dienste deur eenmalige verifikasie.
- In die afwesigheid van 'n aantal vereiste eienskappe in die gebruikersprofiel, is dit moontlik om te verryk met data wat by die loonvrag gevoeg kan word, insluitend outomatiese en on-the-fly.
- Dit is nie nodig om inligting oor aktiewe sessies te stoor nie, die bedienertoepassing hoef slegs die handtekening te verifieer.
- Meer buigsame toegangsbeheer deur bykomende eienskappe in die loonvrag.
- Die gebruik van 'n tekenhandtekening vir die kopskrif en loonvrag verhoog die sekuriteit van die oplossing as geheel.
JWT-token - samestelling
Titel - by verstek bevat die kopskrif slegs die tipe teken en die algoritme wat vir enkripsie gebruik word.
Die tipe teken word in die "tik" sleutel gestoor. Die 'tipe' sleutel word in die JWT geïgnoreer. As die "typ" sleutel teenwoordig is, moet die waarde daarvan JWT wees om aan te dui dat hierdie voorwerp 'n JSON Web Token is.
Die tweede sleutel "alg" definieer die algoritme wat gebruik word om die teken te enkripteer. Dit moet by verstek op HS256 gestel word. Die kopskrif is geënkodeer in base64.
{ "alg": "HS256", "type": "JWT"}
loonvrag (inhoud) - die loonvrag stoor enige inligting wat nagegaan moet word. Elke sleutel in die loonvrag staan bekend as 'n "eis". Byvoorbeeld, jy kan die aansoek slegs op uitnodiging inskryf (geslote promosie). Wanneer ons iemand wil nooi om deel te neem, stuur ons vir hulle 'n uitnodigingsbrief. Dit is belangrik om seker te maak dat die e-posadres aan die persoon behoort wat die uitnodiging aanvaar, so ons sal hierdie adres by die loonvrag insluit, hiervoor stoor ons dit in die "e-pos" sleutel
{ "e-pos": "[e-pos beskerm]"}
Sleutels in loonvrag kan arbitrêr wees. Daar is egter 'n paar voorbehou:
- iss (Uitreiker) - Identifiseer die toepassing waarvandaan die token gestuur word.
- sub (Onderwerp) - definieer die onderwerp van die teken.
- aud (Gehoor) is 'n reeks hooflettergevoelige stringe of URI's wat 'n lys van die ontvangers van hierdie teken is. Wanneer die ontvangende kant 'n JWT met die gegewe sleutel ontvang, moet dit kyk vir die teenwoordigheid van homself in die ontvangers - anders ignoreer die teken.
- exp (Vervaltyd) - Dui aan wanneer die token verval. Die JWT-standaard vereis dat al sy implementerings verstreke tokens verwerp. Die exp-sleutel moet 'n tydstempel in unix-formaat wees.
- nbf (Nie voor nie) is 'n tyd in unix-formaat wat die oomblik bepaal wanneer die token geldig word.
- iat (Uitgereik op) - Hierdie sleutel verteenwoordig die tyd wat die token uitgereik is en kan gebruik word om die ouderdom van die JWT te bepaal. Die iat-sleutel moet 'n tydstempel in unix-formaat wees.
- Jti (JWT ID) - 'n string wat die unieke identifiseerder van hierdie teken definieer, hooflettergevoelig.
Dit is belangrik om te verstaan dat die loonvrag nie in geënkripteerde vorm oorgedra word nie (alhoewel tokens geneste kan word en dit dan moontlik is om geënkripteerde data oor te dra). Daarom kan dit geen geheime inligting stoor nie. Soos die kopskrif, is die loonvrag base64-geënkodeer.
Handtekening - wanneer ons 'n titel en loonvrag het, kan ons die handtekening bereken.
Base64-geënkodeer: kopskrif en loonvrag word geneem, dit word deur 'n punt in 'n string gekombineer. Dan word hierdie string en die geheime sleutel ingevoer na die enkripsie-algoritme wat in die kopskrif ("alg"-sleutel) gespesifiseer word. Die sleutel kan enige string wees. Langer snare sal die meeste voorkeur geniet aangesien dit langer sal neem om op te tel.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Bou 'n Sleutelmantel Failover Cluster Argitektuur
Wanneer 'n enkele groepering vir alle projekte gebruik word, is daar verhoogde vereistes vir 'n SSO-oplossing. Wanneer die aantal projekte klein is, is hierdie vereistes nie so opvallend vir alle projekte nie, maar met 'n toename in die aantal gebruikers en integrasies neem die vereistes vir beskikbaarheid en prestasie toe.
Die verhoging van die risiko van enkel SSO mislukking verhoog die vereistes vir die oplossing argitektuur en die metodes wat gebruik word vir oortollige komponente en lei tot 'n baie streng SLA. In hierdie verband, meer dikwels tydens die ontwikkeling of vroeë stadiums van die implementering van oplossings, het projekte hul eie nie-fout-verdraagsame infrastruktuur. Soos ontwikkeling vorder, is dit nodig om geleenthede vir ontwikkeling en skaal neer te lê. Dit is die mees buigsame om 'n failover-kluster te bou deur houervirtualisering of 'n hibriede benadering te gebruik.
Om in die aktiewe/aktiewe en aktiewe/passiewe groeperingsmodusse te werk, is dit nodig om datakonsekwentheid in 'n relasionele databasis te verseker - beide databasisnodusse moet sinchronies tussen verskillende geo-verspreide datasentrums gerepliseer word.
Die eenvoudigste voorbeeld van 'n foutverdraagsame installasie.
Wat is die voordele van die gebruik van 'n enkele groepering:
- Hoë beskikbaarheid en werkverrigting.
- Ondersteuning vir bedryfsmodusse: aktief / aktief, aktief / passief.
- Vermoë om dinamies te skaal - wanneer houervirtualisering gebruik word.
- Moontlikheid van gesentraliseerde bestuur en monitering.
- Eenvormige benadering vir identifikasie/verifikasie/magtiging van gebruikers in projekte.
- Meer deursigtige interaksie tussen verskillende projekte sonder gebruikersbetrokkenheid.
- Die vermoë om die JWT-token in verskeie projekte te hergebruik.
- Enkele punt van vertroue.
- Vinniger bekendstelling van projekte met behulp van mikrodienste/houervirtualisering (nie nodig om bykomende komponente op te hef en op te stel nie).
- Dit is moontlik om kommersiële ondersteuning van die verkoper te koop.
Waarna om te kyk wanneer jy 'n groep beplan
DBMS
Keycloak gebruik 'n databasisbestuurstelsel om: ryke, kliënte, gebruikers, ens.
'n Wye reeks DBMS word ondersteun: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak kom met sy eie ingeboude relasionele databasis. Dit word aanbeveel om te gebruik vir nie-gelaaide omgewings - soos ontwikkelingsomgewings.
Om in aktiewe/aktiewe en aktiewe/passiewe groeperingsmodusse te werk, word datakonsekwentheid in 'n relasionele databasis vereis, en beide databasisklusternodusse word sinchronies tussen datasentrums gerepliseer.
Verspreide kas (Infinspan)
Vir die cluster om korrek te werk, word addisionele sinchronisasie van die volgende tipes kas met behulp van die JBoss Data Grid vereis:
Stawingsessies - word gebruik om data te stoor wanneer 'n spesifieke gebruiker geverifieer word. Versoeke vanaf hierdie kas sluit gewoonlik net die blaaier en die Keycloak-bediener in, nie die toepassing nie.
Aksietekens word gebruik vir scenario's waar die gebruiker 'n handeling asynchronies (via e-pos) moet bevestig. Byvoorbeeld, tydens 'n vergeet wagwoordvloei, word die actionTokens Infinispan-kas gebruik om tred te hou met metadata oor geassosieerde aksietekens wat reeds gebruik is, sodat dit nie hergebruik kan word nie.
Kas en ongeldigmaking van aanhoudende data - word gebruik om aanhoudende data te kas om onnodige navrae na die databasis te vermy. Wanneer enige Keycloak-bediener die data opdateer, moet alle ander Keycloak-bedieners in alle datasentrums daarvan weet.
Werk - Slegs gebruik om ongeldige boodskappe tussen cluster nodusse en datasentrums te stuur.
Gebruikersessies – word gebruik om data oor gebruikersessies te stoor wat geldig is vir die duur van die gebruiker se blaaiersessie. Die kas moet HTTP-versoeke van die eindgebruiker en die toepassing verwerk.
Brute force beskerming - word gebruik om data oor mislukte aanmeldings op te spoor.
Vrag balansering
Die lasbalanseerder is die enkele toegangspunt tot keycloak en moet taai sessies ondersteun.
Toepassingsbedieners
Hulle word gebruik om die interaksie van komponente met mekaar te beheer en kan gevirtualiseer of gehouer word met behulp van bestaande outomatiseringsinstrumente en dinamiese skaal van infrastruktuur-outomatiseringsinstrumente. Die mees algemene ontplooiingscenario's in OpenShift, Kubernates, Rancher.
Dit sluit die eerste deel af - die teoretiese een. In die volgende reeks artikels sal voorbeelde van integrasies met verskeie identiteitsverskaffers en voorbeelde van instellings ontleed word.
Bron: will.com