En iu ajn granda kompanio, kaj X5 Retail Group ne estas escepto, dum ĝi disvolvas, la nombro da projektoj, kiuj postulas uzantan rajtigon, pliiĝas. Kun la tempo, senjunta transiro de uzantoj de unu aplikaĵo al alia estas postulata, kaj tiam necesas uzi ununuran Single-Sing-On (SSO) servilon. Sed kio pri kiam identecaj provizantoj kiel AD aŭ aliaj, kiuj ne havas kromajn atributojn, estas jam uzataj en diversaj projektoj. Klaso de sistemoj nomataj "identigmakleristoj" venos al la savo. La plej funkciaj estas ĝiaj reprezentantoj, kiel Keycloak, Gravitee Access-administrado, ktp. Plej ofte, uzkazoj povas esti malsamaj: maŝina interago, uzantpartopreno, ktp. La solvo devas subteni flekseblan kaj skaleblan funkciojn, kiuj povas kombini ĉiujn postulojn en unu, kaj tiaj solvoj nia kompanio nun havas indikan makleriston - Keycloak.
Keycloak estas malfermfonta identeco kaj alirkontrolprodukto konservita fare de RedHat. Ĝi estas la bazo por la produktoj de la kompanio uzante SSO - RH-SSO.
Bazaj konceptoj
Antaŭ ol vi komencas trakti solvojn kaj alirojn, vi devas decidi laŭ terminoj kaj sinsekvo de procezoj:
Identigo estas procedo por rekoni subjekton per sia identigilo (alivorte, jen la difino de nomo, salutnomo aŭ numero).
Aŭtentigo - ĉi tio estas aŭtentikiga proceduro (la uzanto estas kontrolita per pasvorto, la letero estas kontrolita per elektronika subskribo, ktp.)
Rajtigo - jen la disponigo de aliro al rimedo (ekzemple al retpoŝto).
Identeca Makleristo Keycloak
ŝlosilmantelo estas malfermfonta identeco kaj aliradministradsolvo dizajnita por uzo en IS kie mikroservaj arkitekturpadronoj povas esti uzitaj.
Keycloak ofertas funkciojn kiel ununura ensaluto (SSO), perita identeco kaj socia ensaluto, uzantfederacio, klientadaptiloj, administra konzolo kaj konto-administra konzolo.
Baza funkcieco subtenata de Keycloak:
- Single-Sign On kaj Single-Sign Out por retumilaplikoj.
- Subteno por OpenID/OAuth 2.0/SAML.
- Identeca Maklerado - aŭtentikigo per eksteraj OpenID Connect aŭ SAML-identecprovizantoj.
- Socia Ensaluto - Guglo, GitHub, Facebook, Twitter subteno por uzantidentigo.
- Uzanto-Federacio - sinkronigado de uzantoj de LDAP kaj Active Directory-serviloj kaj aliaj identecaj provizantoj.
- Kerberos-ponto - uzante Kerberos-servilon por aŭtomata uzantaŭtentigo.
- Administra Konzolo - por unuigita administrado de agordoj kaj solvo-opcioj per la Reto.
- Account Management Console - por memadministrado de la uzantprofilo.
- Personigo de la solvo bazita sur la kompania identeco de la kompanio.
- 2FA-Aŭtentikigo - TOTP/HOTP-subteno per Google Authenticator aŭ FreeOTP.
- Ensalutfluoj - memregistrado de uzantoj, reakiro kaj rekomencigo de pasvortoj, kaj aliaj eblas.
- Sesia Administrado - administrantoj povas administri uzantsesiojn de ununura punkto.
- Token Mappers - liganta uzantajn atributojn, rolojn kaj aliajn postulatajn atributojn al ĵetonoj.
- Fleksebla politika administrado trans sfero, aplikaĵo kaj uzantoj.
- CORS-subteno - Klientadaptiloj havas enkonstruitan CORS-subtenon.
- Interfacoj de Servaj Provizantoj (SPI) - Granda nombro da SPIoj, kiuj ebligas al vi personecigi diversajn aspektojn de la servilo: aŭtentikigfluoj, identecprovizantoj, protokolmapado kaj pli.
- Klientadaptiloj por JavaScript-aplikoj, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- Subteno por labori kun diversaj aplikoj kiuj subtenas la OpenID Connect Relying Party-bibliotekon aŭ SAML 2.0 Service Provider Library.
- Vastebla uzante kromaĵojn.
Por CI / KD-procezoj, same kiel aŭtomatigo de administradprocezoj en Keycloak, la REST API / JAVA API povas esti uzata. Dokumentaro haveblas elektronike:
REST-API
Java API
Entreprenaj Identecaj Provizantoj (Surlokaj)
Kapablo aŭtentikigi uzantojn per User Federation-servoj.
Trapasa aŭtentikigo ankaŭ povas esti uzata - se uzantoj aŭtentikiĝas kontraŭ laborstacioj kun Kerberos (LDAP aŭ AD), tiam ili povas esti aŭtomate aŭtentikigitaj ĉe Keycloak sen devi enigi sian uzantnomon kaj pasvorton denove.
Por aŭtentigo kaj plia rajtigo de uzantoj, eblas uzi interrilatan DBMS, kiu estas plej aplikebla por evoluaj medioj, ĉar ĝi ne implikas longajn agordojn kaj integriĝojn en la fruaj stadioj de projektoj. Defaŭlte, Keycloak uzas enkonstruitan DBMS por stoki agordojn kaj uzantdatenojn.
La listo de subtenataj DBMS estas ampleksa kaj inkluzivas: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle kaj aliaj. La plej elprovitaj ĝis nun estas Oracle 12C Release1 RAC kaj Galera 3.12-grupo por MariaDB 10.1.19.
Identecaj provizantoj - socia ensaluto
Eblas uzi ensaluton de sociaj retoj. Por aktivigi la kapablon aŭtentikigi uzantojn, uzu la administran konzolon Keycloack. Ŝanĝoj en la aplika kodo ne estas bezonataj kaj ĉi tiu funkcio disponeblas el la skatolo kaj povas esti aktivigita en ajna etapo de la projekto.
Eblas uzi OpenID/SAML Identity provizantojn por uzantaŭtentigo.
Tipaj rajtigaj scenaroj uzante OAuth2 en Keycloak
Rajtigo Kodo Fluo - uzata kun servilflankaj aplikoj. Unu el la plej oftaj specoj de rajtpermeso ĉar ĝi taŭgas por servilaj aplikoj kie la fontkodo kaj klientdatenoj de la aplikaĵo ne estas haveblaj al eksteruloj. La procezo en ĉi tiu kazo baziĝas sur alidirektado. La aplikaĵo devas povi interagi kun uzantagento (uzant-agento), kiel tTT-legilo - por ricevi API-rajtigajn kodojn alidirektitaj per la uzantagento.
implica fluo - uzata de poŝtelefonaj aŭ ret-aplikoj (aplikoj kurantaj sur la aparato de la uzanto).
La implica rajtiga permestipo estas uzata de poŝtelefonaj kaj retaj aplikaĵoj, kie klienta konfidenco ne povas esti garantiita. La implica permesospeco ankaŭ uzas uzantagent-redirekton, per kio la alirĵetono estas pasita al la uzantagento por plua uzo en la aplikiĝo. Ĉi tio disponigas la ĵetonon al la uzanto kaj aliaj aplikoj sur la aparato de la uzanto. Ĉi tiu speco de rajtiga permeso ne aŭtentikigas la identecon de la aplikaĵo, kaj la procezo mem dependas de alidirekta URL (antaŭe registrita ĉe la servo).
Implica Fluo ne subtenas alirĵetonajn refreŝigajn ĵetonojn.
Kliento Akreditaĵoj Grant Flow — estas uzataj kiam la aplikaĵo aliras la API. Tiu speco de rajtpermeso estas tipe uzita por servil-al-servilaj interagoj kiuj devas esti faritaj en la fono sen tuja uzantinteragado. La klienta akreditaĵo-donaco-fluo permesas al retservo (konfidenca kliento) uzi siajn proprajn akreditaĵojn anstataŭe de parodiado de uzanto por aŭtentikigi dum vokado de alia retservo. Por pli alta nivelo de sekureco, estas eble ke la voka servo uzu atestilon (anstataŭ komunan sekreton) kiel akreditaĵon.
La OAuth2-specifo estas priskribita en
JWT-ĵetono kaj ĝiaj avantaĝoj
JWT (JSON Web Token) estas malferma normo () kiu difinas kompaktan kaj memstaran manieron sekure transdoni informojn inter partioj kiel JSON-objekton.
Laŭ la normo, la ĵetono konsistas el tri partoj en bazo-64-formato, apartigitaj per punktoj. La unua parto estas nomita la kaplinio, kiu enhavas la specon de ĵetono kaj la nomon de la hash-algoritmo por akiri ciferecan subskribon. La dua parto konservas la bazajn informojn (uzanto, atributoj, ktp.). La tria parto estas la cifereca subskribo.
. .
Neniam stoku ĵetonon en via DB. Ĉar valida ĵetono estas ekvivalenta al pasvorto, stoki la ĵetonon estas kiel konservi la pasvorton en klara teksto.
Alirĵetono estas signo, kiu donas al sia posedanto aliron al sekuraj servilaj rimedoj. Ĝi kutime havas mallongan vivdaŭron kaj povas porti pliajn informojn kiel la IP-adreso de la partio, kiu petas la ĵetonon.
Refreŝigi ĵetonon estas signo kiu permesas al klientoj peti novajn alirĵetonojn post kiam ilia vivdaŭro eksvalidiĝis. Ĉi tiuj ĵetonoj estas kutime elsenditaj por longa tempodaŭro.
La ĉefaj avantaĝoj de uzado en mikroserva arkitekturo:
- Kapablo aliri diversajn aplikojn kaj servojn per unufoja aŭtentigo.
- Manke de kelkaj postulataj atributoj en la uzantprofilo, eblas riĉigi per datumoj, kiuj povas esti aldonitaj al la utila ŝarĝo, inkluzive de aŭtomatigitaj kaj dumfluge.
- Ne necesas konservi informojn pri aktivaj sesioj, la servila aplikaĵo nur bezonas kontroli la subskribon.
- Pli fleksebla alirkontrolo per pliaj atributoj en la utila ŝarĝo.
- La uzo de signosignaturo por la kaplinio kaj utila ŝarĝo pliigas la sekurecon de la solvo entute.
JWT-ĵetono - komponado
kaplinio - defaŭlte, la kaplinio enhavas nur la specon de ĵetono kaj la algoritmon uzatan por ĉifrado.
La tipo de la ĵetono estas konservita en la "tip" ŝlosilo. La "tipo" ŝlosilo estas ignorita en la JWT. Se la "typ" ŝlosilo ĉeestas, ĝia valoro devas esti JWT por indiki, ke ĉi tiu objekto estas JSON Reteja Token.
La dua ŝlosilo "alg" difinas la algoritmon uzatan por ĉifri la ĵetonon. Ĝi devus esti agordita al HS256 defaŭlte. La kaplinio estas kodita en base64.
{ "alg": "HS256", "type": "JWT"}
utila ŝarĝo (enhavo) - la utila ŝarĝo konservas ajnajn informojn, kiujn oni devas kontroli. Ĉiu ŝlosilo en la utila ŝarĝo estas konata kiel "postulo". Ekzemple, vi povas eniri la aplikaĵon nur per invito (fermita reklamo). Kiam ni volas inviti iun partopreni, ni sendas al ili invitleteron. Gravas kontroli, ke la retadreso apartenas al la persono, kiu akceptas la inviton, do ni inkludos ĉi tiun adreson en la utila ŝarĝo, por tio ni konservas ĝin en la ŝlosilo "retpoŝto".
{ "retpoŝto": "[retpoŝte protektita]"}
Ŝlosiloj en utila ŝarĝo povas esti arbitraj. Tamen, estas kelkaj rezervitaj:
- iss (Eldonanto) - Identigas la aplikaĵon de kiu la ĵetono estas sendata.
- sub (Subject) - difinas la subjekton de la ĵetono.
- aud (Audience) estas tabelo de uskleksentemaj ĉenoj aŭ URIoj kiuj estas listo de la ricevantoj de ĉi tiu signo. Kiam la ricevanta flanko ricevas JWT kun la donita ŝlosilo, ĝi devas kontroli la ĉeeston de si mem en la ricevantoj - alie ignoru la ĵetonon.
- exp (Expiration Time) - Indikas kiam la ĵetono eksvalidiĝas. La JWT-normo postulas ĉiujn ĝiajn efektivigojn malakcepti eksvalidiĝintajn ĵetonojn. La exp-ŝlosilo devas esti tempomarko en uniksa formato.
- nbf (Ne Antaŭe) estas tempo en uniksa formato, kiu determinas la momenton, kiam la ĵetono validas.
- iat (Eldonita Ĉe) - Ĉi tiu ŝlosilo reprezentas la tempon, kiam la ĵetono estis eldonita kaj povas esti uzata por determini la aĝon de la JWT. La iat-ŝlosilo devas esti tempomarko en uniksa formato.
- Jti (JWT ID) — ĉeno kiu difinas la unikan identigilon de ĉi tiu signo, majuskle-distinta.
Gravas kompreni, ke la utila ŝarĝo ne estas transdonita en ĉifrita formo (kvankam ĵetonoj povas esti nestitaj kaj tiam eblas transdoni ĉifritajn datumojn). Tial ĝi ne povas konservi ajnan sekretan informon. Kiel la kaplinio, la utila ŝarĝo estas base64 kodita.
Subskribo - kiam ni havas titolon kaj utilan ŝarĝon, ni povas kalkuli la subskribon.
Base64-kodita: kaplinio kaj utila ŝarĝo estas prenitaj, ili estas kombinitaj en ŝnuron tra punkto. Tiam ĉi tiu ĉeno kaj la sekreta ŝlosilo estas enigataj al la ĉifrada algoritmo specifita en la kaplinio ("alg" ŝlosilo). La ŝlosilo povas esti ajna ŝnuro. Pli longaj ŝnuroj estos plej preferataj ĉar daŭros pli longe por preni.
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
Konstruado de Keycloak Failover Cluster Architecture
Kiam vi uzas ununuran areton por ĉiuj projektoj, estas pliigitaj postuloj por SSO-solvo. Kiam la nombro da projektoj estas malgranda, ĉi tiuj postuloj ne estas tiel videblaj por ĉiuj projektoj, tamen, kun pliiĝo en la nombro da uzantoj kaj integriĝoj, la postuloj por havebleco kaj rendimento pliiĝas.
Pliigi la riskon de ununura SSO-malsukceso pliigas la postulojn por la solva arkitekturo kaj la metodoj uzitaj por redundaj komponentoj kaj kondukas al tre malloza SLA. Ĉi-rilate, pli ofte en la disvolviĝo aŭ fruaj stadioj de efektivigado de solvoj, projektoj havas sian propran ne-malsukcesan infrastrukturon. Dum evoluo progresas, necesas doni ŝancojn por disvolviĝo kaj skalo. Estas plej flekseble konstrui malsukcesan areton uzante kontenervirtualigon aŭ hibridan aliron.
Por labori en la Aktivaj/Aktivaj kaj Aktivaj/Pasivaj aretreĝimoj, estas postulate certigi datenkonsistecon en interrilata datumbazo - ambaŭ datumbaznodoj devas esti sinkrone reproduktitaj inter malsamaj geo-distribuitaj datencentroj.
La plej simpla ekzemplo de misfunkcia instalaĵo.
Kio estas la avantaĝoj de uzado de ununura areto:
- Alta havebleco kaj rendimento.
- Subteno por operaciaj reĝimoj: Aktiva / Aktiva, Aktiva / Pasiva.
- Kapablo dinamike skali - kiam vi uzas ujo-virtualigon.
- Eblo de centralizita administrado kaj monitorado.
- Unuigita aliro por identigo/aŭtentikigo/rajtigo de uzantoj en projektoj.
- Pli travidebla interagado inter malsamaj projektoj sen uzanta implikiĝo.
- La kapablo reuzi la JWT-ĵetonon en diversaj projektoj.
- Ununura punkto de fido.
- Pli rapida lanĉo de projektoj uzante mikroservojn/ujon virtualigon (ne bezonas levi kaj agordi pliajn komponantojn).
- Eblas aĉeti komercan subtenon de la vendisto.
Kion Serĉi Kiam Planado de Areto
DBMS
Keycloak uzas datumbazan administradsistemon por stoki: regnojn, klientojn, uzantojn, ktp.
Vasta gamo de DBMS estas subtenata: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak venas kun sia propra enkonstruita interrilata datumbazo. Oni rekomendas uzi por ne-ŝarĝitaj medioj - kiel disvolvaj medioj.
Por labori en Aktivaj/Aktivaj kaj Aktivaj/Pasivaj aretreĝimoj, datenkonsistenco en interrilata datumbazo estas postulata, kaj ambaŭ datumbazaj aretnodoj estas sinkrone reproduktitaj inter datencentroj.
Distribuita kaŝmemoro (Infinspan)
Por ke la areto funkciu ĝuste, necesas plia sinkronigo de la sekvaj specoj de kaŝmemoroj uzante la JBoss Data Grid:
Aŭtentikigsesioj - uzataj por konservi datumojn dum aŭtentikigado de specifa uzanto. Petoj de ĉi tiu kaŝmemoro kutime inkluzivas nur la retumilon kaj la servilon Keycloak, ne la aplikaĵon.
Agaj signoj estas uzataj por scenaroj, kie la uzanto bezonas konfirmi agon nesinkrone (per retpoŝto). Ekzemple, dum forgesita pasvortfluo, la kaŝmemoro de actionTokens Infinispan estas uzata por konservi trakon de metadatenoj pri rilataj agĵetonoj kiuj jam estis uzitaj, do ĝi ne povas esti reuzita.
Kaŝmemoro kaj malvalidigo de konstantaj datumoj - uzata por konservi konstantajn datumojn por eviti nenecesajn demandojn al la datumbazo. Kiam iu ajn Keycloak-servilo ĝisdatigas la datumojn, ĉiuj aliaj Keycloak-serviloj en ĉiuj datumcentroj devas scii pri ĝi.
Laboro - Nur uzata por sendi nevalidajn mesaĝojn inter clusternodoj kaj datumcentroj.
Uzantsesioj - uzataj por stoki datumojn pri uzantsesioj kiuj validas dum la daŭro de la retumila sesio de la uzanto. La kaŝmemoro devas procesi HTTP-petojn de la finuzanto kaj la aplikaĵo.
Protekto de krudforto - uzata por spuri datumojn pri malsukcesaj ensalutoj.
Ŝarĝbalancado
La ŝarĝbalancilo estas la ununura enirpunkto al keycloak kaj devas subteni gluiĝemajn sesiojn.
Aplikaj Serviloj
Ili kutimas kontroli la interagadon de komponentoj unu kun la alia kaj povas esti virtualigitaj aŭ kontenerigitaj uzante ekzistantajn aŭtomatigilojn kaj dinamikan skaladon de infrastrukturaj aŭtomatigiloj. La plej oftaj deplojscenaroj en OpenShift, Kubernates, Rancher.
Ĉi tio finas la unuan parton - la teorian. En la sekva serio de artikoloj, ekzemploj de integriĝoj kun diversaj identecaj provizantoj kaj ekzemploj de agordoj estos analizitaj.
fonto: www.habr.com