Understanding How Casbin Matching Works in Detail

ในโพสต์นี้, ฉันจะอธิบายการออกแบบและการใช้งาน RBAC โดยใช้ไลบรารี Casbin สำหรับแพลตฟอร์ม SaaS ที่จัดการกับหลายๆ ระดับของทรัพยากรและบทบาทที่สืบทอดสิทธิ์จากระดับที่สูงกว่า, Casbin เป็นทางเลือกที่มีประสิทธิภาพที่ควรพิจารณา

บทนำสู่ RBAC

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

การเข้าใจ RBAC แบบลำดับชั้นของ Azure

มีบทบาทที่เรียกว่า Owner สำหรับทรัพยากรทั้งหมดใน Azure สมมติว่าถ้าฉันได้รับมอบหมายบทบาท Owner ที่ระดับการสมัครใช้งาน, นั่นหมายความว่าฉันเป็น Owner ของกลุ่มทรัพยากรและทรัพยากรทั้งหมดภายใต้การสมัครใช้งานนั้น ถ้าฉันมีบทบาท Owner ที่ระดับกลุ่มทรัพยากร, แล้วฉันก็เป็น Owner ของทรัพยากรทั้งหมดภายใต้กลุ่มทรัพยากรนั้น

ภาพนี้แสดงว่าฉันมีสิทธิ์ Owner ที่ระดับการสมัครใช้งาน

เมื่อฉันตรวจสอบ IAM ของกลุ่มทรัพยากรภายใต้การสมัครใช้งานนี้, คุณจะเห็นว่าฉันได้รับสิทธิ์ Owner ที่สืบทอดมาจากการสมัครใช้งาน

ดังนั้น, นี่คือวิธีการที่ RBAC ของ Azure เป็นแบบลำดับชั้น ซอฟต์แวร์ส่วนใหญ่ขององค์กรใช้ RBAC แบบลำดับชั้นเนื่องจากลักษณะลำดับชั้นของระดับทรัพยากร ในบทแนะนำนี้, เราจะพยายามใช้งานระบบที่คล้ายกันโดยใช้ Casbin

Casbin ทำงานอย่างไร?

ก่อนที่จะลงมือใช้งาน, สำคัญที่จะต้องเข้าใจว่า Casbin คืออะไรและมันทำงานอย่างไรในระดับสูง ความเข้าใจนี้จำเป็นเพราะระบบการควบคุมการเข้าถึงตามบทบาท (RBAC) อาจแตกต่างกันไปตามความต้องการเฉพาะ โดยการทำความเข้าใจการทำงานของ Casbin, เราสามารถปรับแต่งโมเดลให้เหมาะสมได้

ACL คืออะไร?

ACL ย่อมาจาก Access Control List มันเป็นวิธีการที่ผู้ใช้ถูกจับคู่กับการกระทำและการกระทำกับทรัพยากร

การนิยามโมเดล

ลองพิจารณาตัวอย่างง่ายๆ ของโมเดล ACL

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && r.obj == p.obj && r.act == p.act

1. request_definition เป็นแม่แบบคำถามของระบบ ตัวอย่างเช่น, คำขอ alice, write, data1 สามารถตีความได้ว่า "บุคคล Alice สามารถทำการกระทำ 'write' บนวัตถุ 'data1' ได้หรือไม่?"

2. policy_definition เป็นแม่แบบการมอบหมายของระบบ ตัวอย่างเช่น, โดยการสร้างนโยบาย alice, write, data1, คุณกำลังมอบสิทธิ์ให้บุคคล Alice ทำการกระทำ 'write' บนวัตถุ 'data1'

3. policy_effect กำหนดผลของนโยบาย

4. ในส่วน matchers, คำขอจะถูกจับคู่กับนโยบายโดยใช้เงื่อนไข r.sub == p.sub && r.obj == p.obj && r.act == p.act

ตอนนี้มาทดสอบโมเดลใน Casbin editor

เปิด editor และวางโมเดลข้างต้นใน Model editor

วางข้อความต่อไปนี้ใน Policy editor:

p, alice, read, data1
p, bob, write, data2

และข้อความต่อไปนี้ใน Request editor:

alice, read, data1

ผลลัพธ์จะเป็น:

true

การแสดงภาพของโมเดล ACL, นโยบาย, และการจับคู่คำขอ

RBAC คืออะไร?

RBAC ย่อมาจาก Role-Based Access Control ใน RBAC, ผู้ใช้จะได้รับมอบหมายบทบาทสำหรับทรัพยากร, และบทบาทสามารถมีการกระทำที่ไม่จำกัด จากนั้นคำขอจะตรวจสอบว่าผู้ใช้มีสิทธิ์ทำการกระทำบนทรัพยากรหรือไม่

การนิยามโมเดล

ลองพิจารณาตัวอย่างโมเดล RBAC ที่ง่าย:

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[role_definition]
g = _, _
g2 = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && g(p.act, r.act) && r.obj == p.obj

1. role_definition เป็นตัวสร้างความสัมพันธ์กราฟที่ใช้กราฟเพื่อเปรียบเทียบวัตถุคำขอกับวัตถุนโยบาย

ตอนนี้มาทดสอบโมเดลใน Casbin editor

เปิด editor และวางโมเดลข้างต้นใน Model editor

วางข้อความต่อไปนี้ใน Policy editor:

p, alice, reader, data1
p, bob, owner, data2

g, reader, read
g, owner, read
g, owner, write

และข้อมูลต่อไปนี้ใน Request editor:

alice, read, data1
alice, write, data1
bob, write, data2
bob, read, data2
bob, write, data1

ผลลัพธ์จะเป็น:

true
false
true
true
false

การแสดงภาพของโมเดล RBAC, นโยบาย, และการจับคู่คำขอ

ตาราง g - Role to action mapping มีการแมปกราฟจากบทบาทไปยังการกระทำ กราฟนี้สามารถเขียนเป็นรายการของเส้นขอบได้, ตามที่แสดงในนโยบายซึ่งเป็นวิธีทั่วไปในการแทนกราฟ:

g, reader, read
g, owner, read
g, owner, write

ข้อมูล

p หมายถึงนโยบายปกติที่สามารถเปรียบเทียบโดยใช้ตัวดำเนินการ == g เป็นฟังก์ชันการเปรียบเทียบที่ใช้กราฟ คุณสามารถกำหนดตัวเปรียบเทียบกราฟได้หลายตัวโดยการเพิ่มเลขท้ายเช่น g, g2, g3, ... และอื่นๆ

RBAC แบบลำดับชั้นคืออะไร?

ใน RBAC แบบลำดับชั้น, มีหลายประเภทของทรัพยากรและมีความสัมพันธ์แบบสืบทอดระหว่างประเภททรัพยากร ตัวอย่างเช่น, "subscription" เป็นหนึ่งประเภทและ "resourceGroup" เป็นอีกประเภทหนึ่ง sub1 ของประเภท Subscription สามารถมี resourceGroups หลายกลุ่ม (rg1, rg2) ของประเภท ResourceGroup

คล้ายกับลำดับชั้นของทรัพยากร, จะมีสองประเภทของบทบาทและการกระทำ: บทบาทและการกระทำของ Subscription, และบทบาทและการกระทำของ ResourceGroup มีความสัมพันธ์ที่ไม่แน่นอนระหว่างบทบาทของ Subscription และบทบาทของ ResourceGroup ตัวอย่างเช่น, พิจารณาบทบาทของ Subscription คือ sub-owner บทบาทนี้ถูกสืบทอดโดยบทบาทของ ResourceGroup คือ rg-owner, ซึ่งหมายความว่าถ้าฉันได้รับบทบาท sub-owner ใน Subscription sub1, แล้วฉันก็จะได้รับบทบาท rg-owner ใน rg1 และ rg2 โดยอัตโนมัติ

คำจำกัดความของโมเดล

มาดูตัวอย่างง่ายๆ ของโมเดล Hierarchical RBAC:

[request_definition]
r = sub, act, obj

[policy_definition]
p = sub, act, obj

[role_definition]
g = _, _
g2 = _, _

[policy_effect]
e = some(where (p.eft == allow))

[matchers]
m = r.sub == p.sub && g(p.act, r.act) && g2(p.obj, r.obj)

1. role_definition เป็นตัวสร้างความสัมพันธ์กราฟที่ใช้กราฟเพื่อเปรียบเทียบวัตถุคำขอกับวัตถุนโยบาย

ตอนนี้มาทดสอบโมเดลใน Casbin editor

เปิด editor และวางโมเดลข้างต้นใน Model editor

วางข้อมูลต่อไปนี้ใน Policy editor:

p, alice, sub-reader, sub1
p, bob, rg-owner, rg2

// subscription role to subscription action mapping
g, sub-reader, sub-read
g, sub-owner, sub-read
g, sub-owner, sub-write

// resourceGroup role to resourceGroup action mapping
g, rg-reader, rg-read
g, rg-owner, rg-read
g, rg-owner, rg-write

// subscription role to resourceGroup role mapping
g, sub-reader, rg-reader
g, sub-owner, rg-owner

// subscription resource to resourceGroup resource mapping
g2, sub1, rg1
g2, sub2, rg2

และวางข้อมูลต่อไปนี้ใน Request editor:

alice, rg-read, rg1

ผลลัพธ์จะเป็น:

true

การแสดงภาพของโมเดล RBAC, นโยบาย, และการจับคู่คำขอ

ตาราง g - Role to (Action, Role) Mapping มีการแมปกราฟจากบทบาทไปยังการกระทำ, การแมปบทบาท กราฟนี้สามารถเขียนเป็นรายการของเส้นขอบได้, ตามที่แสดงในนโยบายซึ่งเป็นวิธีทั่วไปในการแทนกราฟ:

// subscription role to subscription action mapping
g, sub-reader, sub-read
g, sub-owner, sub-read
g, sub-owner, sub-write

// resourceGroup role to resourceGroup action mapping
g, rg-reader, rg-read
g, rg-owner, rg-read
g, rg-owner, rg-write

// subscription role to resourceGroup role mapping
g, sub-reader, rg-reader
g, sub-owner, rg-owner

ตาราง g2 - Sub to RG Mapping มีการแมปกราฟจาก subscription ไปยัง resourceGroup:

// subscription resource to resourceGroup resource mapping
g2, sub1, rg1
g2, sub2, rg2

การแสดงภาพของการจับคู่ Subject

การแสดงภาพของการจับคู่ Action

การแสดงภาพของการจับคู่ Object

ข้อมูล

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

สรุป

ในบทเรียนนี้, เราได้เรียนรู้เกี่ยวกับวิธีการทำงานของโมเดลการอนุญาตที่แตกต่างกันและวิธีการที่พวกเขาสามารถถูกสร้างโมเดลโดยใช้ Casbin ในส่วนที่สองของบทเรียนนี้, เราจะนำไปใช้ในแอปพลิเคชันตัวอย่าง Spring Boot และปกป้อง APIs โดยใช้ Casbin