การอนุญาตผ่านการควบคุมการเข้าถึง

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

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

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

คำตอบคือไม่ ตามที่เอกสารที่ graphql.orgระบุอย่างชัดเจน ตรรกะการอนุญาตเป็นของเลเยอร์ตรรกะทางธุรกิจ และ GraphQL จะเข้าถึงจากที่นั่น วิธีนี้ทำให้แอปพลิเคชันมีแหล่งข้อมูลเดียวที่เชื่อถือได้สำหรับการอนุญาต (กล่าวคือสิ่งที่ WordPress มอบให้):

Gato GraphQL เคารพหลักการนี้ โดยสะท้อน (และภายใต้เอ็นจิน มอบหมายให้) กลไกการอนุญาตที่ WordPress มอบให้

​

นโยบายการควบคุมการเข้าถึง

ในบรรดานโยบายการควบคุมการเข้าถึงหลายอย่างที่เราสามารถนำไปใช้กับแอปพลิเคชัน สองอย่างที่นิยมมากที่สุดคือ Role-Based Access Control (RBAC) และ Attribute-Based Access Control (ABAC)

WordPress และ Gato GraphQL รองรับทั้งสองแบบ

ด้วย Role-Based Access Control เราจะมอบสิทธิ์ตามบทบาท แล้วจึงกำหนดบทบาทให้กับผู้ใช้ ตัวอย่างเช่น WordPress มีบทบาท administrator ที่สามารถเข้าถึงทรัพยากรทั้งหมด และบทบาท editor, author, contributor และ subscriber ที่มีสิทธิ์จำกัดในระดับที่แตกต่างกัน เช่น สามารถสร้างและเผยแพร่บล็อกโพสต์ สร้างเท่านั้น หรือแค่อ่านเท่านั้น

ด้วย Attribute-Based Access Control สิทธิ์จะถูกมอบตามข้อมูลเมตาที่สามารถกำหนดให้กับหน่วยงานต่างๆ รวมถึงผู้ใช้ ทรัพยากร และเงื่อนไขสภาพแวดล้อม (เช่น เวลาของวันหรือ IP ของผู้เยี่ยมชม) ตัวอย่างเช่นใน WordPress ความสามารถ edit_others_posts ใช้เพื่อตรวจสอบว่าผู้ใช้สามารถแก้ไขโพสต์ของผู้ใช้อื่นได้หรือไม่

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

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

​

การกำหนดระดับการมองเห็น

เมื่อผู้ใช้ไม่มีสิทธิ์เข้าถึงฟิลด์ที่ร้องขอจาก GraphQL schema ข้อผิดพลาดที่ควรส่งกลับควรเป็นอย่างไร?

มีสองความเป็นไปได้ ตามระดับการมองเห็นที่ต้องการสำหรับ schema ได้แก่ สาธารณะหรือส่วนตัว

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

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

​

การควบคุมการเข้าถึงผ่านอินเทอร์เฟซผู้ใช้

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

ผู้ดูแลไซต์กำหนดค่า ACL โดยเลือก:

• ฟิลด์ที่จะตรวจสอบ
• กฎที่จะตรวจสอบ จากรายการต่อไปนี้:
  • ผู้ใช้ต้องเข้าสู่ระบบหรือไม่?
  • ผู้ใช้ต้องออกจากระบบหรือไม่?
  • ผู้ใช้ต้องมีบทบาทที่กำหนดหรือไม่?
  • ผู้ใช้ต้องมีความสามารถที่กำหนดหรือไม่?
• การกำหนดค่าเฉพาะกฎ:
  • บทบาทใด?
  • ความสามารถใด?
• ระดับการมองเห็น:
  • ค่าเริ่มต้น (เหมือนกับที่กำหนดให้กับ schema)?
  • สาธารณะ?
  • ส่วนตัว?