πPi Auth
เข้าสู่ระบบ
สารบัญ

ดูแลองค์กร

Role, binding และ explain

system role เทมเพลต การผูกกับคนหรือโครงสร้าง และวิธีคำนวณสิทธิ์ที่มีผล

สิทธิ์ใน Pi Auth มีสามชั้น: แอปประกาศ permission ผู้ดูแลจัดกลุ่มเป็น role แล้ว role ถูกผูกกับไดเรกทอรี สิทธิ์ที่มีผลของสมาชิกคือผลรวมของ binding เหล่านั้น ณ ตอนนี้ — คำนวณสด cache สั้น ๆ และอธิบายที่มาได้เสมอ

Role

ชนิดมาจากไหนหมายเหตุ
System roleทุก tenant โดยอัตโนมัติเจ้าของ tenant และ ผู้ดูแล tenant มีสิทธิ์ในตัว tenant:admin, directory:read/write, access:read/write; สมาชิก มี directory:read ตาม base role ของ membership แก้หรือลบไม่ได้
เทมเพลต rolemanifest ของแอป ตอนติดตั้งแอปrole สำเร็จรูปเช่น “ผู้ดูแล Pi PDF” แก้ได้ตามใจ — เป็นสำเนาของ tenant
Role ที่สร้างเองสิทธิ์ → Roles → สร้าง rolepermission ชุดใดก็ได้จากแอปที่ติดตั้ง role หนึ่งรวม permission หลายแอปได้

permission ที่แอปทำเครื่องหมาย HIGH ถูกเน้นในตัวแก้ role permission ที่ deprecated (ถูกเอาออกจาก manifest ใหม่) ยังอยู่ใน role เดิมแบบขีดฆ่าจนกว่าจะมีคนเอาออก

Binding

binding เชื่อม role กับ subject เปิด role แล้วกด ผูก:

Subjectใครได้ role
สมาชิกรายคนเฉพาะคนนั้น เหมาะกับข้อยกเว้น ส่วนกติกาให้ใช้ binding เชิงโครงสร้าง
กลุ่มทุกคนในกลุ่ม ตามที่สมาชิกกลุ่มเปลี่ยน
ตำแหน่งทุกคนที่ถือตำแหน่งนั้นไม่ว่าอยู่ตรงไหนของผัง — รวมผู้รักษาการ
หน่วยงานทุกคนที่สังกัดหลักคือหน่วยนั้น; ถ้าเลือกรวมหน่วยย่อย คือทุกคนในต้นไม้ใต้มัน หน่วยใหม่ที่สร้างใต้มันได้รับต่อโดยอัตโนมัติ

binding มีช่วงเวลามีผล (จาก / ถึง) ได้ สิทธิ์ชั่วคราว — ตรวจสอบ โครงการ รักษาการ — หมดไปเอง และแสดงเป็นหมดอายุในหน้า role แทนที่จะค้างเงียบ ๆ

สิทธิ์ที่มีผลคำนวณอย่างไร

  1. รวบรวม subject ของสมาชิก

    membership, กลุ่ม, ตำแหน่งหลักและตำแหน่งที่ได้รับมอบหมาย, หน่วยงานหลักและบรรพบุรุษทั้งหมด

  2. หา binding ที่ตรง

    binding ที่มีผล (อยู่ในช่วงเวลา) ซึ่ง subject เป็นหนึ่งในนั้น บวก system role ของ base role

  3. รวม permission ของ role ทั้งหมด

    ตัด permission ที่ deprecated และของแอปที่ถอนแล้ว ผลลัพธ์ตัดซ้ำและเรียงลำดับ

  4. cache 5 นาที

    การเปลี่ยน binding, role, ผังองค์กร, กลุ่ม หรือ membership ล้าง cache ของ tenant ทันที — 5 นาทีมีผลเฉพาะเมื่อไม่มีอะไรเปลี่ยน

โทเค็นมีสิทธิ์ของแอปที่ระบุใน resource เท่านั้น สมาชิกที่มีสิทธิ์ในห้าแอปจะได้เฉพาะชุดที่เกี่ยวในโทเค็นของแต่ละแอป

Explain

สิทธิ์ → ตรวจสิทธิ์ (explain) รับสมาชิก (และแอปถ้าต้องการ) แล้วแสดงทุกสิทธิ์ที่มีผลพร้อมสายที่มา: role ไหน ผูกกับ subject ใด ถึงผ่านหน่วยงานหรือตำแหน่งใด ใช้เมื่อมีคนถามว่า “ทำไมฉันถึงทำ/ไม่ทำสิ่งนี้ได้?” — คำตอบคือ binding ที่ต้องแก้ ไม่ใช่โค้ด

ตรวจสิทธิ์ในแอป

server
const user = await piAuth.getCurrentUser();
if (!user?.perms.includes("memo:approve")) return forbidden();
// หรือ
piAuth.requirePermission(user, "memo:approve"); // throw 403 problem

ตรวจ permission ไม่ใช่ base role หรือตำแหน่ง: trole === "admin" พังทันทีที่องค์กรอยากให้คนที่ไม่ใช่ admin อนุมัติ ส่วน memo:approve ให้เขาผูกกับใครก็ได้

ให้ผู้ใช้ขอสิทธิ์จากในแอป

คนที่เข้าแอปได้แต่ยังไม่มี permission ไม่ต้องไปตามหาผู้ดูแลเอง — วางปุ่ม <RequestAccessButton clientId={process.env.NEXT_PUBLIC_PI_AUTH_CLIENT_ID!} /> จาก @suphark/auth-ui (≥ 0.3.0) หรือลิงก์ไป https://auth.suphark.com/request-access?client_id=<clientId> (แอปที่ไม่ใช้ React)

  1. ผู้ใช้พิมพ์ข้อความถึงผู้ดูแล (ไม่บังคับ) แล้วส่ง — คำขอเข้าองค์กรที่ผู้ใช้เลือกอยู่ที่ Pi Auth
  2. ผู้ดูแลได้อีเมล แล้วเลือก role ของแอปตอนกดอนุมัติที่ คน › คำขอเข้าใช้และสิทธิ์ (หรือหน้า ผู้ใช้ ของแอป)
  3. ผู้ใช้ได้อีเมลแจ้ง สิทธิ์มีผลทันที (แอปได้ event role.binding.changed)

แอปโหมด “รออนุมัติ” ใช้หน้าจอเดียวกัน — คำขอเข้าใช้ครั้งแรกก็เลือก role ตอนอนุมัติได้เช่นกัน