ในบริษัทขนาดใหญ่ใดๆ และ X5 Retail Group ก็ไม่มีข้อยกเว้น เนื่องจากมีการพัฒนา จำนวนโครงการที่ต้องมีการอนุญาตจากผู้ใช้จึงเพิ่มขึ้น เมื่อเวลาผ่านไป จำเป็นต้องมีการเปลี่ยนผู้ใช้จากแอปพลิเคชันหนึ่งไปยังอีกแอปพลิเคชันหนึ่งอย่างราบรื่น จากนั้นจึงจำเป็นต้องใช้เซิร์ฟเวอร์ Single-Sing-On (SSO) เดียว แต่จะเกิดอะไรขึ้นเมื่อผู้ให้บริการข้อมูลประจำตัว เช่น AD หรืออื่นๆ ที่ไม่มีแอตทริบิวต์เพิ่มเติมถูกใช้ในโครงการต่างๆ แล้ว ระบบที่เรียกว่า "นายหน้าระบุตัวตน" จะมาช่วย ฟังก์ชั่นที่ใช้งานได้มากที่สุดคือตัวแทนของมัน เช่น Keycloak, Gravitee Access Management เป็นต้น ส่วนใหญ่กรณีการใช้งานอาจแตกต่างกัน: การโต้ตอบกับเครื่อง การมีส่วนร่วมของผู้ใช้ ฯลฯ โซลูชันต้องรองรับฟังก์ชันที่ยืดหยุ่นและปรับขนาดได้ซึ่งสามารถรวมความต้องการทั้งหมดไว้ในที่เดียว และโซลูชันดังกล่าว ขณะนี้บริษัทของเรามีโบรกเกอร์บ่งชี้ - Keycloak
Keycloak เป็นผลิตภัณฑ์ระบุตัวตนแบบโอเพ่นซอร์สและการควบคุมการเข้าถึงที่ดูแลโดย RedHat เป็นพื้นฐานสำหรับผลิตภัณฑ์ของบริษัทโดยใช้ SSO - RH-SSO
แนวคิดพื้นฐาน
ก่อนที่คุณจะเริ่มจัดการกับวิธีแก้ปัญหาและแนวทางต่างๆ คุณควรตัดสินใจในแง่ของเงื่อนไขและลำดับของกระบวนการ:
บัตรประจำตัว เป็นขั้นตอนสำหรับการจดจำหัวเรื่องด้วยตัวระบุ (อีกนัยหนึ่ง นี่คือคำจำกัดความของชื่อ ล็อกอิน หรือหมายเลข)
การรับรอง - นี่คือขั้นตอนการตรวจสอบสิทธิ์ (ผู้ใช้ถูกตรวจสอบด้วยรหัสผ่าน จดหมายถูกตรวจสอบด้วยลายเซ็นอิเล็กทรอนิกส์ ฯลฯ)
การอนุญาต - นี่คือข้อกำหนดในการเข้าถึงทรัพยากร (เช่น อีเมล)
รหัสประจำตัวนายหน้า
พวงกุญแจ เป็นโซลูชันการจัดการข้อมูลประจำตัวและการเข้าถึงแบบโอเพ่นซอร์สที่ออกแบบมาเพื่อใช้ใน IS ซึ่งสามารถใช้รูปแบบสถาปัตยกรรมไมโครเซอร์วิสได้
Keycloak นำเสนอคุณสมบัติต่างๆ เช่น การลงชื่อเพียงครั้งเดียว (SSO), ข้อมูลประจำตัวผ่านนายหน้าและการเข้าสู่ระบบโซเชียล, สหพันธ์ผู้ใช้, อะแดปเตอร์ไคลเอ็นต์, คอนโซลผู้ดูแลระบบ และคอนโซลการจัดการบัญชี
ฟังก์ชันพื้นฐานที่สนับสนุนโดย Keycloak:
- การลงชื่อเพียงครั้งเดียวและลงชื่อออกเพียงครั้งเดียวสำหรับแอปพลิเคชันเบราว์เซอร์
- รองรับ OpenID/OAuth 2.0/SAML
- Identity Brokering - การรับรองความถูกต้องโดยใช้ OpenID Connect ภายนอกหรือผู้ให้บริการข้อมูลประจำตัว SAML
- การเข้าสู่ระบบโซเชียล - Google, GitHub, Facebook, Twitter รองรับการระบุตัวตนของผู้ใช้
- User Federation - การซิงโครไนซ์ผู้ใช้จากเซิร์ฟเวอร์ LDAP และ Active Directory และผู้ให้บริการข้อมูลประจำตัวอื่นๆ
- สะพาน Kerberos - ใช้เซิร์ฟเวอร์ Kerberos สำหรับการตรวจสอบผู้ใช้โดยอัตโนมัติ
- คอนโซลผู้ดูแลระบบ - สำหรับการจัดการแบบรวมศูนย์ของการตั้งค่าและตัวเลือกโซลูชันผ่านทางเว็บ
- คอนโซลการจัดการบัญชี - สำหรับการจัดการโปรไฟล์ผู้ใช้ด้วยตนเอง
- การปรับแต่งโซลูชันตามเอกลักษณ์องค์กรของบริษัท
- การรับรองความถูกต้อง 2FA - รองรับ TOTP/HOTP โดยใช้ Google Authenticator หรือ FreeOTP
- ขั้นตอนการเข้าสู่ระบบ - ผู้ใช้ลงทะเบียนด้วยตนเอง กู้คืนและรีเซ็ตรหัสผ่าน และอื่นๆ ได้
- การจัดการเซสชัน - ผู้ดูแลระบบสามารถจัดการเซสชันของผู้ใช้ได้จากจุดเดียว
- Token Mappers - เชื่อมโยงแอ็ตทริบิวต์ของผู้ใช้ บทบาท และแอ็ตทริบิวต์ที่จำเป็นอื่นๆ กับโทเค็น
- การจัดการนโยบายที่ยืดหยุ่นทั่วทั้งขอบเขต แอปพลิเคชัน และผู้ใช้
- การสนับสนุน CORS - ไคลเอนต์อะแด็ปเตอร์มีการสนับสนุน CORS ในตัว
- Service Provider Interfaces (SPI) - SPI จำนวนมากที่ให้คุณปรับแต่งลักษณะต่างๆ ของเซิร์ฟเวอร์: ขั้นตอนการตรวจสอบสิทธิ์ ผู้ให้บริการข้อมูลประจำตัว การแมปโปรโตคอล และอื่นๆ
- ไคลเอนต์อะแด็ปเตอร์สำหรับแอปพลิเคชัน JavaScript, WildFly, JBoss EAP, Fuse, Tomcat, Jetty, Spring
- รองรับการทำงานกับแอพพลิเคชั่นต่างๆ ที่รองรับ OpenID Connect Relying Party library หรือ SAML 2.0 Service Provider Library
- ขยายได้โดยใช้ปลั๊กอิน
สำหรับกระบวนการ CI / CD รวมถึงระบบอัตโนมัติของกระบวนการจัดการใน Keycloak สามารถใช้ REST API / JAVA API ได้ เอกสารมีให้ทางอิเล็กทรอนิกส์:
REST API
จาวา เอพีไอ
ผู้ให้บริการข้อมูลประจำตัวองค์กร (ในองค์กร)
ความสามารถในการตรวจสอบผู้ใช้ผ่านบริการ User Federation
นอกจากนี้ยังสามารถใช้การรับรองความถูกต้องแบบพาสทรูได้ หากผู้ใช้ตรวจสอบสิทธิ์บนเวิร์กสเตชันด้วย 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
ขั้นตอนรหัสการให้สิทธิ์ - ใช้กับแอปพลิเคชันฝั่งเซิร์ฟเวอร์ ประเภทของสิทธิ์การอนุญาตที่พบได้บ่อยที่สุดประเภทหนึ่ง เนื่องจากเหมาะสำหรับแอปพลิเคชันเซิร์ฟเวอร์ที่ซอร์สโค้ดของแอปพลิเคชันและข้อมูลไคลเอ็นต์ไม่พร้อมใช้งานสำหรับบุคคลภายนอก กระบวนการในกรณีนี้ขึ้นอยู่กับการเปลี่ยนเส้นทาง แอปพลิเคชันต้องสามารถสื่อสารกับตัวแทนผู้ใช้ (user-agent) เช่น เว็บเบราว์เซอร์ - เพื่อรับรหัสอนุญาต API ที่เปลี่ยนเส้นทางผ่านตัวแทนผู้ใช้
การไหลโดยปริยาย - ใช้โดยแอปพลิเคชันมือถือหรือเว็บ (แอปพลิเคชันที่ทำงานบนอุปกรณ์ของผู้ใช้)
ประเภทการอนุญาตโดยปริยายถูกใช้โดยแอปพลิเคชันมือถือและเว็บซึ่งไม่สามารถรับประกันการรักษาความลับของลูกค้าได้ ประเภทการอนุญาตโดยปริยายยังใช้การเปลี่ยนเส้นทางตัวแทนผู้ใช้ โดยที่โทเค็นการเข้าถึงจะถูกส่งผ่านไปยังตัวแทนผู้ใช้เพื่อใช้ในแอปพลิเคชันต่อไป ซึ่งจะทำให้โทเค็นพร้อมใช้งานสำหรับผู้ใช้และแอปพลิเคชันอื่นๆ บนอุปกรณ์ของผู้ใช้ การอนุญาตการให้สิทธิ์ประเภทนี้ไม่ได้ตรวจสอบตัวตนของแอปพลิเคชัน และกระบวนการนั้นใช้ URL การเปลี่ยนเส้นทาง (ก่อนหน้านี้ลงทะเบียนกับบริการ)
Implicit Flow ไม่รองรับโทเค็นการรีเฟรชโทเค็นการเข้าถึง
ข้อมูลประจำตัวของลูกค้าให้สิทธิ์โฟลว์ — ใช้เมื่อแอปพลิเคชันเข้าถึง API ประเภทของสิทธิ์การอนุญาตนี้โดยทั่วไปจะใช้สำหรับการโต้ตอบระหว่างเซิร์ฟเวอร์กับเซิร์ฟเวอร์ที่ต้องดำเนินการในเบื้องหลังโดยไม่มีการโต้ตอบจากผู้ใช้ในทันที โฟลว์การให้สิทธิ์ข้อมูลประจำตัวไคลเอ็นต์อนุญาตให้บริการเว็บ (ไคลเอ็นต์ที่เป็นความลับ) ใช้ข้อมูลรับรองของตนเองแทนการปลอมตัวเป็นผู้ใช้เพื่อตรวจสอบสิทธิ์เมื่อเรียกใช้บริการเว็บอื่น สำหรับการรักษาความปลอดภัยในระดับที่สูงขึ้น บริการการโทรสามารถใช้ใบรับรอง (แทนความลับที่แชร์) เป็นข้อมูลรับรองได้
ข้อกำหนด OAuth2 อธิบายไว้ใน
โทเค็น JWT และประโยชน์ของมัน
JWT (JSON Web Token) เป็นมาตรฐานเปิด () ที่กำหนดวิธีที่กะทัดรัดและมีทุกอย่างในตัวเองเพื่อถ่ายโอนข้อมูลอย่างปลอดภัยระหว่างฝ่ายต่างๆ เป็นอ็อบเจ็กต์ JSON
ตามมาตรฐาน โทเค็นประกอบด้วยสามส่วนในรูปแบบฐาน 64 คั่นด้วยจุด ส่วนแรกเรียกว่าส่วนหัว ซึ่งมีประเภทของโทเค็นและชื่อของอัลกอริทึมแฮชสำหรับการรับลายเซ็นดิจิทัล ส่วนที่สองเก็บข้อมูลพื้นฐาน (ผู้ใช้ คุณลักษณะ ฯลฯ) ส่วนที่สามคือลายเซ็นดิจิทัล
. .
อย่าเก็บโทเค็นไว้ในฐานข้อมูลของคุณ เนื่องจากโทเค็นที่ถูกต้องเทียบเท่ากับรหัสผ่าน การจัดเก็บโทเค็นจึงเหมือนกับการจัดเก็บรหัสผ่านในรูปแบบข้อความธรรมดา
โทเค็นการเข้าถึง เป็นโทเค็นที่ให้สิทธิ์แก่เจ้าของในการเข้าถึงทรัพยากรเซิร์ฟเวอร์ที่ปลอดภัย โดยปกติจะมีอายุการใช้งานสั้นและอาจมีข้อมูลเพิ่มเติม เช่น ที่อยู่ IP ของบุคคลที่ร้องขอโทเค็น
รีเฟรชโทเค็น เป็นโทเค็นที่อนุญาตให้ลูกค้าขอโทเค็นการเข้าถึงใหม่หลังจากอายุการใช้งานหมดอายุ โทเค็นเหล่านี้มักจะออกเป็นระยะเวลานาน
ข้อได้เปรียบหลักของการใช้งานในสถาปัตยกรรมไมโครเซอร์วิส:
- ความสามารถในการเข้าถึงแอพพลิเคชั่นและบริการต่าง ๆ ผ่านการรับรองความถูกต้องเพียงครั้งเดียว
- ในกรณีที่ไม่มีแอตทริบิวต์ที่จำเป็นจำนวนหนึ่งในโปรไฟล์ผู้ใช้ สามารถเพิ่มคุณค่าด้วยข้อมูลที่สามารถเพิ่มลงในเพย์โหลดได้ รวมถึงแบบอัตโนมัติและแบบ on-the-fly
- ไม่จำเป็นต้องเก็บข้อมูลเกี่ยวกับเซสชันที่ใช้งานอยู่ แอปพลิเคชันเซิร์ฟเวอร์จำเป็นต้องตรวจสอบลายเซ็นเท่านั้น
- การควบคุมการเข้าถึงที่ยืดหยุ่นยิ่งขึ้นผ่านแอตทริบิวต์เพิ่มเติมในเพย์โหลด
- การใช้ลายเซ็นโทเค็นสำหรับส่วนหัวและเพย์โหลดจะเพิ่มความปลอดภัยของโซลูชันโดยรวม
โทเค็น JWT - องค์ประกอบ
ชื่อเรื่อง - ตามค่าเริ่มต้น ส่วนหัวจะมีเฉพาะประเภทของโทเค็นและอัลกอริทึมที่ใช้สำหรับการเข้ารหัส
ประเภทของโทเค็นจะถูกเก็บไว้ในปุ่ม "typ" คีย์ 'type' ถูกละเว้นใน JWT หากมีคีย์ "typ" ค่าต้องเป็น JWT เพื่อระบุว่าอ็อบเจ็กต์นี้เป็น JSON Web Token
คีย์ที่สอง "alg" กำหนดอัลกอริทึมที่ใช้ในการเข้ารหัสโทเค็น ควรตั้งค่าเป็น HS256 โดยค่าเริ่มต้น ส่วนหัวถูกเข้ารหัสใน base64
{ "alg": "HS256", "ประเภท": "JWT"}
เพย์โหลด (เนื้อหา) - payload เก็บข้อมูลใด ๆ ที่จำเป็นต้องตรวจสอบ แต่ละคีย์ในเพย์โหลดเรียกว่า "การอ้างสิทธิ์" ตัวอย่างเช่น คุณสามารถเข้าสู่แอปพลิเคชันได้โดยการเชิญเท่านั้น (ปิดโปรโมชัน) เมื่อเราต้องการเชิญใครสักคนให้เข้าร่วม เราจะส่งจดหมายเชิญไปให้ สิ่งสำคัญคือต้องตรวจสอบว่าที่อยู่อีเมลเป็นของบุคคลที่ตอบรับคำเชิญ ดังนั้นเราจะรวมที่อยู่นี้ไว้ในเพย์โหลด สำหรับสิ่งนี้เราจะจัดเก็บไว้ในคีย์ "อีเมล"
{ "อีเมล": "[ป้องกันอีเมล]"}
คีย์ในเพย์โหลดสามารถกำหนดได้ตามอำเภอใจ อย่างไรก็ตาม มีข้อสงวนบางประการ:
- iss (ผู้ออก) - ระบุแอปพลิเคชันที่ส่งโทเค็น
- ย่อย (หัวเรื่อง) - กำหนดหัวเรื่องของโทเค็น
- aud (ผู้ชม) เป็นอาร์เรย์ของสตริงหรือ URI ที่คำนึงถึงตัวพิมพ์เล็กและใหญ่ซึ่งเป็นรายการของผู้รับของโทเค็นนี้ เมื่อฝั่งรับได้รับ JWT ด้วยคีย์ที่กำหนด ฝั่งนั้นจะต้องตรวจสอบการมีอยู่ของตัวเองในฝั่งผู้รับ - มิฉะนั้นไม่ต้องสนใจโทเค็น
- exp (เวลาหมดอายุ) - ระบุเมื่อโทเค็นหมดอายุ มาตรฐาน JWT กำหนดให้มีการใช้งานทั้งหมดเพื่อปฏิเสธโทเค็นที่หมดอายุ คีย์ exp ต้องเป็นการประทับเวลาในรูปแบบยูนิกซ์
- nbf (Not Before) คือเวลาในรูปแบบยูนิกซ์ที่กำหนดช่วงเวลาที่โทเค็นถูกต้อง
- iat (ออกเมื่อ) - คีย์นี้แสดงถึงเวลาที่ออกโทเค็นและสามารถใช้เพื่อกำหนดอายุของ JWT คีย์ iat ต้องเป็นการประทับเวลาในรูปแบบยูนิกซ์
- Jti (JWT ID) — สตริงที่กำหนดตัวระบุเฉพาะของโทเค็นนี้ โดยคำนึงถึงตัวพิมพ์เล็กและใหญ่
สิ่งสำคัญคือต้องเข้าใจว่าเพย์โหลดไม่ได้ถูกส่งในรูปแบบการเข้ารหัส (แม้ว่าโทเค็นสามารถซ้อนกันและจากนั้นก็สามารถส่งข้อมูลที่เข้ารหัสได้) ดังนั้นจึงไม่สามารถเก็บข้อมูลที่เป็นความลับได้ เช่นเดียวกับส่วนหัว เพย์โหลดถูกเข้ารหัสแบบเบส 64
ลายเซ็น - เมื่อเรามีชื่อและ payload แล้ว เราสามารถคำนวณลายเซ็นได้
เข้ารหัส Base64: นำส่วนหัวและเพย์โหลดมารวมกันเป็นสตริงผ่านจุด จากนั้นสตริงนี้และคีย์ลับจะถูกป้อนเข้าสู่อัลกอริทึมการเข้ารหัสที่ระบุในส่วนหัว (คีย์ "alg") คีย์สามารถเป็นสตริงใดก็ได้ สตริงที่ยาวจะเป็นที่ต้องการมากที่สุดเนื่องจากจะใช้เวลานานกว่าในการรับ
{"alg":"RSA1_5","payload":"A128CBC-HS256"}
การสร้างสถาปัตยกรรมคลัสเตอร์ Keycloak Failover
เมื่อใช้คลัสเตอร์เดียวสำหรับทุกโครงการ จะมีข้อกำหนดเพิ่มขึ้นสำหรับโซลูชัน SSO เมื่อโครงการมีจำนวนน้อย ข้อกำหนดเหล่านี้อาจไม่ชัดเจนสำหรับทุกโครงการ อย่างไรก็ตาม ด้วยจำนวนผู้ใช้และการผสานรวมที่เพิ่มขึ้น ข้อกำหนดสำหรับความพร้อมใช้งานและประสิทธิภาพก็เพิ่มขึ้น
การเพิ่มความเสี่ยงของความล้มเหลวของ SSO เดียวจะเพิ่มข้อกำหนดสำหรับสถาปัตยกรรมโซลูชันและวิธีการที่ใช้สำหรับส่วนประกอบที่ซ้ำซ้อน และนำไปสู่ SLA ที่เข้มงวดมาก ในเรื่องนี้ บ่อยครั้งในระหว่างการพัฒนาหรือช่วงเริ่มต้นของการนำโซลูชันไปใช้ โครงการต่างๆ จะมีโครงสร้างพื้นฐานที่ไม่ทนต่อข้อผิดพลาดของตนเอง เมื่อการพัฒนาดำเนินไป จำเป็นต้องวางโอกาสในการพัฒนาและปรับขนาด การสร้างคลัสเตอร์เฟลโอเวอร์มีความยืดหยุ่นมากที่สุดโดยใช้การจำลองเสมือนของคอนเทนเนอร์หรือวิธีการแบบผสมผสาน
ในการทำงานในโหมดคลัสเตอร์ Active/Active และ Active/Passive จำเป็นต้องตรวจสอบความสอดคล้องของข้อมูลในฐานข้อมูลเชิงสัมพันธ์ - โหนดฐานข้อมูลทั้งสองจะต้องจำลองแบบพร้อมกันระหว่างศูนย์ข้อมูลที่กระจายตามพื้นที่ต่างๆ
ตัวอย่างที่ง่ายที่สุดของการติดตั้งที่ทนต่อความผิดพลาด
ประโยชน์ของการใช้คลัสเตอร์เดียวคืออะไร:
- ความพร้อมใช้งานและประสิทธิภาพสูง
- รองรับโหมดการทำงาน: Active / Active, Active / Passive
- ความสามารถในการปรับขนาดแบบไดนามิก - เมื่อใช้การจำลองเสมือนของคอนเทนเนอร์
- ความเป็นไปได้ของการจัดการและการตรวจสอบแบบรวมศูนย์
- วิธีการแบบครบวงจรสำหรับการระบุตัวตน/การรับรองความถูกต้อง/การให้สิทธิ์ผู้ใช้ในโครงการ
- การโต้ตอบที่โปร่งใสมากขึ้นระหว่างโครงการต่างๆ โดยที่ผู้ใช้ไม่ต้องเกี่ยวข้อง
- ความสามารถในการใช้โทเค็น JWT ซ้ำในโครงการต่างๆ
- จุดเดียวของความไว้วางใจ
- เปิดตัวโครงการได้เร็วขึ้นโดยใช้ microservices/container virtualization (ไม่จำเป็นต้องยกและกำหนดค่าส่วนประกอบเพิ่มเติม)
- เป็นไปได้ที่จะซื้อการสนับสนุนเชิงพาณิชย์จากผู้ขาย
สิ่งที่ต้องมองหาเมื่อวางแผนคลัสเตอร์
DBMS
Keycloak ใช้ระบบจัดการฐานข้อมูลเพื่อจัดเก็บ: ขอบเขต ลูกค้า ผู้ใช้ ฯลฯ
รองรับ DBMS ที่หลากหลาย: MS SQL, Oracle, MySQL, PostgreSQL Keycloak มาพร้อมกับฐานข้อมูลเชิงสัมพันธ์ในตัวของมันเอง ขอแนะนำให้ใช้สำหรับสภาพแวดล้อมที่ไม่ได้โหลด - เช่นสภาพแวดล้อมการพัฒนา
ในการทำงานในโหมดคลัสเตอร์ Active/Active และ Active/Passive จำเป็นต้องมีความสอดคล้องของข้อมูลในฐานข้อมูลเชิงสัมพันธ์ และโหนดคลัสเตอร์ฐานข้อมูลทั้งสองจะถูกจำลองแบบพร้อมกันระหว่างศูนย์ข้อมูล
แคชแบบกระจาย (Infinspan)
เพื่อให้คลัสเตอร์ทำงานได้อย่างถูกต้อง จำเป็นต้องมีการซิงโครไนซ์เพิ่มเติมของแคชประเภทต่อไปนี้โดยใช้ JBoss Data Grid:
เซสชันการรับรองความถูกต้อง - ใช้เพื่อบันทึกข้อมูลเมื่อตรวจสอบผู้ใช้เฉพาะราย คำขอจากแคชนี้มักจะรวมเฉพาะเบราว์เซอร์และเซิร์ฟเวอร์ Keycloak ไม่ใช่แอปพลิเคชัน
โทเค็นการดำเนินการใช้สำหรับสถานการณ์ที่ผู้ใช้ต้องการยืนยันการดำเนินการแบบอะซิงโครนัส (ทางอีเมล) ตัวอย่างเช่น ระหว่างขั้นตอนการลืมรหัสผ่าน แคช actionTokens Infinispan จะถูกใช้เพื่อติดตามข้อมูลเมตาเกี่ยวกับโทเค็นการดำเนินการที่เกี่ยวข้องซึ่งถูกใช้ไปแล้ว ดังนั้นจึงไม่สามารถใช้ซ้ำได้
การแคชและการทำให้ข้อมูลถาวรไม่ถูกต้อง - ใช้เพื่อแคชข้อมูลถาวรเพื่อหลีกเลี่ยงการสืบค้นที่ไม่จำเป็นไปยังฐานข้อมูล เมื่อเซิร์ฟเวอร์ Keycloak ใด ๆ อัปเดตข้อมูล เซิร์ฟเวอร์ Keycloak อื่น ๆ ทั้งหมดในศูนย์ข้อมูลทั้งหมดจำเป็นต้องทราบเกี่ยวกับข้อมูลดังกล่าว
งาน - ใช้เพื่อส่งข้อความที่ไม่ถูกต้องระหว่างโหนดคลัสเตอร์และศูนย์ข้อมูลเท่านั้น
เซสชันผู้ใช้ - ใช้เพื่อเก็บข้อมูลเกี่ยวกับเซสชันผู้ใช้ที่ถูกต้องตามระยะเวลาเซสชันเบราว์เซอร์ของผู้ใช้ แคชต้องประมวลผลคำขอ HTTP จากผู้ใช้ปลายทางและแอปพลิเคชัน
การป้องกันการบังคับเดรัจฉาน - ใช้เพื่อติดตามข้อมูลเกี่ยวกับการเข้าสู่ระบบที่ล้มเหลว
โหลดบาลานซ์
โหลดบาลานเซอร์เป็นจุดเริ่มต้นเดียวสำหรับคีย์โคลก และต้องรองรับเซสชันที่เหนียว
เซิร์ฟเวอร์แอปพลิเคชัน
ใช้เพื่อควบคุมการโต้ตอบของส่วนประกอบต่างๆ ซึ่งกันและกัน และสามารถจำลองเสมือนหรือคอนเทนเนอร์โดยใช้เครื่องมือการทำงานอัตโนมัติที่มีอยู่และการปรับขนาดไดนามิกของเครื่องมือการทำงานอัตโนมัติของโครงสร้างพื้นฐาน สถานการณ์การปรับใช้ที่พบบ่อยที่สุดใน OpenShift, Kubernates, Rancher
นี่เป็นการสรุปส่วนแรก - ส่วนทางทฤษฎี ในบทความชุดถัดไป เราจะวิเคราะห์ตัวอย่างการผสานรวมกับผู้ให้บริการข้อมูลประจำตัวต่างๆ และตัวอย่างการตั้งค่า
ที่มา: will.com