Аливаа томоохон компани болон X5 Retail Group нь үл хамаарах зүйл биш бөгөөд хөгжил ахих тусам хэрэглэгчийн зөвшөөрөл шаарддаг төслүүдийн тоо нэмэгддэг. Цаг хугацаа өнгөрөхөд хэрэглэгчдийг нэг програмаас нөгөөд шилжүүлэх шаардлагатай болж, дараа нь нэг Single-Sing-On (SSO) сервер ашиглах шаардлагатай болдог. Гэхдээ AD эсвэл нэмэлт шинж чанаргүй бусад таних үйлчилгээ үзүүлэгчид янз бүрийн төслүүдэд аль хэдийн ашиглагдаж байвал яах вэ. "Identity Brokers" гэж нэрлэгддэг системийн ангиуд аврах ажилд ирнэ. Хамгийн их ажиллагаатай нь Keycloak, Gravitee Access менежмент гэх мэт түүний төлөөлөгчид юм. Ихэнхдээ ашиглалтын хувилбарууд нь өөр өөр байж болно: машины харилцан үйлчлэл, хэрэглэгчийн оролцоо гэх мэт. Энэхүү шийдэл нь бүх шаардлагыг нэг дор нэгтгэж чадах уян хатан, өргөтгөх боломжтой функцийг дэмжих ёстой. мөн ийм шийдэл Манай компани одоо заагч брокер – Keycloak-тай боллоо.
Keycloak нь RedHat-аас хадгалдаг нээлттэй эхийн таних болон хандалтын хяналтын бүтээгдэхүүн юм. Энэ нь SSO - RH-SSO-г ашиглан компанийн бүтээгдэхүүний үндэс суурь юм.
Үндсэн ухагдахуунууд
Шийдэл, арга барилыг шийдэж эхлэхээсээ өмнө үйл явцын нэр томъёо, дарааллыг шийдэх хэрэгтэй.
Таних тэмдэг Энэ нь субьектийг танигчаар нь таних журам (өөрөөр хэлбэл энэ нь нэр, нэвтрэх эсвэл дугаарыг тодорхойлох явдал юм).
Гэрчлэлт – энэ бол баталгаажуулах журам (хэрэглэгчийг нууц үг ашиглан баталгаажуулах, захидал цахим гарын үсэг ашиглан баталгаажуулах гэх мэт)
Зөвшөөрөл – нөөцөд (жишээ нь, цахим шуудан) хандах боломжийг олгож байна.
Keycloak Identity Broker
түлхүүрийн нөмрөг нь бичил үйлчилгээний архитектурын хэв маягийг ашиглаж болох IS-д ашиглахад зориулагдсан нээлттэй эхийн таних болон хандалтын удирдлагын шийдэл юм.
Keycloak нь Single Sign-On (SSO), Brokered Identity and Social Login, User Federation, Client Adapters, Admin Console, Account Management Console зэрэг функцуудыг санал болгодог.
Keycloak-д дэмжигдсэн үндсэн функцууд:
- Хөтөч програмуудын хувьд нэг удаа нэвтэрч, нэг удаа гарна уу.
- OpenID/OAuth 2.0/SAML дэмжлэг.
- Identity Brokering – гадаад OpenID Connect эсвэл SAML таних үйлчилгээ үзүүлэгч ашиглан баталгаажуулалт.
- Нийгмийн нэвтрэлт - Google, GitHub, Facebook, Twitter-ийн хэрэглэгчийн таних дэмжлэг.
- Хэрэглэгчийн холбоо – LDAP болон Active Directory серверүүд болон бусад таниулах үйлчилгээ үзүүлэгчээс хэрэглэгчдийг синхрончлох.
- Kerberos bridge – хэрэглэгчийг автоматаар баталгаажуулахад Kerberos сервер ашиглах.
- Админ консол - вэбээр дамжуулан тохиргоо болон шийдлийн сонголтуудын нэгдсэн удирдлагад зориулагдсан.
- Бүртгэлийн удирдлагын консол – хэрэглэгчийн профайлыг бие даан удирдахад зориулагдсан.
- Компанийн байгууллагын онцлогт тулгуурлан шийдлийг өөрчлөх.
- 2FA Authentication - Google Authenticator эсвэл FreeOTP ашиглан TOTP/HOTP дэмжлэг.
- Нэвтрэх урсгал - хэрэглэгч өөрөө бүртгүүлэх, нууц үгээ сэргээх, дахин тохируулах, бусад боломжтой.
- Session Management - администраторууд хэрэглэгчийн сессийг нэг цэгээс удирдах боломжтой.
- Token Mappers – хэрэглэгчийн шинж чанар, үүрэг болон бусад шаардлагатай шинж чанаруудыг жетон болгон холбох.
- Хүрээ, аппликейшн болон хэрэглэгчдэд уян хатан бодлогын удирдлага.
- CORS-ийн дэмжлэг - Үйлчлүүлэгч адаптерууд нь CORS дэмжлэгтэй.
- Үйлчилгээ үзүүлэгчийн интерфейс (SPI) - серверийн янз бүрийн талыг тохируулах боломжийг олгодог олон тооны SPI: баталгаажуулалтын урсгал, таних үйлчилгээ үзүүлэгч, протоколын зураглал гэх мэт.
- JavaScript програмуудад зориулсан клиент адаптерууд, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
- OpenID Connect Relying Party номын сан эсвэл SAML 2.0 үйлчилгээ үзүүлэгчийн номын санг дэмждэг төрөл бүрийн програмуудтай ажиллахад дэмжлэг үзүүлэх.
- Plugins ашиглан өргөтгөх боломжтой.
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 болон бусад. Одоогоор хамгийн их туршиж үзсэн нь MariaDB 12-д зориулсан Oracle 1C Release3.12 RAC болон Galera 10.1.19 кластер юм.
Identity үйлчилгээ үзүүлэгчид - нийгмийн нэвтрэлт
Нийгмийн сүлжээнээс нэвтрэх эрхийг ашиглах боломжтой. Хэрэглэгчдийг баталгаажуулах чадварыг идэвхжүүлэхийн тулд Keycloack админ консолыг ашиглана уу. Програмын кодыг өөрчлөх шаардлагагүй бөгөөд энэ функцийг хайрцагнаас авах боломжтой бөгөөд төслийн аль ч үе шатанд идэвхжүүлж болно.
Хэрэглэгчдийг баталгаажуулахын тулд OpenID/SAML Identity үйлчилгээ үзүүлэгчийг ашиглах боломжтой.
Keycloak-д OAuth2 ашигладаг ердийн зөвшөөрлийн хувилбарууд
Зөвшөөрлийн кодын урсгал — сервер талын програмуудад ашиглагддаг. Зөвшөөрлийн зөвшөөрлийн хамгийн түгээмэл төрлүүдийн нэг нь програмын эх код болон үйлчлүүлэгчийн өгөгдөлд бусад хүмүүст хандах боломжгүй сервер талын програмуудад тохиромжтой. Энэ тохиолдолд үйл явц нь дахин чиглүүлэлт дээр суурилдаг. Аппликешн нь хэрэглэгчийн агентаар дамжуулсан API зөвшөөрлийн кодыг хүлээн авахын тулд вэб хөтөч гэх мэт хэрэглэгчийн агенттай (хэрэглэгч-агент) холбогдох боломжтой байх ёстой.
Далд урсгал - гар утас эсвэл вэб програмууд (хэрэглэгчийн төхөөрөмж дээр ажиллаж байгаа програмууд) ашигладаг.
Далд зөвшөөрлийн зөвшөөрлийн төрлийг үйлчлүүлэгчийн нууцлалыг баталгаажуулах боломжгүй мобайл болон вэб програмуудад ашигладаг. Мөн далд зөвшөөрлийн төрөл нь хэрэглэгчийн агентын дахин чиглүүлэлтийг ашигладаг бөгөөд үүгээр хандалтын токеныг хэрэглэгчийн агент руу дамжуулж, цаашдын хэрэглээнд нь ашигладаг. Энэ нь токеныг хэрэглэгч болон хэрэглэгчийн төхөөрөмж дээрх бусад програмуудад ашиглах боломжтой болгодог. Энэ төрлийн зөвшөөрлийн зөвшөөрөл нь програмын таних тэмдгийг баталгаажуулдаггүй бөгөөд процесс нь өөрөө дахин чиглүүлэх URL (өмнө нь үйлчилгээнд бүртгүүлсэн) дээр тулгуурладаг.
Implicit Flow нь хандалтын токен сэргээх жетонуудыг дэмждэггүй.
Үйлчлүүлэгчийн итгэмжлэл Grant урсгал — програм API-д хандах үед ашиглагддаг. Энэ төрлийн зөвшөөрлийн зөвшөөрлийг ихэвчлэн хэрэглэгчийн шууд харилцан үйлчлэлгүйгээр далд хийх ёстой серверээс сервер хоорондын харилцан үйлчлэлд ашигладаг. Үйлчлүүлэгчийн итгэмжлэл олгох урсгал нь вэб үйлчилгээнд (нууц үйлчлүүлэгч) өөр вэб үйлчилгээ рүү залгах үед хэрэглэгчийн нэрээр таниулахын оронд өөрийн итгэмжлэлийг ашиглах боломжийг олгодог. Аюулгүй байдлын өндөр түвшний хувьд дуудлага хийх үйлчилгээ нь гэрчилгээг (хуваалцсан нууцын оронд) итгэмжлэл болгон ашиглах боломжтой.
OAuth2-ийн тодорхойлолтыг доор тайлбарласан болно
JWT токен ба түүний давуу талууд
JWT (JSON Web Token) нь нээлттэй стандарт (), энэ нь JSON объект хэлбэрээр талуудын хооронд мэдээллийг найдвартай дамжуулах авсаархан, бие даасан арга замыг тодорхойлдог.
Стандартын дагуу токен нь үндсэн 64 форматтай, цэгээр тусгаарлагдсан гурван хэсгээс бүрдэнэ. Эхний хэсгийг толгой гэж нэрлэдэг бөгөөд энэ нь токенын төрөл, тоон гарын үсгийг олж авах хэш алгоритмын нэрийг агуулдаг. Хоёрдахь хэсэг нь үндсэн мэдээллийг (хэрэглэгч, шинж чанарууд гэх мэт) хадгалдаг. Гурав дахь хэсэг нь тоон гарын үсэг юм.
. .
Токеныг DB-дээ хэзээ ч бүү хадгал. Хүчинтэй токен нь нууц үгтэй дүйцэхүйц тул жетоныг хадгалах нь нууц үгийг тодорхой текстээр хадгалахтай адил юм.
Хандалтын токен нь эзэмшигчдээ хамгаалагдсан серверийн нөөцөд хандах боломжийг олгодог токен юм. Энэ нь ихэвчлэн богино хугацаанд үйлчилдэг бөгөөд жетоныг хүссэн талын IP хаяг гэх мэт нэмэлт мэдээллийг агуулж болно.
Токеныг шинэчлэх нь үйлчлүүлэгчид ашиглалтын хугацаа нь дууссаны дараа шинэ хандалтын жетон хүсэх боломжийг олгодог токен юм. Эдгээр жетоныг ихэвчлэн удаан хугацаагаар гаргадаг.
Микро үйлчилгээний архитектурыг ашиглах гол давуу талууд:
- Нэг удаагийн баталгаажуулалтаар янз бүрийн програм, үйлчилгээнд хандах боломжтой.
- Хэрэглэгчийн профайлд хэд хэдэн шаардлагатай шинж чанарууд байхгүй бол тэдгээрийг ачааллын ачаалалд нэмж оруулах боломжтой мэдээллээр баяжуулах боломжтой, үүнд автоматаар болон шууд ажиллах боломжтой.
- Идэвхтэй сешнүүдийн талаарх мэдээллийг хадгалах шаардлагагүй, серверийн програм нь зөвхөн гарын үсгийг баталгаажуулах шаардлагатай.
- Ачаалал дахь нэмэлт шинж чанаруудаар дамжуулан илүү уян хатан хандалтын хяналт.
- Гарчиг болон ачааллын хувьд токен гарын үсэг ашиглах нь шийдлийн аюулгүй байдлыг бүхэлд нь нэмэгдүүлдэг.
JWT токен - найрлага
Толгой — анхдагчаар толгой хэсэгт зөвхөн токенын төрөл болон шифрлэхэд ашигладаг алгоритмыг агуулна.
Токен төрлийг "typ" товчлуурт хадгална. JWT дээр "typ" товчлуурыг үл тоомсорлодог. Хэрэв "typ" товчлуур байгаа бол энэ объект нь JSON Web Token гэдгийг харуулахын тулд түүний утга JWT байх ёстой.
Хоёрдахь түлхүүр "alg" нь жетоныг шифрлэхэд ашигладаг алгоритмыг тодорхойлдог. Анхдагчаар үүнийг HS256 гэж тохируулсан байх ёстой. Толгой нь base64 дээр кодлогдсон.
{ "alg": "HS256", "typ": "JWT"}
ачаалал (агуулга) - Ачаа нь шалгах шаардлагатай аливаа мэдээллийг хадгалдаг. Ачаалал дахь түлхүүр бүрийг "нэхэмжлэл" гэж нэрлэдэг. Жишээлбэл, та өргөдөлд зөвхөн урилгаар (хаалттай сурталчилгаа) орж болно. Бид хэн нэгнийг оролцохыг хүсвэл урилгын захидал илгээдэг. Имэйл хаяг нь урилгыг хүлээн авсан хүнийх мөн эсэхийг шалгах нь чухал тул бид энэ хаягийг ачаалалд оруулах бөгөөд үүний тулд бид үүнийг "и-мэйл" түлхүүрт хадгалдаг.
{ "имэйл": "[имэйлээр хамгаалагдсан]" }
Ачааллын түлхүүрүүд нь дур зоргоороо байж болно. Гэсэн хэдий ч, хэд хэдэн нөөцөлсөн байна:
- iss (Issuer) - жетон илгээсэн програмыг тодорхойлно.
- дэд (Сэдэв) - жетоны сэдвийг тодорхойлно.
- aud (Үзэгчид) – энэ токеныг хүлээн авагчдын жагсаалт болох том жижиг үсгээр ялгах тэмдэгт мөрүүд эсвэл URI-уудын массив. Хүлээн авагч тал өгөгдсөн түлхүүрээр JWT хүлээн авахдаа хүлээн авагчид байгаа эсэхийг шалгах ёстой - эс тэгвээс жетоныг үл тоомсорлож болно.
- exp (Төгсгөлийн хугацаа) - Токен дуусах хугацааг заана. JWT стандарт нь бүх хэрэгжилт нь хугацаа нь дууссан жетоноос татгалзахыг шаарддаг. Exp түлхүүр нь unix форматтай цагийн тэмдэг байх ёстой.
- nbf (Өмнө нь биш) нь токен хүчинтэй болох мөчийг тодорхойлдог unix форматтай цаг юм.
- iat (Issued At) - Энэ түлхүүр нь жетон гаргасан цагийг илэрхийлдэг бөгөөд JWT-ийн насыг тодорхойлоход ашиглаж болно. iat түлхүүр нь unix форматтай цагийн тэмдэг байх ёстой.
- Jti (JWT ID) нь энэ токенд зориулсан жижиг жижиг жижиг тодорхойлогчийг тодорхойлдог мөр юм.
Ачаалал нь шифрлэгдсэн байдлаар дамждаггүй гэдгийг ойлгох нь чухал (хэдийгээр токенуудыг үүрлэж, дараа нь шифрлэгдсэн өгөгдлийг дамжуулах боломжтой). Тиймээс та ямар ч нууц мэдээллийг хадгалах боломжгүй. Гарчигтай адил ачаалал нь base64 кодлогдсон байна.
Гарын үсэг - Нэгэнт бид толгой болон ачаалалтай бол гарын үсгийг тооцоолж болно.
base64-д кодлогдсон толгой болон ачааллыг авч цэгээр тусгаарласан шугам болгон нэгтгэнэ. Дараа нь энэ мөр болон нууц түлхүүрийг толгой хэсэгт заасан шифрлэлтийн алгоритмд оруулна ("alg" түлхүүр). Түлхүүр нь ямар ч мөр байж болно. Сонголт хийхэд илүү их цаг хугацаа шаардагдах тул урт мөрүүдийг сонгох нь илүү дээр байх болно.
{"alg":"RSA1_5","ачаалал":"A128CBC-HS256"}
Keycloak Failover Cluster архитектурыг бүтээх
Бүх төслүүдэд нэг кластер ашиглах үед SSO шийдэлд тавигдах шаардлага нэмэгддэг. Төслийн тоо цөөхөн үед эдгээр шаардлага нь бүх төслүүдэд тийм ч чухал биш боловч хэрэглэгчдийн тоо, нэгдлүүд нэмэгдэхийн хэрээр хүртээмж, гүйцэтгэлийн шаардлага нэмэгддэг.
Ганц SSO бүтэлгүйтлийн эрсдлийг нэмэгдүүлэх нь шийдлийн архитектур болон илүүдэл бүрэлдэхүүн хэсгүүдэд ашигладаг аргуудад тавигдах шаардлагыг нэмэгдүүлж, маш хатуу SLA-д хүргэдэг. Үүнтэй холбогдуулан, төслүүдийг боловсруулах эсвэл хэрэгжүүлэх эхний үе шатанд ихэвчлэн өөрсдийн алдааг тэсвэрлэдэггүй дэд бүтэцтэй байдаг. Хөгжил урагшлахын хэрээр хөгжих, өргөжүүлэх боломжийг бий болгох шаардлагатай байна. Контейнерын виртуалчлал эсвэл эрлийз аргыг ашиглан бүтэлгүйтлийн кластер байгуулах нь хамгийн уян хатан байдаг.
Идэвхтэй/Идэвхтэй, Идэвхтэй/Идэвхгүй кластер горимд ажиллахын тулд харилцааны мэдээллийн сан дахь өгөгдлийн тууштай байдлыг хангах шаардлагатай - мэдээллийн сангийн зангилаа хоёулаа өөр өөр гео-тархагдсан мэдээллийн төвүүдийн хооронд синхроноор хуулбарлагдах ёстой.
Гэмтэлд тэсвэртэй суурилуулалтын хамгийн энгийн жишээ.
Нэг кластер ашиглахын давуу тал нь юу вэ?
- Өндөр хүртээмж, гүйцэтгэл.
- Үйлдлийн горимыг дэмжих: Идэвхтэй/Идэвхтэй, Идэвхтэй/Идэвхгүй.
- Динамик масштабын боломж - контейнер виртуалчлалыг ашиглах үед.
- Төвлөрсөн удирдлага, хяналт тавих боломж.
- Төсөл дэх хэрэглэгчдийг таних/баталгаажуулах/зөвшөөрөх нэгдсэн арга.
- Хэрэглэгчийн оролцоогүйгээр өөр өөр төслүүдийн хоорондын илүү ил тод харилцан үйлчлэл.
- JWT жетоныг янз бүрийн төслүүдэд дахин ашиглах чадвар.
- Итгэлийн нэг цэг.
- Микро үйлчилгээ/контейнер виртуалчлалыг ашиглан төслүүдийг хурдан эхлүүлэх (нэмэлт бүрэлдэхүүн хэсгүүдийг суулгах, тохируулах шаардлагагүй).
- Худалдагчаас арилжааны дэмжлэг авах боломжтой.
Кластер төлөвлөхдөө юуг анхаарах вэ
DBMS
Keycloak нь хадгалахын тулд DBMS удирдлагын системийг ашигладаг: хүрээ, үйлчлүүлэгч, хэрэглэгчид гэх мэт.
Өргөн хүрээний DBMS дэмждэг: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak нь өөрийн суурилагдсан харилцааны мэдээллийн сантай ирдэг. Хөгжүүлэлтийн орчин гэх мэт ачаалалгүй орчинд ашиглахыг зөвлөж байна.
Идэвхтэй/Идэвхтэй, Идэвхтэй/Идэвхгүй кластерийн горимд ажиллахын тулд харилцааны мэдээллийн сан дахь өгөгдлийн нийцтэй байдлыг хангах шаардлагатай бөгөөд мэдээллийн сангийн кластерын хоёр зангилаа өгөгдлийн төвүүдийн хооронд синхроноор хуулбарлагдана.
Тархсан кэш (Infinspan)
Кластер зөв ажиллахын тулд JBoss Data Grid ашиглан дараах кэш төрлийн нэмэлт синхрончлол шаардлагатай.
Баталгаажуулах сесс - тодорхой хэрэглэгчийг баталгаажуулах үед өгөгдөл хадгалахад ашигладаг. Энэ кэшийн хүсэлт нь ихэвчлэн програм биш зөвхөн хөтөч болон Keycloak сервертэй холбоотой байдаг.
Үйлдлийн токенууд - хэрэглэгч үйлдлийг асинхроноор баталгаажуулах шаардлагатай хувилбаруудад ашиглагддаг (имэйлээр). Жишээлбэл, нууц үгээ мартсан үед Infinispan actionTokens кэш нь аль хэдийн ашиглагдсан холбогдох үйлдлийн токенуудын мета өгөгдлийг хянахад ашиглагддаг тул үүнийг дахин ашиглах боломжгүй.
Байнгын өгөгдлийг кэшлэх, хүчингүй болгох – өгөгдлийн санд шаардлагагүй асуулга хийхээс зайлсхийхийн тулд байнгын өгөгдлийг кэш хийхэд ашигладаг. Аливаа Keycloak сервер өгөгдлийг шинэчлэх үед бүх дата төвийн бусад бүх Keycloak серверүүд энэ талаар мэдэх ёстой.
Ажил - Зөвхөн кластерийн зангилаа болон дата төвүүдийн хооронд хүчингүй болсон тухай мессеж илгээхэд ашиглагддаг.
Хэрэглэгчийн сессүүд - хэрэглэгчийн хөтөчийн сессийн хугацаанд хүчинтэй байгаа хэрэглэгчийн сешнүүдийн талаарх мэдээллийг хадгалахад ашигладаг. Кэш нь эцсийн хэрэглэгч болон програмын HTTP хүсэлтийг боловсруулах ёстой.
Харгис хүчний хамгаалалт - бүтэлгүйтсэн нэвтрэлтийн талаарх мэдээллийг хянахад ашигладаг.
Ачааллыг тэнцвэржүүлэх
Ачаалал тэнцвэржүүлэгч нь түлхүүрийг хаах нэг цэг бөгөөд наалттай сессийг дэмжих ёстой.
Хэрэглээний серверүүд
Эдгээр нь бүрэлдэхүүн хэсгүүдийн харилцан үйлчлэлийг хянахад ашиглагддаг бөгөөд одоо байгаа автоматжуулалтын хэрэгслүүд болон дэд бүтцийн автоматжуулалтын хэрэгслүүдийн динамик масштабыг ашиглан виртуалчлах эсвэл контейнержүүлж болно. OpenShift, Kubernates, Rancher-д байршуулах хамгийн түгээмэл хувилбарууд.
Энэ нь эхний хэсэг болох онолын хэсгийг дуусгаж байна. Дараах цуврал нийтлэлүүдэд янз бүрийн таних үйлчилгээ үзүүлэгчидтэй нэгтгэх жишээ, тохиргооны жишээг авч үзэх болно.
Эх сурвалж: www.habr.com