Ցանկացած խոշոր ընկերությունում, և X5 Retail Group-ը բացառություն չէ, քանի որ այն զարգանում է, օգտվողների թույլտվություն պահանջող նախագծերի թիվը մեծանում է: Ժամանակի ընթացքում օգտատերերի անխափան անցումը մի հավելվածից մյուսին է պահանջվում, այնուհետև անհրաժեշտություն է առաջանում օգտագործել մեկ Single-Sing-On (SSO) սերվեր: Բայց ինչ վերաբերում է այն դեպքում, երբ ինքնության մատակարարները, ինչպիսիք են AD կամ այլք, որոնք չունեն լրացուցիչ հատկանիշներ, արդեն օգտագործվում են տարբեր նախագծերում: Օգնության կգա համակարգերի դասը, որը կոչվում է «նույնականացման բրոքերներ»: Առավել ֆունկցիոնալը նրա ներկայացուցիչներն են, ինչպիսիք են Keycloak-ը, Gravitee Access-ի կառավարումը և այլն: Ամենից հաճախ օգտագործման դեպքերը կարող են տարբեր լինել՝ մեքենայի փոխազդեցություն, օգտվողի մասնակցություն և այլն: և նման լուծումներ մեր ընկերությունն այժմ ունի ցուցիչ բրոքեր՝ Keycloak:
Keycloak-ը բաց կոդով ինքնության և մուտքի վերահսկման արտադրանք է, որը պահպանվում է RedHat-ի կողմից: Այն հիմք է հանդիսանում ընկերության արտադրանքի համար, օգտագործելով SSO - RH-SSO:
Հիմնական հասկացություններ
Նախքան լուծումներով և մոտեցումներով զբաղվելը, դուք պետք է որոշեք գործընթացների տերմիններով և հաջորդականությամբ.
Հայտնաբերում առարկան իր նույնացուցիչով ճանաչելու ընթացակարգ է (այլ կերպ ասած՝ սա անվան, մուտքի կամ համարի սահմանումն է):
Նույնականացմանը - սա նույնականացման ընթացակարգ է (օգտագործողը ստուգվում է գաղտնաբառով, նամակը ստուգվում է էլեկտրոնային ստորագրությամբ և այլն)
Լիազորություն - սա ռեսուրսի (օրինակ, էլ. փոստի) հասանելիության ապահովումն է:
Identity Broker Keycloak
ստեղնաշար բաց կոդով ինքնության և մուտքի կառավարման լուծում է, որը նախատեսված է IS-ում օգտագործելու համար, որտեղ կարող են օգտագործվել միկրոսերվիսային ճարտարապետության օրինաչափություններ:
Keycloak-ն առաջարկում է այնպիսի գործառույթներ, ինչպիսիք են՝ միայնակ մուտքը (SSO), միջնորդավորված ինքնություն և սոցիալական մուտք, օգտվողների դաշնություն, հաճախորդի ադապտերներ, ադմինիստրատորի վահանակ և հաշվի կառավարման վահանակ:
Keycloak-ի կողմից աջակցվող հիմնական գործառույթը՝
- Single-Sign On և Single-Sign Out բրաուզերի հավելվածների համար:
- Աջակցություն OpenID/OAuth 2.0/SAML-ին:
- Identity Brokering - նույնականացում արտաքին OpenID Connect կամ SAML ինքնության մատակարարների միջոցով:
- Սոցիալական մուտք - Google, GitHub, Facebook, Twitter աջակցություն օգտվողների նույնականացման համար:
- Օգտագործողների ֆեդերացիա - LDAP և Active Directory սերվերներից և ինքնության այլ մատակարարներից օգտվողների համաժամացում:
- Kerberos կամուրջ - Kerberos սերվերի օգտագործումը օգտատերերի ավտոմատ նույնականացման համար:
- Ադմինիստրատորի վահանակ - ցանցի միջոցով կարգավորումների և լուծման տարբերակների միասնական կառավարման համար:
- Հաշվի կառավարման վահանակ - օգտվողի պրոֆիլի ինքնակառավարման համար:
- Լուծման անհատականացում՝ հիմնված ընկերության կորպորատիվ ինքնության վրա:
- 2FA Նույնականացում - TOTP/HOTP աջակցություն Google Authenticator-ի կամ FreeOTP-ի միջոցով:
- Մուտք գործելու հոսքեր – հնարավոր է օգտատիրոջ ինքնագրանցում, գաղտնաբառի վերականգնում և վերակայում և այլն:
- Նիստի կառավարում – ադմինիստրատորները կարող են կառավարել օգտվողի նիստերը մեկ կետից:
- Token Mappers - օգտատիրոջ հատկանիշները, դերերը և այլ պահանջվող ատրիբուտները կապում են նշաններին:
- Ճկուն քաղաքականության կառավարում ողջ ոլորտում, հավելվածում և օգտագործողների համար:
- CORS աջակցություն - Հաճախորդի ադապտերներն ունեն ներկառուցված CORS աջակցություն:
- Ծառայությունների մատակարարների միջերեսներ (SPI) - Մեծ թվով SPI-ներ, որոնք թույլ են տալիս հարմարեցնել սերվերի տարբեր ասպեկտներ՝ նույնականացման հոսքեր, ինքնության մատակարարներ, արձանագրությունների քարտեզագրում և այլն:
- Հաճախորդի ադապտերներ JavaScript հավելվածների համար, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring:
- Աջակցություն տարբեր հավելվածների հետ աշխատելու համար, որոնք աջակցում են OpenID Connect Relying Party գրադարանին կամ SAML 2.0 Ծառայությունների Մատակարարի Գրադարանին:
- Ընդարձակելի՝ օգտագործելով պլագիններ:
CI / CD գործընթացների, ինչպես նաև Keycloak-ում կառավարման գործընթացների ավտոմատացման համար կարող է օգտագործվել REST API / JAVA API-ն: Փաստաթղթերը հասանելի են էլեկտրոնային եղանակով.
REST API
Java API
Ձեռնարկությունների ինքնության մատակարարներ (շենքում)
Օգտագործողների ֆեդերացիայի ծառայությունների միջոցով օգտատերերին նույնականացնելու հնարավորություն:
Անցումային նույնականացումը կարող է օգտագործվել նաև. եթե օգտվողները նույնականացնում են Kerberos-ի (LDAP կամ AD) աշխատանքային կայանների դեմ, ապա նրանք կարող են ավտոմատ կերպով նույնականացվել Keycloak-ում՝ առանց նորից մուտքագրելու իրենց օգտանունը և գաղտնաբառը:
Օգտատերերի նույնականացման և հետագա թույլտվության համար հնարավոր է օգտագործել հարաբերական DBMS, որն առավել կիրառելի է զարգացման միջավայրերի համար, քանի որ այն չի ներառում երկար կարգավորումներ և ինտեգրումներ նախագծերի վաղ փուլերում: Լռելյայնորեն, Keycloak-ն օգտագործում է ներկառուցված DBMS՝ կարգավորումները և օգտվողի տվյալները պահելու համար:
Աջակցվող DBMS-ների ցանկը ընդարձակ է և ներառում է՝ MS SQL, Oracle, PostgreSQL, MariaDB, Oracle և այլն: Մինչ այժմ ամենաշատ փորձարկվածներն են Oracle 12C Release1 RAC-ը և Galera 3.12 կլաստերը MariaDB 10.1.19-ի համար:
Ինքնության մատակարարներ՝ սոցիալական մուտք
Հնարավոր է մուտք գործել սոցիալական ցանցերից։ Օգտատերերին նույնականացնելու հնարավորությունը ակտիվացնելու համար օգտագործեք Keycloack ադմինիստրատորի վահանակը: Դիմումի կոդի փոփոխությունները պարտադիր չեն, և այս գործառույթը հասանելի է առանց տուփի և կարող է ակտիվացվել նախագծի ցանկացած փուլում:
Օգտատերերի նույնականացման համար հնարավոր է օգտագործել OpenID/SAML Identity մատակարարներ:
Տիպիկ թույլտվության սցենարներ, օգտագործելով OAuth2 Keycloak-ում
Թույլտվության ծածկագրի հոսք - օգտագործվում է սերվերային հավելվածների հետ: Թույլտվության թույլտվության ամենատարածված տեսակներից մեկը, քանի որ այն լավ հարմար է սերվերային հավելվածների համար, որտեղ հավելվածի սկզբնական կոդը և հաճախորդի տվյալները հասանելի չեն կողմնակի անձանց համար: Գործընթացը այս դեպքում հիմնված է վերահղման վրա: Հավելվածը պետք է կարողանա շփվել օգտատերերի գործակալի (օգտատիրոջ-գործակալի) հետ, օրինակ՝ վեբ բրաուզերի հետ՝ օգտվողի գործակալի միջոցով վերահղված API-ի թույլտվության կոդերը ստանալու համար:
անուղղակի հոսք - օգտագործվում է բջջային կամ վեբ հավելվածների կողմից (օգտագործողի սարքի վրա աշխատող հավելվածներ):
Անուղղակի թույլտվության թույլտվության տեսակն օգտագործվում է բջջային և վեբ հավելվածների կողմից, որտեղ հաճախորդի գաղտնիությունը չի կարող երաշխավորվել: Անուղղակի թույլտվության տեսակը նաև օգտագործում է օգտվողի գործակալի վերահղում, որի միջոցով մուտքի նշանը փոխանցվում է օգտվողի գործակալին՝ հավելվածում հետագա օգտագործման համար: Սա նշանը հասանելի է դարձնում օգտվողին և օգտագործողի սարքի այլ հավելվածներին: Թույլտվության այս տեսակի թույլտվությունը չի հաստատում հայտի ինքնությունը, և գործընթացն ինքնին հիմնված է վերահղման URL-ի վրա (նախկինում գրանցվել է ծառայության մեջ):
Implicit Flow-ը չի աջակցում մուտքի նշանի թարմացման նշանները:
Հաճախորդների հավատարմագրերի դրամաշնորհային հոսք — օգտագործվում են, երբ հավելվածը մուտք է գործում API: Այս տեսակի թույլտվության թույլտվությունը սովորաբար օգտագործվում է սերվերից սերվեր փոխազդեցությունների համար, որոնք պետք է կատարվեն հետին պլանում՝ առանց օգտվողի անմիջական փոխազդեցության: Հաճախորդի հավատարմագրերի տրամադրման հոսքը թույլ է տալիս վեբ ծառայությանը (գաղտնի հաճախորդը) օգտագործել իր սեփական հավատարմագրերը` այլ վեբ ծառայություն զանգահարելիս օգտագործողին նույնականացնելու փոխարեն: Անվտանգության ավելի բարձր մակարդակի համար զանգահարող ծառայության համար հնարավոր է որպես հավատարմագիր օգտագործել վկայականը (ընդհանուր գաղտնիքի փոխարեն):
OAuth2 ճշգրտումը նկարագրված է
JWT նշանը և դրա առավելությունները
JWT (JSON Web Token) բաց ստանդարտ է (), որը սահմանում է կոմպակտ և ինքնամփոփ եղանակ՝ կողմերի միջև որպես JSON օբյեկտ անվտանգ փոխանցելու տեղեկատվությունը:
Ստանդարտի համաձայն, նշանը բաղկացած է երեք մասից՝ base-64 ձևաչափով, որոնք բաժանված են կետերով։ Առաջին մասը կոչվում է վերնագիր, որը պարունակում է նշանի տեսակը և թվային ստորագրություն ստանալու համար հեշ ալգորիթմի անվանումը։ Երկրորդ մասը պահպանում է հիմնական տեղեկատվությունը (օգտագործող, ատրիբուտներ և այլն): Երրորդ մասը թվային ստորագրությունն է։
. .
Երբեք մի պահեք նշան ձեր DB-ում: Քանի որ վավեր նշանը համարժեք է գաղտնաբառին, նշանը պահելը նման է գաղտնաբառի հստակ տեքստի պահպանմանը:
Մուտքի նշան նշան է, որը թույլ է տալիս իր սեփականատիրոջը մուտք գործել անվտանգ սերվերի ռեսուրսներ: Այն սովորաբար ունի կարճ ժամկետ և կարող է ունենալ լրացուցիչ տեղեկություններ, ինչպիսիք են նշանը հայցող կողմի IP հասցեն:
Թարմացնել նշանը նշան է, որը թույլ է տալիս հաճախորդներին պահանջել մուտքի նոր նշաններ իրենց կյանքի ժամկետի ավարտից հետո: Այս նշանները սովորաբար թողարկվում են երկար ժամանակով:
Միկրոծառայությունների ճարտարապետության օգտագործման հիմնական առավելությունները.
- Միանվագ նույնականացման միջոցով տարբեր հավելվածներ և ծառայություններ մուտք գործելու հնարավորություն:
- Օգտատիրոջ պրոֆիլում մի շարք պահանջվող ատրիբուտների բացակայության դեպքում հնարավոր է հարստացնել տվյալներ, որոնք կարող են ավելացվել օգտակար բեռին, ներառյալ ավտոմատացված և թռիչքի ժամանակ:
- Ակտիվ նիստերի մասին տեղեկություններ պահելու կարիք չկա, սերվերի հավելվածը միայն պետք է ստուգի ստորագրությունը։
- Ավելի ճկուն մուտքի հսկողություն՝ օգտակար բեռի լրացուցիչ ատրիբուտների միջոցով:
- Վերնագրի և օգտակար բեռի համար նշանային ստորագրության օգտագործումը մեծացնում է լուծման անվտանգությունը որպես ամբողջություն:
JWT նշան - կազմ
Վերնագիր — լռելյայնորեն, վերնագիրը պարունակում է միայն նշանի տեսակը և գաղտնագրման համար օգտագործվող ալգորիթմը:
Նշանի տեսակը պահվում է «typ» ստեղնում: «Տիպ» ստեղնը անտեսվում է JWT-ում: Եթե առկա է «typ» ստեղնը, դրա արժեքը պետք է լինի JWT՝ ցույց տալու համար, որ այս օբյեկտը JSON Web Token է:
Երկրորդ բանալին «alg» նշում է ալգորիթմը, որն օգտագործվում է նշանը գաղտնագրելու համար: Լռելյայն այն պետք է սահմանվի HS256: Վերնագիրը կոդավորված է base64-ում:
{"alg": "HS256", "type": "JWT"}
ծանրաբեռնվածություն (բովանդակություն) - բեռը պահպանում է ցանկացած տեղեկատվություն, որը պետք է ստուգվի: Օգտակար բեռի յուրաքանչյուր բանալի հայտնի է որպես «պահանջ»: Օրինակ՝ հավելված կարող եք մուտք գործել միայն հրավերով (փակ պրոմո): Երբ մենք ուզում ենք որևէ մեկին հրավիրել մասնակցելու, նրան հրավիրատոմս ենք ուղարկում։ Կարևոր է ստուգել, որ էլ.փոստի հասցեն պատկանում է հրավերն ընդունողին, ուստի մենք կներառենք այս հասցեն բեռնվածության մեջ, դրա համար մենք այն պահում ենք «էլ.փոստ» բանալիում:
{ "email": "[էլեկտրոնային փոստով պաշտպանված]«}
Բեռի մեջ գտնվող բանալիները կարող են կամայական լինել: Այնուամենայնիվ, կան մի քանի վերապահվածներ.
- iss (Թողարկող) - որոշում է այն հավելվածը, որից ուղարկվում է նշանը:
- sub (Subject) - սահմանում է նշանի առարկան:
- aud (Հանդիսատես) – մեծատառերի զգայուն տողերի կամ URI-ների զանգված, որն այս նշանի ստացողների ցուցակն է: Երբ ստացող կողմը ստանում է JWT տվյալ բանալիով, նա պետք է ինքն իրեն ստուգի հասցեատերերում, հակառակ դեպքում անտեսի նշանը:
- exp (Expiration Time) - Նշում է, թե երբ է լրանում նշանը: JWT ստանդարտը պահանջում է, որ իր բոլոր իրականացումները մերժեն ժամկետանց նշանները: Exp ստեղնը պետք է լինի unix ձևաչափով ժամանակի դրոշմ:
- nbf (Not Before)-ը unix ձևաչափով ժամանակ է, որը որոշում է այն պահը, երբ նշանը դառնում է վավեր:
- iat (Issued At) - Այս բանալին ներկայացնում է նշանի թողարկման ժամանակը և կարող է օգտագործվել JWT-ի տարիքը որոշելու համար: iat ստեղնը պետք է լինի unix ձևաչափով ժամանակի դրոշմ:
- Jti-ն (JWT ID) տող է, որը սահմանում է այս նշանի համար հատուկ մեծատառերի զգայուն նույնացուցիչ:
Կարևոր է հասկանալ, որ ծանրաբեռնվածությունը չի փոխանցվում կոդավորված ձևով (չնայած նշանները կարող են տեղադրվել, և այնուհետև հնարավոր է փոխանցել կոդավորված տվյալները): Հետեւաբար, այն չի կարող պահել որեւէ գաղտնի տեղեկատվություն: Ինչպես վերնագրի պես, օգտակար բեռը base64 կոդավորված է:
Ստորագրություն - Երբ մենք ունենանք վերնագիր և օգտակար բեռ, մենք կարող ենք հաշվարկել ստորագրությունը:
Base64-encoded. վերնագիրն ու օգտակար բեռը վերցված են, դրանք միավորվում են տողի մեջ կետի միջոցով: Այնուհետև այս տողը և գաղտնի բանալին մուտքագրվում են վերնագրում նշված գաղտնագրման ալգորիթմում («alg» բանալի): Բանալին կարող է լինել ցանկացած լար: Առավել նախընտրելի կլինեն ավելի երկար լարերը, քանի որ այն ավելի երկար կպահանջի:
{"alg":"RSA1_5", "payload":"A128CBC-HS256"}
Keycloak Failover Cluster Architecture-ի կառուցում
Բոլոր նախագծերի համար մեկ կլաստեր օգտագործելու դեպքում ավելացել են ՊՍՍ-ի լուծման պահանջները: Երբ նախագծերի թիվը փոքր է, այդ պահանջներն այնքան էլ նկատելի չեն բոլոր նախագծերի համար, այնուամենայնիվ, օգտագործողների քանակի և ինտեգրումների աճի հետ մեկտեղ ավելանում են հասանելիության և կատարողականի պահանջները:
Մեկ SSO-ի ձախողման ռիսկի ավելացումը մեծացնում է լուծման ճարտարապետության և ավելորդ բաղադրիչների համար օգտագործվող մեթոդների պահանջները և հանգեցնում է շատ խիտ SLA-ի: Այս առումով, ավելի հաճախ լուծումների մշակման կամ իրականացման վաղ փուլերում նախագծերն ունեն իրենց սեփական ենթակառուցվածքները, որոնք չեն հանդուրժում սխալները: Զարգացման գործընթացի հետ մեկտեղ անհրաժեշտ է ստեղծել զարգացման և մասշտաբի հնարավորություններ: Առավել ճկուն է ֆայլերի կլաստերի կառուցումը, օգտագործելով կոնտեյների վիրտուալացում կամ հիբրիդային մոտեցում:
Ակտիվ/Ակտիվ և Ակտիվ/Պասիվ կլաստերի ռեժիմներում աշխատելու համար պահանջվում է ապահովել տվյալների հետևողականությունը հարաբերական տվյալների բազայում. տվյալների բազայի երկու հանգույցները պետք է սինխրոն կերպով վերարտադրվեն տարբեր աշխարհաբաշխված տվյալների կենտրոնների միջև:
Սխալ հանդուրժող տեղադրման ամենապարզ օրինակը:
Որո՞նք են մեկ կլաստերի օգտագործման առավելությունները.
- Բարձր հասանելիություն և կատարողականություն:
- Աջակցություն գործառնական ռեժիմներին՝ Ակտիվ / Ակտիվ, Ակտիվ / Պասիվ:
- Դինամիկ մասշտաբի ունակություն - կոնտեյների վիրտուալացում օգտագործելիս:
- Կենտրոնացված կառավարման և մոնիտորինգի հնարավորություն:
- Նախագծերում օգտագործողների նույնականացման/նույնականացման/լիազորման միասնական մոտեցում:
- Ավելի թափանցիկ փոխազդեցություն տարբեր նախագծերի միջև՝ առանց օգտվողների մասնակցության:
- JWT նշանը տարբեր նախագծերում կրկին օգտագործելու ունակություն:
- Վստահության մեկ կետ.
- Միկրոծառայությունների/կոնտեյներների վիրտուալացման օգտագործմամբ նախագծերի ավելի արագ մեկնարկ (հավելյալ բաղադրիչներ բարձրացնելու և կազմաձևելու կարիք չկա):
- Հնարավոր է ձեռք բերել կոմերցիոն աջակցություն վաճառողից:
Ինչ փնտրել կլաստեր պլանավորելիս
DBMS
Keycloak-ը օգտագործում է տվյալների բազայի կառավարման համակարգ՝ տիրույթներ, հաճախորդներ, օգտվողներ և այլն պահելու համար:
Աջակցվում է DBMS-ների լայն տեսականի՝ MS SQL, Oracle, MySQL, PostgreSQL: Keycloak-ը գալիս է իր ներկառուցված հարաբերական տվյալների բազայով: Խորհուրդ է տրվում օգտագործել թեթև աշխատանքային միջավայրերում, ինչպիսիք են զարգացման միջավայրերը:
Ակտիվ/Ակտիվ և Ակտիվ/Պասիվ կլաստերի ռեժիմներում աշխատելու համար անհրաժեշտ է տվյալների հետևողականություն հարաբերական տվյալների բազայում, և տվյալների բազայի կլաստերների երկու հանգույցները համաժամանակյա կրկնօրինակվում են տվյալների կենտրոնների միջև:
Բաշխված քեշ (Infinspan)
Որպեսզի կլաստերը ճիշտ աշխատի, JBoss Data Grid-ի օգտագործմամբ քեշերի հետևյալ տեսակների լրացուցիչ համաժամացում է պահանջվում.
Նույնականացման նիստեր - օգտագործվում է տվյալ օգտատիրոջ նույնականացման ժամանակ տվյալները պահպանելու համար: Այս քեշի հարցումները սովորաբար ներառում են միայն զննարկիչը և Keycloak սերվերը, այլ ոչ թե հավելվածը:
Գործողությունների նշաններն օգտագործվում են այն սցենարների համար, երբ օգտատերը պետք է ասինխրոն կերպով հաստատի գործողությունը (էլփոստի միջոցով): Օրինակ, գաղտնաբառի մոռացման ժամանակ, actionTokens Infinispan քեշը օգտագործվում է հետևելու մետատվյալներին կապված գործողության նշանների մասին, որոնք արդեն օգտագործվել են, ուստի այն չի կարող կրկին օգտագործվել:
Մշտական տվյալների քեշավորում և անվավերացում - օգտագործվում է մշտական տվյալների քեշավորման համար՝ տվյալների բազայում անհարկի հարցումներից խուսափելու համար: Երբ որևէ Keycloak սերվեր թարմացնում է տվյալները, տվյալների բոլոր կենտրոնների բոլոր մյուս Keycloak սերվերները պետք է իմանան այդ մասին:
Աշխատանք - Օգտագործվում է միայն կլաստերային հանգույցների և տվյալների կենտրոնների միջև անվավեր հաղորդագրություններ ուղարկելու համար:
Օգտագործողի նիստեր - օգտագործվում է օգտատիրոջ աշխատաշրջանի տվյալները պահելու համար, որոնք վավեր են օգտատիրոջ բրաուզերի աշխատաշրջանի ընթացքում: Քեշը պետք է մշակի վերջնական օգտագործողի և հավելվածի HTTP հարցումները:
Կոպիտ ուժի պաշտպանություն - օգտագործվում է անհաջող մուտքերի մասին տվյալները հետևելու համար:
Բեռների հավասարակշռում
Բեռի հավասարակշռիչը ստեղնաշարի միակ մուտքի կետն է և պետք է աջակցի կպչուն նիստերին:
Դիմումի սերվերներ
Դրանք օգտագործվում են բաղադրիչների փոխազդեցությունը միմյանց հետ վերահսկելու համար և կարող են վիրտուալացվել կամ կոնտեյներացվել՝ օգտագործելով առկա ավտոմատացման գործիքները և ենթակառուցվածքի ավտոմատացման գործիքների դինամիկ մասշտաբը: Տեղակայման ամենատարածված սցենարները OpenShift-ում, Kubernates-ում, Rancher-ում:
Սրանով ավարտվում է առաջին մասը՝ տեսականը։ Հոդվածների հաջորդ շարքում կվերլուծվեն ինքնության տարբեր մատակարարների հետ ինտեգրման օրինակներ և կարգավորումների օրինակներ:
Source: www.habr.com