SSO ກ່ຽວກັບສະຖາປັດຕະຍະກໍາຈຸລະພາກ. ພວກເຮົາໃຊ້ Keycloak. ສ່ວນ #1

ໃນບໍລິສັດຂະຫນາດໃຫຍ່ໃດກໍ່ຕາມ, ແລະກຸ່ມຄ້າປີກ X5 ແມ່ນບໍ່ມີຂໍ້ຍົກເວັ້ນ, ເນື່ອງຈາກການພັດທະນາກ້າວຫນ້າ, ຈໍານວນໂຄງການທີ່ຕ້ອງການການອະນຸຍາດຂອງຜູ້ໃຊ້ເພີ່ມຂຶ້ນ. ເມື່ອເວລາຜ່ານໄປ, ການຫັນປ່ຽນຂອງຜູ້ໃຊ້ຈາກແອັບພລິເຄຊັນຫນຶ່ງໄປຫາອີກອັນຫນຶ່ງແມ່ນມີຄວາມຈໍາເປັນແລະຫຼັງຈາກນັ້ນຈໍາເປັນຕ້ອງໃຊ້ເຄື່ອງແມ່ຂ່າຍ Single-Sing-On (SSO) ດຽວ. ແຕ່ສິ່ງທີ່ຕ້ອງເຮັດເມື່ອຜູ້ໃຫ້ບໍລິການຕົວຕົນເຊັ່ນ AD ຫຼືອື່ນໆທີ່ບໍ່ມີຄຸນລັກສະນະເພີ່ມເຕີມແມ່ນໃຊ້ແລ້ວໃນໂຄງການຕ່າງໆ. ຫ້ອງຮຽນຂອງລະບົບທີ່ເອີ້ນວ່າ "ນາຍຫນ້າປະຈໍາຕົວ" ຈະມາເຖິງການກູ້ໄພ. ຫນ້າທີ່ເຮັດວຽກຫຼາຍທີ່ສຸດແມ່ນຕົວແທນຂອງມັນ, ເຊັ່ນ: Keycloak, ການຈັດການ Gravitee Access, ແລະອື່ນໆ. ສ່ວນຫຼາຍມັກ, ສະຖານະການການນໍາໃຊ້ສາມາດແຕກຕ່າງກັນ: ການໂຕ້ຕອບຂອງເຄື່ອງຈັກ, ການມີສ່ວນຮ່ວມຂອງຜູ້ໃຊ້, ແລະອື່ນໆ. ການແກ້ໄຂຕ້ອງສະຫນັບສະຫນູນການທໍາງານທີ່ມີຄວາມຍືດຫຍຸ່ນແລະຂະຫນາດທີ່ສາມາດລວມເອົາຄວາມຕ້ອງການທັງຫມົດໃນຫນຶ່ງ, ແລະການແກ້ໄຂດັ່ງກ່າວບໍລິສັດຂອງພວກເຮົາໃນປັດຈຸບັນມີນາຍຫນ້າຕົວຊີ້ວັດ - Keycloak.

Keycloak ແມ່ນຕົວຕົນແຫຼ່ງເປີດແລະຜະລິດຕະພັນການຄວບຄຸມການເຂົ້າເຖິງທີ່ຮັກສາໄວ້ໂດຍ RedHat. ມັນເປັນພື້ນຖານສໍາລັບຜະລິດຕະພັນຂອງບໍລິສັດໂດຍໃຊ້ SSO - RH-SSO.

ແນວຄວາມຄິດພື້ນຖານ

ກ່ອນທີ່ທ່ານຈະເລີ່ມຕົ້ນຈັດການກັບວິທີແກ້ໄຂແລະວິທີການ, ທ່ານຄວນຕັດສິນໃຈໃນຂໍ້ກໍານົດແລະລໍາດັບຂອງຂະບວນການ:

ການກໍານົດ ແມ່ນຂັ້ນຕອນການຮັບຮູ້ຫົວຂໍ້ໃດຫນຶ່ງໂດຍຕົວລະບຸຂອງລາວ (ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ນີ້ແມ່ນຄໍານິຍາມຂອງຊື່, ເຂົ້າສູ່ລະບົບຫຼືຕົວເລກ).

ການຢືນຢັນ - ນີ້​ແມ່ນ​ຂັ້ນ​ຕອນ​ການ​ກວດ​ສອບ (ຜູ້​ໃຊ້​ໄດ້​ຖືກ​ກວດ​ສອບ​ດ້ວຍ​ລະ​ຫັດ​ຜ່ານ​, ຈົດ​ຫມາຍ​ສະ​ບັບ​ກວດ​ສອບ​ດ້ວຍ​ລາຍ​ເຊັນ​ເອ​ເລັກ​ໂຕຣ​ນິກ​, ແລະ​ອື່ນໆ​)

ການອະນຸຍາດ – ແມ່ນໃຫ້ການເຂົ້າເຖິງຊັບພະຍາກອນ (ຕົວຢ່າງ, ອີເມວ).

Keycloak Identity Broker

ກະແຈ ເປັນຕົວຕົນຂອງແຫຼ່ງເປີດ ແລະການແກ້ໄຂການຈັດການການເຂົ້າເຖິງທີ່ອອກແບບມາເພື່ອໃຊ້ໃນ IS ບ່ອນທີ່ຮູບແບບສະຖາປັດຕະຍະກຳຈຸນລະພາກສາມາດນຳໃຊ້ໄດ້.

Keycloak ສະເຫນີຄຸນນະສົມບັດເຊັ່ນການເຂົ້າສູ່ລະບົບດຽວ (SSO), ຕົວຕົນຂອງນາຍຫນ້າແລະການເຂົ້າສູ່ລະບົບສັງຄົມ, ສະຫະພັນຜູ້ໃຊ້, ຜູ້ດັດແປງລູກຄ້າ, ຄອນໂຊຜູ້ເບິ່ງແຍງແລະຄອນໂຊນການຄຸ້ມຄອງບັນຊີ.

ການທໍາງານພື້ນຖານທີ່ສະຫນັບສະຫນູນໂດຍ Keycloak:

• Single-Sign On ແລະ Single-Sign Out ສໍາລັບຄໍາຮ້ອງສະຫມັກຂອງຕົວທ່ອງເວັບ.
• ຮອງຮັບ OpenID/OAuth 2.0/SAML.
• Identity Brokering – ການກວດສອບຄວາມຖືກຕ້ອງໂດຍໃຊ້ OpenID Connect ຫຼືຜູ້ໃຫ້ບໍລິການຕົວຕົນ SAML.
• ການເຂົ້າສູ່ລະບົບສັງຄົມ - Google, GitHub, Facebook, Twitter ສະຫນັບສະຫນູນການກໍານົດຜູ້ໃຊ້.
• ສະຫະພັນຜູ້ໃຊ້ - synchronization ຂອງຜູ້ໃຊ້ຈາກເຄື່ອງແມ່ຂ່າຍຂອງ LDAP ແລະ Active Directory ແລະຜູ້ໃຫ້ບໍລິການຕົວຕົນອື່ນໆ.
• ຂົວ Kerberos - ໃຊ້ເຊີບເວີ Kerberos ສຳລັບການພິສູດຢືນຢັນຜູ້ໃຊ້ອັດຕະໂນມັດ.
• Admin Console - ສໍາລັບການຈັດການແບບປະສົມປະສານຂອງການຕັ້ງຄ່າແລະທາງເລືອກການແກ້ໄຂຜ່ານເວັບ.
• Account Management Console - ສໍາລັບການຄຸ້ມຄອງຕົນເອງຂອງໂປຣໄຟລ໌ຜູ້ໃຊ້.
• ການປັບແຕ່ງການແກ້ໄຂໂດຍອີງໃສ່ຕົວຕົນຂອງບໍລິສັດຂອງບໍລິສັດ.
• 2FA Authentication – ຮອງຮັບ TOTP/HOTP ໂດຍໃຊ້ Google Authenticator ຫຼື FreeOTP.
• ກະແສການເຂົ້າສູ່ລະບົບ - ການລົງທະບຽນຜູ້ໃຊ້ດ້ວຍຕົນເອງ, ການຟື້ນຕົວລະຫັດຜ່ານແລະການຕັ້ງຄ່າໃຫມ່, ແລະອື່ນໆແມ່ນເປັນໄປໄດ້.
• Session Management - ຜູ້ບໍລິຫານສາມາດຈັດການເຊດຊັນຂອງຜູ້ໃຊ້ຈາກຈຸດດຽວ.
• Token Mappers – ການຜູກມັດຄຸນລັກສະນະຂອງຜູ້ໃຊ້, ບົດບາດ ແລະຄຸນລັກສະນະອື່ນໆທີ່ຕ້ອງການເຂົ້າໃນ tokens.
• ການຈັດການນະໂຍບາຍແບບຍືດຫຍຸ່ນໃນທົ່ວອານາຈັກ, ແອັບພລິເຄຊັນ ແລະຜູ້ໃຊ້
• ການຊ່ວຍເຫຼືອ CORS – ຜູ້ດັດແປງລູກຄ້າມີການຮອງຮັບ CORS ພື້ນເມືອງ.
• ການໂຕ້ຕອບຜູ້ໃຫ້ບໍລິການ (SPI) - ຈໍານວນ SPIs ຈໍານວນຫລາຍທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດປັບແຕ່ງລັກສະນະຕ່າງໆຂອງເຄື່ອງແມ່ຂ່າຍ: ກະແສການພິສູດຢືນຢັນ, ຜູ້ໃຫ້ບໍລິການລະບຸຕົວຕົນ, ແຜນທີ່ໂປໂຕຄອນ, ແລະອື່ນໆ.
• ອະແດບເຕີລູກຄ້າສໍາລັບແອັບພລິເຄຊັນ JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring.
• ຮອງຮັບການເຮັດວຽກກັບແອັບພລິເຄຊັນຕ່າງໆ ທີ່ຮອງຮັບຫ້ອງສະໝຸດ OpenID Connect Relying Party ຫຼື SAML 2.0 Service Provider Library.
• ສາມາດຂະຫຍາຍໄດ້ໂດຍໃຊ້ປລັກອິນ.

ສໍາລັບຂະບວນການ CI/CD, ເຊັ່ນດຽວກັນກັບອັດຕະໂນມັດຂອງຂະບວນການຈັດການໃນ Keycloak, REST API/JAVA API ສາມາດນໍາໃຊ້ໄດ້. ເອກະສານແມ່ນມີຢູ່ໃນແບບຟອມເອເລັກໂຕຣນິກ:

REST API https://www.keycloak.org/docs-api/8.0/rest-api/index.html
Java API https://www.keycloak.org/docs-api/8.0/javadocs/index.html

ຜູ້ໃຫ້ບໍລິການລະບຸຕົວຕົນວິສາຫະກິດ (ຢູ່ໃນສະຖານທີ່)

ຄວາມເປັນໄປໄດ້ຂອງການກວດສອບຜູ້ໃຊ້ໂດຍຜ່ານການບໍລິການສະຫະພັນຜູ້ໃຊ້.

ການພິສູດຢືນຢັນຜ່ານທາງຜ່ານຍັງສາມາດຖືກນໍາໃຊ້ - ຖ້າຜູ້ໃຊ້ພິສູດຢືນຢັນກັບສະຖານີເຮັດວຽກກັບ Kerberos (LDAP ຫຼື AD), ຫຼັງຈາກນັ້ນເຂົາເຈົ້າສາມາດຖືກຢືນຢັນໂດຍອັດຕະໂນມັດກັບ Keycloak ໂດຍບໍ່ຕ້ອງໃສ່ຊື່ຜູ້ໃຊ້ແລະລະຫັດຜ່ານຂອງເຂົາເຈົ້າອີກເທື່ອຫນຶ່ງ.

ສໍາລັບການພິສູດຢືນຢັນແລະການອະນຸຍາດເພີ່ມເຕີມຂອງຜູ້ໃຊ້, ມັນເປັນໄປໄດ້ທີ່ຈະໃຊ້ DBMS ທີ່ກ່ຽວຂ້ອງ, ເຊິ່ງໃຊ້ໄດ້ຫຼາຍທີ່ສຸດສໍາລັບສະພາບແວດລ້ອມການພັດທະນາ, ເນື່ອງຈາກວ່າມັນບໍ່ກ່ຽວຂ້ອງກັບການຕັ້ງຄ່າຍາວແລະການລວມຢູ່ໃນຂັ້ນຕອນຕົ້ນຂອງໂຄງການ. ໂດຍຄ່າເລີ່ມຕົ້ນ, Keycloak ໃຊ້ DBMS ໃນຕົວເພື່ອເກັບຮັກສາການຕັ້ງຄ່າແລະຂໍ້ມູນຜູ້ໃຊ້.

ບັນຊີລາຍຊື່ຂອງ DBMS ທີ່ສະຫນັບສະຫນູນແມ່ນກວ້າງຂວາງແລະປະກອບມີ: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle ແລະອື່ນໆ. ການທົດສອບຫຼາຍທີ່ສຸດມາຮອດປະຈຸບັນແມ່ນ Oracle 12C Release1 RAC ແລະ Galera 3.12 cluster ສໍາລັບ MariaDB 10.1.19.

ຜູ້ໃຫ້ບໍລິການລະບຸຕົວຕົນ - ເຂົ້າສູ່ລະບົບສັງຄົມ

ມັນເປັນໄປໄດ້ທີ່ຈະໃຊ້ການເຂົ້າສູ່ລະບົບຈາກເຄືອຂ່າຍສັງຄົມ. ເພື່ອເປີດໃຊ້ຄວາມສາມາດໃນການກວດສອບຜູ້ໃຊ້, ໃຊ້ Keycloack admin console. ການປ່ຽນແປງລະຫັດຄໍາຮ້ອງສະຫມັກແມ່ນບໍ່ຈໍາເປັນແລະຫນ້າທີ່ນີ້ມີຢູ່ໃນກ່ອງແລະສາມາດເປີດໃຊ້ໄດ້ໃນທຸກຂັ້ນຕອນຂອງໂຄງການ.

ມັນເປັນໄປໄດ້ທີ່ຈະໃຊ້ OpenID/SAML Identity ຜູ້ໃຫ້ບໍລິການສໍາລັບການພິສູດຢືນຢັນຜູ້ໃຊ້.

ສະຖານະການອະນຸຍາດທົ່ວໄປໂດຍໃຊ້ OAuth2 ໃນ Keycloak

ກະແສລະຫັດການອະນຸຍາດ - ໃຊ້ກັບແອັບພລິເຄຊັນຂ້າງເຊີບເວີ. ຫນຶ່ງໃນປະເພດທົ່ວໄປທີ່ສຸດຂອງການອະນຸຍາດເນື່ອງຈາກວ່າມັນເຫມາະສົມດີສໍາລັບຄໍາຮ້ອງສະຫມັກເຊີຟເວີທີ່ລະຫັດແຫຼ່ງຂອງແອັບພລິເຄຊັນແລະຂໍ້ມູນລູກຄ້າບໍ່ມີໃຫ້ຄົນພາຍນອກ. ຂະບວນການໃນກໍລະນີນີ້ແມ່ນອີງໃສ່ການປ່ຽນເສັ້ນທາງ. ແອັບພລິເຄຊັນຕ້ອງສາມາດຕິດຕໍ່ສື່ສານກັບຕົວແທນຜູ້ໃຊ້ (ຜູ້ໃຊ້ - ຕົວແທນ), ເຊັ່ນ: ຕົວທ່ອງເວັບ - ເພື່ອຮັບລະຫັດການອະນຸຍາດ API ທີ່ໂອນຜ່ານຕົວແທນຜູ້ໃຊ້.

ໄຫຼ implicit — ນໍາ​ໃຊ້​ໂດຍ​ການ​ນໍາ​ໃຊ້​ໂທລະ​ສັບ​ມື​ຖື​ຫຼື​ເວັບ​ໄຊ​ຕ​໌ (ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ທີ່​ແລ່ນ​ຢູ່​ໃນ​ອຸ​ປະ​ກອນ​ຂອງ​ຜູ້​ໃຊ້​)​.

ປະເພດການອະນຸຍາດແບບ implicit ແມ່ນໃຊ້ໂດຍແອັບພລິເຄຊັນມືຖື ແລະເວັບທີ່ບໍ່ສາມາດຮັບປະກັນຄວາມລັບຂອງລູກຄ້າໄດ້. ປະເພດການອະນຸຍາດ implicit ຍັງໃຊ້ການປ່ຽນເສັ້ນທາງຕົວແທນຜູ້ໃຊ້, ເຊິ່ງ token ການເຂົ້າເຖິງແມ່ນຖືກສົ່ງໄປຫາຕົວແທນຜູ້ໃຊ້ເພື່ອນໍາໃຊ້ໃນແອັບພລິເຄຊັນຕໍ່ໄປ. ນີ້ເຮັດໃຫ້ token ມີໃຫ້ກັບຜູ້ໃຊ້ແລະແອັບພລິເຄຊັນອື່ນໆໃນອຸປະກອນຂອງຜູ້ໃຊ້. ປະເພດການອະນຸຍາດການອະນຸຍາດນີ້ບໍ່ໄດ້ຢືນຢັນຄວາມຖືກຕ້ອງຂອງຄໍາຮ້ອງສະຫມັກ, ແລະຂະບວນການຂອງມັນເອງແມ່ນອີງໃສ່ URL ການປ່ຽນເສັ້ນທາງ (ລົງທະບຽນກ່ອນຫນ້ານີ້ກັບການບໍລິການ).

Implicit Flow ບໍ່ຮອງຮັບການເຂົ້າເຖິງ token refresh token.

ກະແສການໃຫ້ຂໍ້ມູນປະຈຳຕົວລູກຄ້າ — ໃຊ້ເມື່ອແອັບພລິເຄຊັນເຂົ້າເຖິງ API. ປະເພດຂອງການອະນຸຍາດນີ້ໂດຍທົ່ວໄປແມ່ນໃຊ້ສໍາລັບການໂຕ້ຕອບຂອງເຄື່ອງແມ່ຂ່າຍກັບເຄື່ອງແມ່ຂ່າຍທີ່ຈະຕ້ອງເກີດຂຶ້ນໃນພື້ນຫລັງໂດຍບໍ່ມີການໂຕ້ຕອບຜູ້ໃຊ້ທັນທີທັນໃດ. ກະແສການໃຫ້ຂໍ້ມູນປະຈໍາຕົວລູກຄ້າອະນຸຍາດໃຫ້ບໍລິການເວັບ (ລູກຄ້າທີ່ເປັນຄວາມລັບ) ໃຊ້ຂໍ້ມູນປະຈໍາຕົວຂອງຕົນເອງແທນທີ່ຈະປອມຕົວເປັນຜູ້ໃຊ້ເພື່ອກວດສອບຄວາມຖືກຕ້ອງໃນເວລາທີ່ໂທຫາບໍລິການເວັບອື່ນ. ສໍາລັບລະດັບຄວາມປອດໄພທີ່ສູງຂຶ້ນ, ມັນເປັນໄປໄດ້ສໍາລັບການບໍລິການໂທຫາເພື່ອນໍາໃຊ້ໃບຢັ້ງຢືນ (ແທນທີ່ຈະເປັນຄວາມລັບທີ່ແບ່ງປັນ) ເປັນຂໍ້ມູນປະຈໍາ.

ຂໍ້ມູນຈໍາເພາະ OAuth2 ໄດ້ຖືກອະທິບາຍໄວ້ໃນ
RFC-6749
RFC-8252
RFC-6819

JWT token ແລະຜົນປະໂຫຍດຂອງມັນ

JWT (JSON Web Token) ແມ່ນມາດຕະຖານເປີດ (https://tools.ietf.org/html/rfc7519), ເຊິ່ງກໍານົດວິທີການທີ່ຫນາແຫນ້ນແລະເປັນຕົວຂອງມັນເອງໃນການໂອນຂໍ້ມູນລະຫວ່າງຝ່າຍຕ່າງໆຢ່າງປອດໄພໃນຮູບແບບຂອງວັດຖຸ JSON.

ອີງຕາມມາດຕະຖານ, token ປະກອບດ້ວຍສາມສ່ວນໃນຮູບແບບ base-64, ແຍກໂດຍຈຸດ. ສ່ວນທໍາອິດແມ່ນເອີ້ນວ່າ header, ເຊິ່ງປະກອບດ້ວຍປະເພດຂອງ token ແລະຊື່ຂອງ hash algorithm ສໍາລັບການໄດ້ຮັບລາຍເຊັນດິຈິຕອນ. ສ່ວນທີສອງເກັບຮັກສາຂໍ້ມູນພື້ນຖານ (ຜູ້ໃຊ້, ຄຸນລັກສະນະ, ແລະອື່ນໆ). ສ່ວນທີສາມແມ່ນລາຍເຊັນດິຈິຕອນ.

. .
ຢ່າເກັບ token ໃນ DB ຂອງທ່ານ. ເນື່ອງຈາກວ່າ token ທີ່ຖືກຕ້ອງແມ່ນທຽບເທົ່າກັບລະຫັດຜ່ານ, ການເກັບຮັກສາ token ແມ່ນຄ້າຍຄືການເກັບຮັກສາລະຫັດຜ່ານເປັນຂໍ້ຄວາມທີ່ຈະແຈ້ງ.
ໂທເຄັນການເຂົ້າເຖິງ ເປັນ token ທີ່ອະນຸຍາດໃຫ້ເຈົ້າຂອງຂອງຕົນເຂົ້າເຖິງຊັບພະຍາກອນຂອງເຄື່ອງແມ່ຂ່າຍທີ່ປອດໄພ. ປົກກະຕິແລ້ວມັນມີອາຍຸສັ້ນແລະອາດຈະປະຕິບັດຂໍ້ມູນເພີ່ມເຕີມເຊັ່ນ: ທີ່ຢູ່ IP ຂອງພາກສ່ວນທີ່ຮ້ອງຂໍ token.

ໂຫຼດໂທເຄັນຄືນໃໝ່ ເປັນ token ທີ່ອະນຸຍາດໃຫ້ລູກຄ້າສາມາດຮ້ອງຂໍໃຫ້ມີ tokens ການເຂົ້າເຖິງໃຫມ່ຫຼັງຈາກອາຍຸຂອງເຂົາເຈົ້າຫມົດອາຍຸ. ປົກກະຕິແລ້ວ tokens ເຫຼົ່ານີ້ແມ່ນອອກເປັນເວລາດົນນານ.

ຂໍ້ໄດ້ປຽບຕົ້ນຕໍຂອງການນໍາໃຊ້ໃນສະຖາປັດຕະຍະກໍາຈຸລະພາກ:

• ຄວາມ​ສາ​ມາດ​ໃນ​ການ​ເຂົ້າ​ເຖິງ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ແລະ​ການ​ບໍ​ລິ​ການ​ຕ່າງໆ​ໂດຍ​ຜ່ານ​ການ​ກວດ​ສອບ​ຄັ້ງ​ດຽວ​.
• ໃນເມື່ອບໍ່ມີຄຸນລັກສະນະທີ່ຈໍາເປັນຈໍານວນຫນຶ່ງໃນໂປຣໄຟລ໌ຜູ້ໃຊ້, ມັນເປັນໄປໄດ້ທີ່ຈະເຮັດໃຫ້ພວກເຂົາມີຂໍ້ມູນທີ່ສາມາດເພີ່ມເຂົ້າໃນ payload, ລວມທັງອັດຕະໂນມັດແລະໃນການບິນ.
• ບໍ່ຈໍາເປັນຕ້ອງເກັບຮັກສາຂໍ້ມູນກ່ຽວກັບກອງປະຊຸມທີ່ມີການເຄື່ອນໄຫວ, ຄໍາຮ້ອງສະຫມັກເຊີຟເວີພຽງແຕ່ຕ້ອງການກວດສອບລາຍເຊັນເທົ່ານັ້ນ.
• ການຄວບຄຸມການເຂົ້າເຖິງທີ່ມີຄວາມຍືດຫຍຸ່ນຫຼາຍໂດຍຜ່ານຄຸນລັກສະນະເພີ່ມເຕີມໃນ payload.
• ການນໍາໃຊ້ລາຍເຊັນ token ສໍາລັບ header ແລະ payload ເພີ່ມຄວາມປອດໄພຂອງການແກ້ໄຂທັງຫມົດ.

JWT token - ອົງປະກອບ

ຫົວຫນ້າ - ໂດຍຄ່າເລີ່ມຕົ້ນ, header ມີພຽງແຕ່ປະເພດຂອງ token ແລະ algorithm ທີ່ໃຊ້ສໍາລັບການເຂົ້າລະຫັດ.

ປະເພດຂອງ token ຖືກເກັບໄວ້ໃນປຸ່ມ "ພິມ". ປຸ່ມ 'ປະເພດ' ແມ່ນຖືກລະເລີຍຢູ່ໃນ JWT. ຖ້າປຸ່ມ "ພິມ" ປາກົດ, ຄ່າຂອງມັນຕ້ອງເປັນ JWT ເພື່ອຊີ້ບອກວ່າວັດຖຸນີ້ແມ່ນ JSON Web Token.

ຄີທີສອງ "alg" ລະບຸສູດການຄິດໄລ່ທີ່ໃຊ້ເພື່ອເຂົ້າລະຫັດ token. ໂດຍຄ່າເລີ່ມຕົ້ນມັນຄວນຈະຖືກຕັ້ງເປັນ HS256. ສ່ວນຫົວຖືກເຂົ້າລະຫັດໃນ base64.

{ "alg": "HS256", "typ": "JWT"}
payload (ເນື້ອໃນ) - payload ເກັບຮັກສາຂໍ້ມູນໃດໆທີ່ຕ້ອງການກວດສອບ. ແຕ່ລະກະແຈໃນ payload ເປັນທີ່ຮູ້ຈັກເປັນ "ການຮຽກຮ້ອງ". ຕົວຢ່າງ, ທ່ານສາມາດເຂົ້າຄໍາຮ້ອງສະຫມັກພຽງແຕ່ໂດຍການເຊື້ອເຊີນ (ປິດ promo). ເມື່ອ​ເຮົາ​ຢາກ​ເຊີນ​ຜູ້​ໃດ​ຜູ້​ໜຶ່ງ​ໃຫ້​ເຂົ້າ​ຮ່ວມ, ເຮົາ​ຈະ​ສົ່ງ​ຈົດໝາຍ​ເຊີນ​ເຂົາ​ເຈົ້າ. ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະກວດເບິ່ງວ່າທີ່ຢູ່ອີເມວເປັນຂອງຜູ້ທີ່ຍອມຮັບການເຊື້ອເຊີນ, ດັ່ງນັ້ນພວກເຮົາຈະລວມເອົາທີ່ຢູ່ນີ້ເຂົ້າໃນ payload, ສໍາລັບນີ້ພວກເຮົາເກັບໄວ້ໃນ "ອີເມວ" ທີ່ສໍາຄັນ.

{ "ອີເມວ": "[email protected]"}

ກະແຈໃນ payload ສາມາດເປັນ arbitrary. ຢ່າງໃດກໍຕາມ, ມີການສະຫງວນຈໍານວນຫນ້ອຍ:

• iss (Issuer) - ກໍານົດຄໍາຮ້ອງສະຫມັກທີ່ token ຖືກສົ່ງໄປ.
• sub (Subject) - ກໍານົດຫົວຂໍ້ຂອງ token.
• aud (ຜູ້ຊົມ) ແມ່ນ array ຂອງ strings ທີ່ລະອຽດອ່ອນຕົວພິມນ້ອຍ ຫຼື URIs ທີ່ເປັນລາຍຊື່ຂອງຜູ້ຮັບຂອງ token ນີ້. ເມື່ອຝ່າຍຮັບໄດ້ຮັບ JWT ດ້ວຍກະແຈທີ່ໃຫ້, ມັນຕ້ອງກວດເບິ່ງການມີຕົວຂອງມັນເອງຢູ່ໃນຜູ້ຮັບ - ຖ້າບໍ່ດັ່ງນັ້ນບໍ່ສົນໃຈ token.
• exp (ເວລາຫມົດອາຍຸ) - ຊີ້ໃຫ້ເຫັນເວລາທີ່ token ຫມົດອາຍຸ. ມາດຕະຖານ JWT ຮຽກຮ້ອງໃຫ້ມີການປະຕິບັດທັງຫມົດຂອງມັນເພື່ອປະຕິເສດ token ທີ່ຫມົດອາຍຸ. ລະຫັດ exp ຈະຕ້ອງເປັນ timestamp ໃນຮູບແບບ unix.
• nbf (ບໍ່ກ່ອນ) ແມ່ນເວລາໃນຮູບແບບ unix ທີ່ກໍານົດເວລາທີ່ token ກາຍເປັນທີ່ຖືກຕ້ອງ.
• iat (ອອກທີ່) - ລະຫັດນີ້ສະແດງເຖິງເວລາທີ່ອອກ token ແລະສາມາດຖືກນໍາໃຊ້ເພື່ອກໍານົດອາຍຸຂອງ JWT. ລະຫັດ iat ຈະຕ້ອງເປັນ timestamp ໃນຮູບແບບ unix.
• Jti (JWT ID) — ສະຕຣິງທີ່ກຳນົດຕົວລະບຸສະເພາະຂອງໂທເຄັນນີ້, ໂຕພິມນ້ອຍໃຫຍ່.

ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະເຂົ້າໃຈວ່າ payload ບໍ່ໄດ້ຖືກສົ່ງຜ່ານເຂົ້າລະຫັດ (ເຖິງແມ່ນວ່າ tokens ສາມາດຖືກວາງໄວ້ແລະຫຼັງຈາກນັ້ນມັນກໍ່ເປັນໄປໄດ້ທີ່ຈະສົ່ງຂໍ້ມູນທີ່ຖືກເຂົ້າລະຫັດ). ດັ່ງນັ້ນ, ທ່ານບໍ່ສາມາດເກັບຮັກສາຂໍ້ມູນລັບໃດໆຢູ່ໃນມັນ. ເຊັ່ນດຽວກັນກັບ header, payload ແມ່ນ base64 encoded.
ລາຍເຊັນ - ເມື່ອເຮົາມີຫົວຂໍ້ ແລະ ຈ່າຍແລ້ວ ເຮົາສາມາດຄິດໄລ່ລາຍເຊັນໄດ້.

Base64-encoded: header ແລະ payload ຖືກເອົາ, ພວກມັນຖືກລວມເຂົ້າກັນເປັນ string ຜ່ານຈຸດ. ຈາກນັ້ນສະຕຣິງນີ້ ແລະກະແຈລັບຈະຖືກປ້ອນເຂົ້າໃນລະບົບການເຂົ້າລະຫັດທີ່ລະບຸໄວ້ໃນສ່ວນຫົວ (ປຸ່ມ "alg"). ປຸ່ມສາມາດເປັນສາຍໃດກໍໄດ້. ສາຍທີ່ຍາວກວ່າຈະເປັນທີ່ນິຍົມທີ່ສຸດເພາະມັນຈະໃຊ້ເວລາດົນກວ່າທີ່ຈະເອົາ.

{"alg":"RSA1_5","payload":"A128CBC-HS256"}

ການສ້າງສະຖາປັດຕະຍະກໍາ Keycloak Failover Cluster

ເມື່ອນໍາໃຊ້ກຸ່ມດຽວສໍາລັບໂຄງການທັງຫມົດ, ມີຄວາມຕ້ອງການເພີ່ມຂຶ້ນສໍາລັບການແກ້ໄຂ SSO. ເມື່ອຈໍານວນໂຄງການມີຂະຫນາດນ້ອຍ, ຄວາມຕ້ອງການເຫຼົ່ານີ້ແມ່ນບໍ່ສໍາຄັນຫຼາຍສໍາລັບໂຄງການທັງຫມົດ, ຢ່າງໃດກໍຕາມ, ເນື່ອງຈາກຈໍານວນຜູ້ໃຊ້ແລະການລວມຕົວເພີ່ມຂຶ້ນ, ຄວາມຕ້ອງການສໍາລັບການມີແລະປະສິດທິພາບເພີ່ມຂຶ້ນ.

ການເພີ່ມຄວາມສ່ຽງຂອງຄວາມລົ້ມເຫຼວຂອງ SSO ດຽວເພີ່ມຄວາມຕ້ອງການສໍາລັບສະຖາປັດຕະຍະກໍາການແກ້ໄຂແລະວິທີການທີ່ໃຊ້ສໍາລັບການຊ້ໍາຊ້ອນຂອງອົງປະກອບແລະນໍາໄປສູ່ການ SLA ທີ່ເຄັ່ງຄັດຫຼາຍ. ໃນເລື່ອງນີ້, ເລື້ອຍໆໃນໄລຍະການພັດທະນາຫຼືຂັ້ນຕອນຕົ້ນຂອງການປະຕິບັດການແກ້ໄຂ, ໂຄງການຕ່າງໆມີໂຄງສ້າງພື້ນຖານທີ່ບໍ່ທົນທານຕໍ່ຄວາມຜິດຂອງຕົນເອງ. ເມື່ອ​ການ​ພັດ​ທະ​ນາ​ມີ​ຄວາມ​ຄືບ​ຫນ້າ, ມັນ​ຈໍາ​ເປັນ​ຕ້ອງ​ສ້າງ​ກາ​ລະ​ໂອ​ກາດ​ສໍາ​ລັບ​ການ​ພັດ​ທະ​ນາ​ແລະ​ຂະ​ຫຍາຍ​ຕົວ. ວິທີທີ່ມີຄວາມຍືດຫຍຸ່ນທີ່ສຸດໃນການສ້າງກຸ່ມທີ່ລົ້ມເຫລວແມ່ນການໃຊ້ container virtualization ຫຼືວິທີການປະສົມ.

ເພື່ອເຮັດວຽກຢູ່ໃນໂຫມດກຸ່ມ Active/Active ແລະ Active/Passive, ມັນຈໍາເປັນຕ້ອງຮັບປະກັນຄວາມສອດຄ່ອງຂອງຂໍ້ມູນໃນຖານຂໍ້ມູນທີ່ກ່ຽວຂ້ອງ - ທັງສອງ nodes ຖານຂໍ້ມູນຕ້ອງໄດ້ຮັບການ synchronously replicated ລະຫວ່າງສູນຂໍ້ມູນ geo-distributed ທີ່ແຕກຕ່າງກັນ.

ຕົວຢ່າງທີ່ງ່າຍດາຍທີ່ສຸດຂອງການຕິດຕັ້ງທີ່ທົນທານຕໍ່ຄວາມຜິດ.

ຜົນປະໂຫຍດຂອງການນໍາໃຊ້ກຸ່ມດຽວມີຫຍັງແດ່:

• ມີແລະປະສິດທິພາບສູງ.
• ສະຫນັບສະຫນູນຮູບແບບການດໍາເນີນງານ: Active / Active, Active / Passive.
• ຄວາມເປັນໄປໄດ້ຂອງການຂະຫຍາຍແບບເຄື່ອນໄຫວ - ເມື່ອໃຊ້ container virtualization.
• ຄວາມເປັນໄປໄດ້ຂອງການຄຸ້ມຄອງແລະການຕິດຕາມຈາກສູນກາງ.
• ວິທີການທີ່ເປັນເອກະພາບສໍາລັບການກໍານົດ / ການກວດສອບ / ອະນຸຍາດຜູ້ໃຊ້ໃນໂຄງການ.
• ການໂຕ້ຕອບທີ່ໂປ່ງໃສຫຼາຍຂຶ້ນລະຫວ່າງໂຄງການທີ່ແຕກຕ່າງກັນໂດຍບໍ່ມີການມີສ່ວນຮ່ວມຂອງຜູ້ໃຊ້.
• ຄວາມເປັນໄປໄດ້ຂອງການໃຊ້ JWT token ຄືນໃໝ່ໃນໂຄງການຕ່າງໆ.
• ຈຸດດຽວຂອງຄວາມໄວ້ວາງໃຈ.
• ການເປີດຕົວໂຄງການໄວຂຶ້ນໂດຍໃຊ້ microservices/container virtualization (ບໍ່ຈໍາເປັນຕ້ອງຕິດຕັ້ງ ແລະ configure ອົງປະກອບເພີ່ມເຕີມ).
• ມັນເປັນໄປໄດ້ທີ່ຈະຊື້ການສະຫນັບສະຫນູນທາງການຄ້າຈາກຜູ້ຂາຍ.

ສິ່ງທີ່ຕ້ອງຊອກຫາໃນເວລາວາງແຜນກຸ່ມ

DBMS

Keycloak ໃຊ້ລະບົບການຄຸ້ມຄອງຖານຂໍ້ມູນເພື່ອເກັບຮັກສາ: realms, ລູກຄ້າ, ຜູ້ໃຊ້, ແລະອື່ນໆ.
ລະດັບຄວາມກ້ວາງຂອງ DBMS ແມ່ນສະຫນັບສະຫນູນ: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak ມາພ້ອມກັບຖານຂໍ້ມູນຄວາມສໍາພັນຂອງຕົນເອງ. ມັນແນະນໍາໃຫ້ໃຊ້ສໍາລັບສະພາບແວດລ້ອມທີ່ບໍ່ມີການໂຫຼດ - ເຊັ່ນສະພາບແວດລ້ອມການພັດທະນາ.

ເພື່ອເຮັດວຽກຢູ່ໃນໂຫມດກຸ່ມ Active/Active ແລະ Active/Passive, ມັນຈໍາເປັນຕ້ອງຮັບປະກັນຄວາມສອດຄ່ອງຂອງຂໍ້ມູນໃນຖານຂໍ້ມູນທີ່ກ່ຽວຂ້ອງແລະທັງສອງ nodes ຂອງ cluster ຖານຂໍ້ມູນແມ່ນ synchronously replicated ລະຫວ່າງສູນຂໍ້ມູນ.

ແຄດແຈກຢາຍ (Infinspan)

ເພື່ອໃຫ້ກຸ່ມເຮັດວຽກຢ່າງຖືກຕ້ອງ, ການຊິ້ງຂໍ້ມູນເພີ່ມເຕີມຂອງປະເພດຖານຄວາມຈຳຕໍ່ໄປນີ້ໂດຍໃຊ້ JBoss Data Grid ແມ່ນຕ້ອງການ:

ເຊດຊັນການພິສູດຢືນຢັນ - ໃຊ້ເພື່ອບັນທຶກຂໍ້ມູນໃນເວລາພິສູດຢືນຢັນຜູ້ໃຊ້ສະເພາະ. ການຮ້ອງຂໍຈາກຖານຄວາມຈໍານີ້ໂດຍທົ່ວໄປແລ້ວມີພຽງແຕ່ຕົວທ່ອງເວັບແລະເຄື່ອງແມ່ຂ່າຍຂອງ Keycloak, ບໍ່ແມ່ນຄໍາຮ້ອງສະຫມັກ.

Action tokens ແມ່ນໃຊ້ສໍາລັບສະຖານະການທີ່ຜູ້ໃຊ້ຕ້ອງການຢືນຢັນການກະ ທຳ ແບບບໍ່ກົງກັນ (ຜ່ານອີເມວ). ຕົວຢ່າງ, ໃນລະຫວ່າງການລືມລະຫັດຜ່ານ, cache actionTokens Infinispan ຖືກນໍາໃຊ້ເພື່ອຕິດຕາມ metadata ກ່ຽວກັບ tokens ທີ່ກ່ຽວຂ້ອງທີ່ຖືກນໍາໃຊ້ແລ້ວ, ດັ່ງນັ້ນມັນບໍ່ສາມາດຖືກນໍາໃຊ້ຄືນໄດ້.

Caching ແລະ invalidation ຂອງຂໍ້ມູນຄົງທີ່ - ໃຊ້ເພື່ອ cache ຂໍ້ມູນຄົງທີ່ເພື່ອຫຼີກເວັ້ນການສອບຖາມທີ່ບໍ່ຈໍາເປັນໃນຖານຂໍ້ມູນ. ເມື່ອເຊີບເວີ Keycloak ໃດອັບເດດຂໍ້ມູນ, ເຊີບເວີ Keycloak ອື່ນໆທັງໝົດໃນສູນຂໍ້ມູນທັງໝົດຕ້ອງຮູ້ກ່ຽວກັບມັນ.

ວຽກ - ໃຊ້ເພື່ອສົ່ງຂໍ້ຄວາມທີ່ບໍ່ຖືກຕ້ອງລະຫວ່າງ nodes cluster ແລະສູນຂໍ້ມູນເທົ່ານັ້ນ.

ເຊດຊັນຜູ້ໃຊ້ - ໃຊ້ເພື່ອເກັບຂໍ້ມູນເຊດຊັນຂອງຜູ້ໃຊ້ທີ່ຖືກຕ້ອງສໍາລັບໄລຍະເວລາຂອງເຊດຊັນຂອງຕົວທ່ອງເວັບຂອງຜູ້ໃຊ້. cache ຕ້ອງຈັດການກັບການຮ້ອງຂໍ HTTP ຈາກຜູ້ໃຊ້ສຸດທ້າຍແລະແອັບພລິເຄຊັນ.

Brute force protection - ໃຊ້ເພື່ອຕິດຕາມຂໍ້ມູນກ່ຽວກັບການເຂົ້າສູ່ລະບົບທີ່ລົ້ມເຫລວ.

ການດຸ່ນດ່ຽງການໂຫຼດ

ຕົວດຸ່ນດ່ຽງການໂຫຼດແມ່ນຈຸດເຂົ້າດຽວຕໍ່ກັບ keycloak ແລະຕ້ອງສະຫນັບສະຫນູນກອງປະຊຸມຫນຽວ.

ເຊີບເວີແອັບພລິເຄຊັນ

ພວກມັນຖືກນໍາໃຊ້ເພື່ອຄວບຄຸມການໂຕ້ຕອບຂອງອົງປະກອບເຊິ່ງກັນແລະກັນແລະສາມາດ virtualized ຫຼື containerized ໂດຍໃຊ້ເຄື່ອງມືອັດຕະໂນມັດທີ່ມີຢູ່ແລ້ວແລະຂະຫນາດແບບເຄື່ອນໄຫວຂອງເຄື່ອງມືອັດຕະໂນມັດໂຄງສ້າງພື້ນຖານ. ສະຖານະການນຳໃຊ້ທົ່ວໄປທີ່ສຸດໃນ OpenShift, Kubernates, Rancher.

ນີ້ເຮັດສໍາເລັດສ່ວນທໍາອິດ - ທິດສະດີ. ໃນຊຸດຂອງບົດຄວາມຕໍ່ໄປນີ້, ຕົວຢ່າງຂອງການເຊື່ອມໂຍງກັບຜູ້ໃຫ້ບໍລິການລະບຸຕົວຕົນຕ່າງໆແລະຕົວຢ່າງຂອງການຕັ້ງຄ່າຈະຖືກປຶກສາຫາລື.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com