ACL ของแผนที่

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

หมายเหตุ: Content Connector SDK รองรับ ACL โดเมนเดียว แต่ไม่รองรับ ACL ข้ามโดเมน คุณไม่สามารถให้สิทธิ์เข้าถึงแก่ผู้ใช้และกลุ่มที่อยู่นอกองค์กร ACL ที่อ้างอิงถึงผู้ใช้หรือกลุ่มภายนอกองค์กรจะไม่มีผล

สร้าง ACL

การสร้าง ACL เป็นกระบวนการแบบ 2 ขั้นตอน ดังนี้

1. สร้าง Principal โดยใช้เมธอดแบบคงที่ในคลาส ACL
2. ใช้คลาส Acl.Builder เพื่อสร้าง ACL โดยใช้ผู้ใช้หลัก

ส่วนที่เหลือของเอกสารนี้จะอธิบายแนวคิดบางอย่างที่คุณจําเป็นต้องทราบในการสร้างและจำลอง ACL เช่น การรับช่วงและการเก็บรักษา

สร้างผู้ใช้หลักโดยใช้รหัสภายนอก

Google Cloud Search กำหนดให้ผู้ใช้และกลุ่มต้องแก้ไขเป็นอีเมล Google เมื่อจัดทําดัชนีรายการที่เก็บ เครื่องมือเชื่อมต่อเนื้อหาอาจไม่มีอีเมลเหล่านี้ อย่างไรก็ตาม Content Connector SDK ให้คุณใช้รหัสภายนอก (รหัสที่ให้สิทธิ์ผู้ใช้หรือกลุ่มเข้าถึงรายการในรีโพซิทอรี) แทนอีเมลเพื่อจัดทำดัชนีรายการได้ ใช้วิธี getUserPrincipal() หรือวิธี getGroupPrincpal() เพื่อสร้างผู้ใช้หลักที่มีรหัสภายนอก มีเมธอดแบบคงที่อื่นๆ อีกหลายรายการในคลาส ACL ที่ใช้ในการสร้างออบเจ็กต์ Principal

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

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

การรับช่วง ACL

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

ตั้งค่าการสืบทอด

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

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

หมายเหตุ: หากตั้งค่าการสืบทอดโดยใช้เมธอด setInheritFrom() คุณจะต้องตั้งค่าประเภทการสืบทอดโดยใช้เมธอด setInheritanceType() ดูข้อมูลเกี่ยวกับประเภทการสืบทอดได้ที่หัวข้อตั้งค่าประเภทการสืบทอด

รูปที่ 1 แสดงวิธีใช้เมธอด setInheritFrom() เพื่อรับค่าหลักที่อนุญาตโดยอ้อมและหลักที่ถูกปฏิเสธโดยอ้อม

รูปที่ 1 เมธอด setInheritFrom()

การควบคุมการเข้าถึงเหล่านี้แสดงอยู่ในรูปที่ 1

• ผู้ใช้ 1 เป็นผู้ที่มีสิทธิ์โดยตรงในรายการ ก.
• ผู้ใช้ 2 เป็นผู้ใช้หลักที่ได้รับอนุญาตโดยตรงของรายการ ข.
• รายการ ข. จะรับค่า ACL ของรายการ ก.

กฎการเข้าถึงตามการควบคุมการเข้าถึงมีดังนี้

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

ตั้งค่าประเภทการสืบทอด

หากตั้งค่าการสืบทอดโดยใช้เมธอด setInheritFrom() คุณจะต้องตั้งค่าประเภทการสืบทอดโดยใช้เมธอด setInheritanceType() ประเภทการสืบทอดจะกำหนดวิธีที่ ACL ของรายการย่อยรวมเข้ากับ ACL ของรายการหลัก Acl.InheritanceType ใช้การสืบทอด 3 ประเภท ดังนี้

• BOTH_PERMIT - ตั้งค่าประเภทการสืบทอดเป็น BOTH_PERMIT เพื่อให้สิทธิ์เข้าถึงรายการแก่ผู้ใช้ก็ต่อเมื่อทั้ง ACL ของรายการย่อยและ ACL ของรายการที่รับค่ามาของรายการหลักอนุญาตให้ผู้ใช้รายนั้นเข้าถึงรายการนั้น

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

• PARENT_OVERRIDE - ตั้งค่าประเภทการสืบทอดเป็น PARENT_OVERRIDE เพื่อบังคับให้ ACL ของรายการหลักมีผลเหนือกว่า ACL ของรายการย่อยเมื่อมีความขัดแย้ง ดังนั้นหาก ACL ของรายการย่อยปฏิเสธการเข้าถึงของผู้ใช้ในฐานะผู้อ่านที่ถูกปฏิเสธ ผู้ใช้จะยังคงมีสิทธิ์เข้าถึงหากมีสิทธิ์เข้าถึงรายการหลักในฐานะผู้อ่าน ในทางกลับกัน แม้ว่า ACL ของรายการย่อยจะมอบสิทธิ์เข้าถึงแก่ผู้ใช้ แต่ผู้ใช้ก็ไม่มีสิทธิ์เข้าถึงหากเป็นผู้ใช้ที่มีสิทธิ์อ่านรายการหลักที่ถูกปฏิเสธ

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

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

การจำกัดและการลบรายการ

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

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

การควบคุมการเข้าถึงเหล่านี้แสดงอยู่ในรูปที่ 2

• ผู้ใช้ 1 เป็นผู้ใช้หลักที่ได้รับอนุญาตโดยตรงของรายการ ก.
• ผู้ใช้ 2 เป็นผู้ใช้หลักที่ได้รับอนุญาตโดยตรงของรายการ ข.
• ผู้ใช้ 3 เป็นผู้ใช้หลักที่ได้รับอนุญาตโดยตรงของรายการ C
• รายการ C จะรับค่า ACL ของรายการ A
• สินค้า ข ตั้งชื่อสินค้า ก เป็นคอนเทนเนอร์
• รายการ ค ตั้งชื่อรายการ ข เป็นคอนเทนเนอร์

กฎการเข้าถึงตามการควบคุมการเข้าถึงมีดังนี้

• การเข้าถึงโดยอ้อมมาจากเมธอด setInheritFrom() ดังนั้น ผู้ใช้ 1 จึงเข้าถึงรายการ ค ได้ เนื่องจากรายการ ค รับค่า ACL ของรายการ ก
• การเข้าถึงโดยอ้อมไม่ได้มาจากการที่รายการ C อยู่ในรายการ B ดังนั้น ผู้ใช้ที่ 2 จึงเข้าถึงรายการ C ไม่ได้

รูปที่ 2 เมธอด setInheritFrom() ที่ใช้อยู่

การแยกการรับค่า ACL ออกจากลําดับชั้นการกักเก็บช่วยให้คุณจําลองโครงสร้างที่มีอยู่ได้หลายแบบ

สิ่งที่จะเกิดขึ้นเมื่อลบรายการเรียบร้อยแล้ว

• รายการที่มีสินค้าที่ลบไปแล้วจะค้นหาไม่ได้และระบบจะกำหนดเวลาการลบออกจากแหล่งข้อมูลของ Google
• รายการที่ระบุรายการที่ถูกลบโดยใช้เมธอด setInheritFrom() จะค้นหาไม่ได้

หากทรัพยากรมีรายการที่ถูกลบโดยใช้วิธี setInheritFrom() แต่ไม่มีการตั้งค่าคอนเทนเนอร์โดยใช้ setContainer() หรือลําดับชั้นการบรรจุไม่มีรายการที่ถูกลบ รายการนั้นและข้อมูลของรายการจะยังคงอยู่ในแหล่งข้อมูลของ Google คุณมีหน้าที่รับผิดชอบในการลบรายการดังกล่าว

รูปที่ 3 แสดงตัวอย่างการลบลําดับชั้นของรายการ

รูปที่ 3 การลบรายการและการรับค่า ACL ไปโดยค่าเริ่มต้น

การควบคุมการเข้าถึงเหล่านี้แสดงอยู่ในรูปที่ 3

• ผู้ใช้ 1 เป็นผู้ที่มีสิทธิ์โดยตรงในรายการ ก.
• ผู้ใช้ 2 เป็นผู้ใช้หลักที่ได้รับอนุญาตโดยตรงของรายการ D
• รายการ D และรายการ E จะได้รับค่า ACL ของรายการ A
• รายการ D ตั้งชื่อรายการ A เป็นคอนเทนเนอร์
• รายการ ก. และ ง. เป็นรายการระดับรูทเนื่องจากไม่มีรายการคอนเทนเนอร์

ลบตามลำดับผ่านข้อมูลอ้างอิงคอนเทนเนอร์ สิ่งที่จะเกิดขึ้นเมื่อลบรายการ ก

• รายการที่สืบทอดทั้งหมดของข้อมูลอ้างอิง setInheritFrom() จะเสียสิทธิ์เข้าถึงสำหรับผู้ใช้ทั้งหมด
• ไม่มีผู้ใช้คนใดเข้าถึงรายการ ก ได้
• ระบบจะลบรายการ D โดยนัย ไม่มีผู้ใช้คนใดเข้าถึงรายการ D ได้
• ระบบจะไม่ลบรายการ E เนื่องจากการลบจะทํางานตามลําดับผ่านข้อมูลอ้างอิงคอนเทนเนอร์เท่านั้น
• รายการ E จะเข้าถึงไม่ได้และผู้ใช้จะค้นหารายการ E ไม่ได้