พื้นหลัง
เพื่อนที่เปลี่ยนจากแอพพลิเคชั่นเสาหินแบบดั้งเดิมเป็น Spring Cloud กำลังถามฉันว่าจะจัดการสิทธิ์ microservice ภายใต้ Spring Cloud ได้อย่างไร? วิธีการออกแบบที่สมเหตุสมผลมากขึ้น? จากมุมมองที่มีขนาดใหญ่เรียกว่าสิทธิ์การบริการซึ่งแบ่งออกเป็นสามส่วน:用户认证用户权限และ服务校验
การรับรองความถูกต้องของผู้ใช้
แอปพลิเคชั่นเสาหินแบบดั้งเดิมอาจคุ้นเคยกับการมีอยู่ของเซสชัน หลังจาก Microservices ของ Spring Cloud เซสชันสามารถแก้ไขได้โดยเซสชันแบบกระจาย แต่พวกเขาไม่ใช่กลยุทธ์ที่ดีที่สุด บางคนเริ่มใช้ Spring Cloud Security รวมกับ OAuth2 ซึ่งเป็นที่รู้จักกันดีในเรื่อง OAuth2 ต่อมาเพื่อเพิ่มประสิทธิภาพการจัดเก็บปัญหา Access Token ใน OAuth 2 และปรับปรุงความพร้อมใช้งานและความสามารถในการปรับขนาดของบริการแบ็คเอนด์มีวิธีการตรวจสอบโทเค็นที่ดีกว่า JWT (โทเค็น JSON Web) สิ่งหนึ่งที่จะเน้นที่นี่คือ OAuth2 และ JWT ไม่สามารถเทียบเคียงได้เลยพวกเขาเป็นสองสิ่งที่แตกต่างอย่างสิ้นเชิง
OAuth2是一种授权框架ในขณะที่ JWT เป็นโปรโตคอลการตรวจสอบสิทธิ์
OAuth2 เฟรมเวิร์กการรับรองความถูกต้อง OAuth2 มีสี่บทบาท:
OAuth2 มี 4 โหมดการอนุญาต
ในหมู่พวกเขากระบวนการดำเนินการของ OAUTH2 จะแสดงในรูปด้านล่างตัดตอนมาจาก RFC 6749:
- |-(a)-คำขอการอนุญาต-> | ทรัพยากร || - - - - เจ้าของ || | <-(b)-ทุนอนุญาต --- | - - - - - - |-(c)-ทุนการอนุญาต-> | การอนุญาต || ลูกค้า | - - เซิร์ฟเวอร์ || | <-(D) ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ทรัพยากร || - - เซิร์ฟเวอร์ || <-(f) --- ทรัพยากรที่ได้รับการป้องกัน --- | -
ใน Spring Cloud OAuth2 คำขอทั้งหมดเพื่อเข้าถึงทรัพยากร microservice พกโทเค็นในส่วนหัว HTTP บริการที่เข้าถึงจะขอให้เซิร์ฟเวอร์การอนุญาตตรวจสอบความถูกต้องของโทเค็น ด้วยวิธีนี้เราต้องการคำขอ两次或者更多次การตรวจสอบความถูกต้องของโทเค็นทั้งหมดอยู่บนเซิร์ฟเวอร์การอนุญาตซึ่งได้กลายเป็นคอขวดที่ใหญ่มากสำหรับการขยายตัวในแนวนอนของระบบของเรา
โปรโตคอลการรับรอง JWT
授权服务器ทำให้ข้อมูลผู้ใช้และขอบเขตการอนุญาตและวางสตริง JSON จากนั้นใช้ BASE64 เพื่อเข้ารหัสและในที่สุดก็ลงนามในสตริงด้วยคีย์ส่วนตัวในเซิร์ฟเวอร์การอนุญาตเพื่อรับ JSON Web Token
สมมติว่าเซิร์ฟเวอร์ทรัพยากรอื่น ๆ ทั้งหมดจะมีคีย์สาธารณะ RSA เมื่อเซิร์ฟเวอร์ทรัพยากรได้รับคำขอให้มีโทเค็นในส่วนหัว HTTP เซิร์ฟเวอร์ทรัพยากรสามารถรับโทเค็นและตรวจสอบว่าใช้ลายเซ็นส่วนตัวที่ถูกต้องหรือไม่ (ไม่ว่าจะมีการลงนามโดยเซิร์ฟเวอร์ที่ได้รับอนุญาตนั่นคือการตรวจสอบลายเซ็น) หลังจากผ่านการตรวจสอบข้อมูลการตรวจสอบที่ถูกต้องที่อยู่ใน Toekn จะได้รับหลังจาก deserialization
ในหมู่พวกเขาผังงานหลักมีดังนี้:
- - - -
ด้วยวิธีการข้างต้นเราสามารถเสร็จสิ้นการตรวจสอบผู้ใช้ตามบริการได้ดี
สิทธิ์ของผู้ใช้
ทุกคนชอบ shiro สำหรับการอนุญาตให้ปิดกั้นแอพพลิเคชั่นตัวเดียวแบบดั้งเดิมและใช้งานง่าย แต่เมื่อแยกออกแล้วการอนุญาตเริ่มกระจัดกระจายไปทั่ว API ต่างๆ shiro ยังทำงานอยู่หรือไม่? ในโครงการฉันไม่ได้ใช้ shiro หลังจากที่ด้านหน้าและด้านหลังถูกแยกออกจากกันการโต้ตอบคือโทเค็นบริการแบ็กเอนด์ไม่มีสัญลักษณ์ปุ่มส่วนหน้าจะถูกจัดหาทรัพยากรและเราจะจัดการสิทธิ์ได้ที่ไหน?
บทคัดย่อและการออกแบบ
ก่อนที่จะแนะนำการออกแบบหลักที่ยืดหยุ่นให้ฉันแนะนำแนวคิดตัวอย่างให้คุณทราบ: RBAC (การควบคุมการเข้าถึงตามบทบาทการควบคุมการเข้าถึงตามบทบาท) ซึ่งหมายความว่าผู้ใช้เชื่อมโยงกับการอนุญาตผ่านบทบาท พูดง่ายๆคือผู้ใช้มีหลายบทบาทและแต่ละบทบาทมีการอนุญาตหลายประการ
RBAC เป็นแบบจำลองการวิเคราะห์ส่วนใหญ่แบ่งออกเป็น: โมเดลพื้นฐาน RBAC0 (Core RBAC), โมเดลลำดับชั้นบทบาท RBAC1 (ลำดับชั้น RBAC), โมเดลการ จำกัด บทบาท RBAC2 (ข้อ จำกัด RBAC) และแบบจำลอง RBAC3 (รวม RBAC)
Core UML
นี่คือแผนภาพความสัมพันธ์ RBAC ที่เป็นนามธรรมของผู้เขียนหลังจากสถานการณ์ธุรกิจหลายสถานการณ์
คำอธิบายชั้นเรียน
กลุ่ม
กลุ่มหรือกลุ่มซึ่งเป็นคอลเลกชันที่มีสิทธิ์จำนวนหนึ่งสามารถเป็นพาหะของการอนุญาต
子类: ผู้ใช้ (ผู้ใช้), บทบาท (บทบาท), ตำแหน่ง (โพสต์), หน่วย (แผนก) ผ่านองค์ประกอบเฉพาะของผู้ใช้กลุ่มหรือกลุ่มของสถานการณ์ทางธุรกิจที่แตกต่างกันจะเกิดขึ้นและการอนุญาตของผู้ใช้จะได้รับผ่านการอนุญาตให้กับคลาสหลักของกลุ่มหรือกลุ่ม
การอนุญาต
การอนุญาตการรวมเข้ากับทรัพยากรจำนวนหนึ่งสามารถเป็นพาหะของทรัพยากรได้
ทรัพยากร
มีทรัพยากรภายใต้การอนุญาตและแหล่งที่มาของทรัพยากรรวมถึง: เมนู (เมนู), ปุ่ม (การอนุญาตดำเนินการ), องค์ประกอบหน้า (ปุ่ม, แท็บ, ฯลฯ ), สิทธิ์ข้อมูล ฯลฯ
โปรแกรม
โปรแกรมผู้ให้บริการเรนเดอร์สำหรับการควบคุมการอนุญาตที่เกี่ยวข้องสามารถติดตั้งในหลายเมนู
องค์ประกอบพื้นฐานของโปรแกรมเว็บทั่วไป
ความสัมพันธ์ระหว่างโมเดลและไมโครเซอ
หากอินเทอร์เฟซ API ทั้งหมดหลังจากบริการคลาวด์สปริงถูกกำหนดเป็น Resources ด้านบนเราจะเห็นสถานการณ์ดังกล่าว
ตัวอย่างเช่นหากผู้ใช้เพิ่มลบแก้ไขและตรวจสอบหน้าของเราจะทำเช่นนี้
| องค์ประกอบหน้า | การเข้ารหัสทรัพยากร | ทรัพยากร URI | วิธีการขอทรัพยากร |
|---|---|---|---|
| สอบถาม | user_btn_get | /api/user/{id} | รับ |
| เพิ่มขึ้น | user_btn_add | /API/ผู้ใช้ | โพสต์ |
| แก้ไข | user_btn_edit | /api/user/{id} | ใส่ |
| ลบ | user_btn_del | /api/user/{id} | ลบ |
หลังจากการสรุปความสัมพันธ์การแมปข้างต้นทรัพยากรด้านหน้าและด้านหลังของเราจะถูกอ้างอิงทำให้เราสามารถอนุญาตให้มีการอนุญาตกลุ่มผู้ใช้ได้ง่ายขึ้น ตัวอย่างเช่นฉันให้สิทธิ์ผู้ใช้เพื่อเพิ่มและลบ ใน前端เราจำเป็นต้องตรวจสอบว่า资源编码มีอยู่หรือไม่เพื่อควบคุมการแสดงผลและการซ่อนปุ่มในขณะที่后端เราจำเป็นต้องสกัดกั้นอย่างสม่ำเสมอและตรวจสอบว่าผู้ใช้มี URI และ请求方式ที่สอดคล้องกัน
สำหรับว่าการสกัดกั้นการอนุญาตแบบรวมอยู่บนเกตเวย์ Zuul หรือบนสกัดกั้นของบริการแบ็กเอนด์ที่เฉพาะเจาะจง (ตัวกรอง, ตัวรับสัญญาณ) สามารถนำไปใช้ได้อย่างง่ายดาย ไม่ จำกัด เพียงการรุกรานของรหัส ผังงานของการวาง Zuul มีดังนี้:
หากการสกัดกั้นแบบครบวงจรของการอนุญาตถูกวางไว้บน Zuul จะมีปัญหานั่นคือไม่ว่าบริการแบ็คเอนด์จะปลอดภัยหรือไม่และบริการจะต้องเรียกผ่านศูนย์ลงทะเบียนหรือไม่ สิ่งนี้เกี่ยวข้องกับโมดูลที่สามที่อยู่เบื้องหลังการรับรองความถูกต้องระหว่างบริการ
การรับรองความถูกต้องระหว่างบริการ
เพราะเราทุกคนรู้ว่าบริการนี้เรียกว่าขั้นตอนระยะไกลโดยตรงหลังจากที่พวกเขาพบลูกค้าผ่านศูนย์ลงทะเบียน เราจำเป็นต้องปกป้องแต่ละบริการและอินเทอร์เฟซที่ละเอียดอ่อนในการผลิต กระบวนการของหัวข้อมีดังนี้:
วิธีการใช้งานของผู้เขียนขึ้นอยู่กับ FeignClient Inteceprot ของ Spring Cloud (ใช้สำหรับโทเค็นบริการโดยอัตโนมัติส่งผ่านบริบทปัจจุบัน) และ Mvc Inteceptor (การตรวจสอบโทเค็นบริการอัปเดตบริบทปัจจุบัน) เพื่อป้องกันความปลอดภัยของบริการต่อไป
หลังจากรวมคุณสมบัติของสปริงเมฆแผนภูมิการไหลโดยรวมมีดังนี้:
จุดเพิ่มประสิทธิภาพ
แม้ว่าความปลอดภัยของอินเทอร์เฟซ API จะได้รับการรับรองผ่านการตรวจสอบความถูกต้องตามกฎหมาย Http访问频率ผู้ใช้ที่กล่าวถึงข้างต้น เมื่อจำนวนคำขอเพิ่มขึ้นปัญหาของ慢จะชัดเจนเป็นพิเศษ กลยุทธ์การเพิ่มประสิทธิภาพบางอย่างสามารถพิจารณาได้เช่นแคชการอนุญาตผู้ใช้การกระจายและการจัดเก็บข้อมูลการอนุมัติการบริการแบบผสมและการรีเฟรชโทเค็นการตรวจสอบความถูกต้องของบริการเป็นประจำ
บทสรุป
ข้างต้นเป็นแนวคิดทั่วไปของฉันในโครงการ เพื่อนที่สนใจสามารถเรียนรู้จากโครงการโอเพ่นซอร์สของฉัน ยินดีต้อนรับสู่ Star:
- Gitchina: https://gitee.com/minull/ace-security (JWT, สิทธิ์ผู้ใช้)
- gitHub: https://github.com/wxiaoqi/ace-security
- Gitchina: http://git.oschina.net/geek_qi/ace-gate (การตรวจสอบบริการ)
ข้างต้นเป็นเนื้อหาทั้งหมดของบทความนี้ ฉันหวังว่ามันจะเป็นประโยชน์ต่อการเรียนรู้ของทุกคนและฉันหวังว่าทุกคนจะสนับสนุน wulin.com มากขึ้น