• หลายผู้เช่า
  • saas
  • องค์กร
  • การทำงานร่วมกัน
  • ตัวตน
  • การควบคุมการเข้าถึง

อธิบายโมเดลหลายผู้เช่าของ Logto

ดูว่าเราออกแบบโมเดลหลายผู้เช่าของ Logto อย่างไรและประโยชน์ที่นำมาให้กับแอป SaaS

Gao
Gao
Founder

ความสับสน

คุณอาจเคยได้ยินเกี่ยวกับผลิตภัณฑ์บางตัวที่ใช้คำว่า "หลายผู้เช่า" เพื่อแสดงการแยกตัวตน: แต่ละผู้เช่าจะมีชุดผู้ใช้, บทบาท, การอนุญาต, และข้อมูลของตนเอง

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

โมเดลของ Logto

ที่ Logto เราได้สังเกตความสับสนนี้ตั้งแต่เริ่มต้นการออกแบบของเรา และเราต้องการทำให้มันถูกต้องสำหรับแอปของคุณและผู้ใช้ของคุณ นี่คืองานออกแบบของเรา:

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

โมเดลนี้ให้ความยืดหยุ่นและการใช้งานซ้ำในการจัดการตัวตน โดยเฉพาะสำหรับแอป SaaS ถ้าเรามองไปที่แอป SaaS ที่เป็นที่นิยมบางตัว เราจะพบว่ามันสามารถเข้ากับโมเดลนี้ได้ คำว่า "องค์กร" อาจแตกต่างไปในแอปต่าง ๆ เช่น "พื้นที่ทำงาน", "ทีม" เป็นต้น แต่แนวคิดเป็นสิ่งเดียวกัน

สำหรับตัวอย่างใน Notion (เครื่องมือการทำงานร่วมกันที่เป็นที่นิยม):

  • คุณสามารถสร้างและเข้าร่วมพื้นที่ทำงานด้วยบัญชีเดียว แทนที่จะลงทะเบียนสำหรับแต่ละพื้นที่ทำงานด้วยบัญชีที่ต่างกัน
  • สำหรับแต่ละพื้นที่ทำงาน Notion กำหนด ชุดระดับการเข้าถึงเดียวกัน: "เจ้าของพื้นที่ทำงาน" และ "สมาชิก" ขณะที่คุณอาจคาดหวังระดับการเข้าถึงที่แตกต่างกันสำหรับพื้นที่ทำงานต่าง ๆ

ดังนั้นผู้ใช้สามารถเปลี่ยนระหว่างพื้นที่ทำงานได้ง่ายดายโดยไม่ต้องเปลี่ยนบัญชีหรือเข้าสู่ระบบใหม่ และมันยังคงรักษาการแยกระหว่างพื้นที่ทำงาน เปรียบเทียบกับโมเดลของ Logto มันหมายถึง:

  • เทมเพลตองค์กร กำหนดบทบาทสองบทบาท: "เจ้าของ" และ "สมาชิก"
  • หากผู้ใช้เข้าร่วมพื้นที่ทำงาน หมายความว่าผู้ใช้เป็นสมาชิกของ องค์กร และมีบทบาท "สมาชิก" ใน องค์กร
  • หากผู้ใช้สร้างพื้นที่ทำงาน หมายความว่าผู้ใช้เป็นสมาชิกของ องค์กร และมีบทบาท "เจ้าของ" ใน องค์กร

ตามบทบาทที่แตกต่าง ผู้ใช้สามารถมีการอนุญาตต่าง ๆ ในพื้นที่ทำงาน (องค์กร) ที่แตกต่างกัน

ประโยชน์ต่าง ๆ

ประสบการณ์ของผู้ใช้

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

การใช้งานซ้ำ

หนึ่งในข้อดีของแอป SaaS คือพวกมันมีมาตรฐานและสามารถปรับขยายได้ สำหรับตัวอย่าง คุณสามารถสร้างพื้นที่ทำงานใหม่ใน Notion ด้วยการคลิกเพียงไม่กี่ครั้ง และมันพร้อมใช้งาน

เมื่อแอปของคุณเติบโต คุณอาจต้องการเพิ่มบทบาทและการอนุญาตใหม่ในแต่ละองค์กร สำหรับตัวอย่าง บทบาทใหม่ "ผู้ใช้ทั่วไป" และการอนุญาตใหม่ "เชิญ:ผู้ใช้ทั่วไป" มันอาจจะเป็นฝันร้ายหากคุณต้องอัปเดตองค์กรที่มีอยู่ทั้งหมดทีละอัน

ด้วย Logto คุณสามารถอัปเดตเทมเพลตองค์กร และองค์กรที่มีอยู่ทั้งหมดจะถูกอัปเดตโดยอัตโนมัติ

หนึ่งโมเดลการควบคุมการเข้าถึง หลายการใช้งาน

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

ส่วนที่น่าตื่นเต้นที่สุดคือคุณสามารถใช้พวกมันพร้อมกัน มาเพิ่มตัวอย่างของ Notion:

  • สำหรับการเข้าถึงพื้นที่ทำงาน คุณสามารถใช้ Logto organization RBAC
  • สำหรับการเข้าถึงและอัปเดตทรัพยากรระดับที่บัญชี (เช่น ข้อมูลโปรไฟล์และการเรียกเก็บเงิน) คุณสามารถใช้ Logto API resource RBAC

ชุดคำสั่ง Logto ส่วนมากรองรับ RBAC ทั้งสองประเภท

ความแตกต่าง

Organization RBAC และ API resource RBAC แตกต่างกันในแง่ต่อไปนี้:

  • Organization RBAC ต้องการบริบทขององค์กร ในขณะที่ API resource RBAC ไม่ต้องการ
  • Organization RBAC ใช้สำหรับการควบคุมการเข้าถึงในองค์กร ในขณะที่ API resource RBAC ใช้สำหรับการควบคุมการเข้าถึงทรัพยากร API
  • ผู้ใช้สามารถมีบทบาทองค์กรที่แตกต่างกันในองค์กรที่ต่างกัน ในขณะที่บทบาทสำหรับทรัพยากร API เป็นสากลในผู้เช่า
  • บทบาทและการอนุญาตถูกแยกต่างหากสำหรับ RBAC ทั้งสองประเภทนี้

หมายเหตุปิดท้าย

การสร้างแอป SaaS เป็นเรื่องยาก และเราหวังว่า Logto จะช่วยให้คุณมุ่งเน้นไปที่ธุรกิจหลักของคุณ อย่าลังเลที่จะส่งความเห็นให้เรา หากคุณมีคำถามหรือข้อเสนอแนะ