RBAC ในการปฏิบัติ: การสร้างการอนุญาตที่ปลอดภัยสำหรับแอปพลิเคชันของคุณ

คุณกำลังประสบปัญหาในการสร้างระบบการอนุญาตที่ปลอดภัยและสามารถขยายได้สำหรับแอปพลิเคชันของคุณหรือไม่? การควบคุมการเข้าถึงตามบทบาท (RBAC) เป็นมาตรฐานอุตสาหกรรมสำหรับการจัดการสิทธิ์ของผู้ใช้ แต่การทำให้ถูกต้องอาจเป็นเรื่องท้าทาย บทเรียนนี้จะแสดงวิธีการสร้างระบบ RBAC ที่แข็งแกร่งโดยใช้ตัวอย่างระบบการจัดการเนื้อหาจริง (CMS)

ด้วยการทำตามไกด์นี้ คุณจะได้เรียนรู้:

• ✨ วิธีการออกแบบและใช้สิทธิ์ที่ละเอียดยิบที่ให้คุณมีการควบคุมที่แม่นยำ
• 🔒 วิธีที่ดีที่สุดในการจัดระเบียบสิทธิ์ให้เป็นบทบาทที่มีความหมาย
• 👤 เทคนิคในการจัดการทรัพยากรอย่างมีประสิทธิภาพ
• 🚀 วิธีทำให้ระบบการอนุญาตของคุณสามารถขยายและบำรุงรักษาได้
• 💡 การใช้งานที่เป็นประโยชน์โดยใช้ตัวอย่าง CMS จริง

โค้ดต้นฉบับทั้งหมดสำหรับบทเรียนนี้มีอยู่บน GitHub

การเข้าใจพื้นฐานของ RBAC#

การควบคุมการเข้าถึงตามบทบาทมากกว่าการกำหนดสิทธิ์ให้ผู้ใช้ เป็นการสร้างวิธีการเชิงโครงสร้างเพื่อการอนุญาตที่สมดุลความปลอดภัยกับการบำรุงรักษา

คุณสามารถเรียนรู้เพิ่มเติมเกี่ยวกับ What is RBAC ใน Auth Wiki

นี่คือหลักการสำคัญที่เราจะปฏิบัติตามในการนำไปใช้:

การออกแบบสิทธิ์ที่ละเอียดยิบ#

สิทธิ์ที่ละเอียดยิบให้คุณมีการควบคุมที่แม่นยำว่า ผู้ใช้สามารถทำอะไรได้บ้างในระบบของคุณ แทนที่จะใช้ระดับการเข้าถึงกว้างๆ เช่น "admin" หรือ "user" เรากำหนดการกระทำเฉพาะที่ผู้ใช้สามารถทำได้บนทรัพยากร ตัวอย่างเช่น:

• read:articles - ดูบทความในระบบ
• create:articles - สร้างบทความใหม่
• update:articles - แก้ไขบทความที่มีอยู่
• publish:articles - เปลี่ยนสถานะการเผยแพร่ของบทความ

การเป็นเจ้าของทรัพยากรและการควบคุมการเข้าถึง#

การเป็นเจ้าของทรัพยากรเป็นแนวคิดพื้นฐานในการออกแบบการอนุญาตของ CMS ของเรา ในขณะที่ RBAC กำหนดว่าบทบาทต่างๆ สามารถทำการกระทำใดได้บ้าง เจ้าของเพิ่มมิติส่วนตัวในการควบคุมการเข้าถึง:

• ผู้เขียนจะสามารถเข้าถึงบทความที่พวกเขาสร้างได้โดยอัตโนมัติ
• โมเดลการเป็นเจ้าของที่เป็นธรรมชาติหมายความว่าผู้เขียนสามารถดูและแก้ไขเนื้อหาของตนเองได้เสมอ
• ระบบจะตรวจทั้งสิทธิ์ตามบทบาทหรือการเป็นเจ้าของเมื่อจัดการการทำงานของบทความ
• ตัวอย่างเช่น แม้ไม่มีสิทธิ์ update:articles ผู้เขียนยังคงสามารถแก้ไขบทความของตนเองได้
• ดีไซน์นี้ลดความจำเป็นสำหรับสิทธิ์บทบาทเพิ่มเติมในขณะที่ยังคงความปลอดภัย

วิธีการสองชั้นนี้ (บทบาท + การเป็นเจ้าของ) สร้างระบบที่มีสัญชาตญาณและปลอดภัยขึ้น ผู้เผยแพร่และผู้ดูแลยังคงสามารถจัดการเนื้อหาทั้งหมดผ่านสิทธิ์บทบาทของพวกเขาในขณะที่ผู้เขียนยังคงควบคุมงานของตนเองได้

การออกแบบ API ที่ปลอดภัย#

เริ่มต้นด้วยการออกแบบฟังก์ชั่นหลักของ CMS ผ่าน API endpoints ของมัน:

การใช้การควบคุมการเข้าถึงสำหรับ API ของคุณ#

สำหรับแต่ละ endpoint เราจำเป็นต้องพิจารณาสองแง่มุมของการควบคุมการเข้าถึง:

1. การเป็นเจ้าของทรัพยากร - ผู้ใช้เป็นเจ้าของทรัพยากรนี้หรือไม่?
2. สิทธิ์ตามบทบาท - บทบาทของผู้ใช้อนุญาตการทำงานนี้หรือไม่?

นี่คือวิธีที่เราจะจัดการการเข้าถึงสำหรับแต่ละ endpoint:

การสร้างระบบสิทธิ์ที่ขยายได้#

ตามความต้องการของ API เราสามารถกำหนดสิทธิ์เหล่านี้:

สังเกตว่าสิทธิ์เหล่านี้ต้องการเพียงเมื่อเข้าถึงทรัพยากรที่คุณไม่ได้เป็นเจ้าของ ผู้เป็นเจ้าของบทความสามารถทำได้โดยอัตโนมัติ:

• ดูบทความของตนเอง (ไม่จำเป็นต้องใช้ read:articles)
• แก้ไขบทความของตนเอง (ไม่จำเป็นต้องใช้ update:articles)
• ลบบทความของตนเอง (ไม่จำเป็นต้องใช้ delete:articles)

การสร้างบทบาทที่มีประสิทธิภาพ#

เมื่อเรากำหนด API และสิทธิ์เสร็จแล้ว เราสามารถสร้างบทบาทที่รวบรวมสิทธิ์เหล่านี้อย่างมีเหตุผล:

หมายเหตุ: ผู้เขียนมีสิทธิ์ read/update/delete บทความของตนเองโดยอัตโนมัติ โดยไม่คำนึงถึงสิทธิ์บทบาท

แต่ละบทบาทถูกออกแบบด้วยความรับผิดชอบเฉพาะ:

• ผู้ดูแลระบบ: มีการควบคุม CMS ทั้งหมดรวมถึงการทำงานของบทความทั้งหมด
• ผู้เผยแพร่: เน้นการทบทวนเนื้อหาและการจัดการการเผยแพร่
• ผู้เขียน: เชี่ยวชาญในการสร้างเนื้อหา

โครงสร้างบทบาทนี้สร้างการแยกแยะความรับผิดชอบที่ชัดเจน:

• ผู้เขียนมุ่งเน้นการสร้างเนื้อหา
• ผู้เผยแพร่จัดการคุณภาพและความเห็นของเนื้อหา
• ผู้ดูแลระบบดูแลการควบคุมระบบทั้งหมด

การตั้งค่า RBAC ใน Logto#

ก่อนที่คุณจะเริ่ม คุณจำเป็นต้องสร้างบัญชีใน Logto Cloud หรือคุณสามารถใช้ Logto ด้วยตัวเองโดยใช้ Logto OSS version

แต่สำหรับบทเรียนนี้เราจะใช้ Logto Cloud เพื่อความสะดวก

การตั้งค่าแอปพลิเคชันของคุณ#

1. ไปที่ "แอปพลิเคชัน" ใน Logto Console เพื่อสร้างแอปพลิเคชัน react ใหม่
   • ชื่อแอปพลิเคชัน: ระบบการจัดการเนื้อหา
   • ประเภทแอปพลิเคชัน: แอปพลิเคชันเว็บแบบดั้งเดิม
   • Redirect URIs: http://localhost:5173/callback

การกำหนดค่า API ทรัพยากรและสิทธิ์#

1. ไปที่ "ทรัพยากร API" ใน Logto Console เพื่อสร้างทรัพยากร API ใหม่
   • ชื่อ API: CMS API
   • ตัวระบุ API: https://api.cms.com
   • เพิ่มสิทธิ์ในการเข้าถึง API ทรัพยากร
     • list:articles
     • read:articles
     • create:articles
     • update:articles
     • publish:articles
     • delete:articles

การสร้างบทบาท#

ไปที่บทบาทใน Logto Console เพื่อสร้างบทบาทต่อไปนี้สำหรับ CMS

• ผู้ดูแลระบบ
  • ด้วยสิทธิ์ทั้งหมด
• ผู้เผยแพร่
  • ด้วย read:articles, list:articles, publish:articles
• ผู้เขียน
  • ด้วย create:articles

การมอบบทบาทให้กับผู้ใช้#

ไปที่ส่วน "การจัดการผู้ใช้" ใน Logto Console เพื่อสร้างผู้ใช้

ในแท็บ "บทบาท" ของรายละเอียดผู้ใช้ คุณสามารถมอบบทบาทให้กับผู้ใช้ได้

ในตัวอย่างของเรา เราสร้างผู้ใช้ 3 คนพร้อมบทบาทดังนี้:

• Alex: ผู้ดูแลระบบ
• Bob: ผู้เผยแพร่
• Charlie: ผู้เขียน

การรวมส่วนหน้าเข้ากับ Logto RBAC#

ตอนนี้เราได้ตั้งค่า RBAC ใน Logto แล้ว เราสามารถเริ่มรวมเข้ากับส่วนหน้า

ก่อนอื่น ทำตาม Logto Quick Starts เพื่อรวม Logto เข้ากับแอปพลิเคชันของคุณ

ในตัวอย่างของเรา เราใช้ React เพื่อตัวอย่าง

หลังจากที่คุณได้ติดตั้ง Logto ในแอปพลิเคชันของคุณแล้ว เราจำเป็นต้องเพิ่มการกำหนดค่า RBAC เพื่อให้ Logto ใช้งานได้

อย่าลืมออกจากระบบและเข้าสู่ระบบใหม่เพื่อให้การเปลี่ยนแปลงนี้มีผลหากคุณได้เข้าสู่ระบบแล้ว

เวลาที่ผู้ใช้ลงชื่อเข้าใช้ด้วย Logto และขอเครื่องหมายการเข้าถึงสำหรับทรัพยากร API ที่ระบุด้านบน Logto จะเพิ่มขอบเขต (สิทธิ์) ที่เกี่ยวข้องกับบทบาทของผู้ใช้ลงในเครื่องหมายการเข้าถึง

คุณสามารถใช้ getAccessTokenClaims จากฮุก useLogto เพื่อดึงขอบเขตจากเครื่องหมายการเข้าถึง

และคุณสามารถใช้ userScopes เพื่อตรวจสอบว่าผู้ใช้มีสิทธิ์ในการเข้าถึงทรัพยากรหรือไม่

การรวมส่วนหลังเข้ากับ Logto RBAC#

ตอนนี้ถึงเวลาในการรวม Logto RBAC เข้ากับส่วนหลังของคุณ

มิดเดิลแวร์การอนุญาตในส่วนหลัง#

ก่อนอื่น เราจำเป็นต้องเพิ่มมิดเดิลแวร์ในส่วนหลัง เพื่อตรวจสอบสิทธิ์ของผู้ใช้ ตรวจสอบว่าผู้ใช้ได้เข้าสู่ระบบหรือไม่ และตรวจสอบว่าพวกเขามีสิทธิ์ที่จำเป็นในการเข้าถึง API บางอย่างหรือไม่

ในส่วนของมิดเดิลแวร์นี้ เราตรวจสอบว่าคำขอจากส่วนหน้ามีเครื่องหมายการเข้าถึงที่ถูกต้องหรือไม่ และตรวจสอบว่าผู้ใช้มีสิทธิ์ที่จำเป็นในการเข้าถึง API บางอย่างหรือไม่

เหตุผลที่เราตรวจสอบทรัพยากร API เนื่องจากทรัพยากร API ของเราจริงๆ แล้วแทนทรัพยากรของส่วนหลัง CMS ของเรา และสิทธิ์การเข้าถึง CMS ทั้งหมดของเราถูกเชื่อมโยงกับทรัพยากร API นี้

เนื่องจากทรัพยากร API นี้แทนทรัพยากร CMS ใน Logto ในโค้ดส่วนหน้าของเรา เราจึงเพิ่มเครื่องหมายเข้าถึงที่สอดคล้องกันเมื่อทำการร้องขอ API ไปยังส่วนหลัง:

ตอนนี้เราสามารถใช้มิดเดิลแวร์ requireAuth เพื่อปกป้อง API endpoints ของเรา

การปกป้อง API endpoints#

สำหรับ API ที่ควรเข้าถึงได้เฉพาะผู้ใช้ที่มีสิทธิ์ที่เฉพาะเจาะจง เราสามารถเพิ่มการจำกัดโดยตรงในมิดเดิลแวร์ได้ เช่น API การสร้างบทความควรเข้าถึงได้เฉพาะผู้ใช้ที่มีสิทธิ์ create:articles เท่านั้น:

สำหรับ API ที่ต้องตรวจสอบทั้งสิทธิ์และการเป็นเจ้าของทรัพยากร เราสามารถใช้ฟังก์ชัน hasScopes ได้ เช่น ใน API การแสดงรายการบทความ ผู้ใช้ที่มีสิทธิ์ list:articles สามารถเข้าถึงบทความทั้งหมดได้ ในขณะที่ผู้เขียนสามารถเข้าถึงบทความที่เขาเป็นผู้สร้างเท่านั้น:

ถึงจุดนี้เราได้ดำเนินการ RBAC เสร็จสมบูรณ์แล้ว คุณสามารถตรวจสอบ โค้ดต้นฉบับทั้งหมด เพื่อดูการดำเนินการทั้งหมดได้

ทดสอบการใช้ CMS RBAC#

ตอนนี้ลองทดสอบการใช้ CMS RBAC ของเราโดยใช้ผู้ใช้สามคนที่เราเพิ่งสร้างขึ้น

ก่อนอื่นลงชื่อเข้าใช้ในบทบาทของ Alex และ Charles แล้วสร้างบทความจะได้รับบทความใหม่

เนื่องจาก Alex มีบทบาทผู้ดูแลระบบ พวกเขาสามารถสร้าง ลบ แก้ไข เผยแพร่ และดูบทความทั้งหมด

Charles ที่มีบทบาทผู้เขียน สามารถสร้างบทความของเขาเองและสามารถดู แก้ไข และลบบทความที่เขาเป็นเจ้าของเท่านั้น

Bob ในบทบาทผู้เผยแพร่ สามารถดูบทความทั้งหมดและจัดการการเผยแพร่แต่ไม่สามารถสร้าง แก้ไข หรือ ลบได้

สรุป#

ยินดีด้วย! คุณได้เรียนรู้วิธีการใช้ระบบ RBAC ที่แข็งแกร่งในแอปพลิเคชันของคุณ

สำหรับกรณีที่ซับซ้อนมากขึ้น เช่น การสร้างแอปพลิเคชัน multi-tenant, Logto มีการสนับสนุนที่ครอบคลุมสำหรับองค์กร เข้าไปดูที่คำแนะนำของเราได้ที่ Build a multi-tenant SaaS application: A complete guide from design to implementation เพื่อเรียนรู้เพิ่มเติมเกี่ยวกับการควบคุมการเข้าถึงในระดับองค์กร

การเขียนโค้ดที่มีความสุข! 🚀