ACL ของแผนที่

เพื่อให้มั่นใจว่าเฉพาะผู้ใช้ที่มีสิทธิ์เข้าถึงรายการเท่านั้นที่จะเห็นรายการนั้นในผลการค้นหา คุณควรจัดทำดัชนีรายการด้วยรายการควบคุมการเข้าถึง (ACL) จากที่เก็บข้อมูลขององค์กร คุณต้องสร้างรูปแบบ ACL ของที่เก็บและรวม ACL เหล่านั้นเมื่อจัดทำดัชนีรายการในที่เก็บ 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 ว่าไม่มีสิทธิ์เข้าถึงรายการที่เฉพาะเจาะจง

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

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

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

รูปที่ 1 วิธี setInheritFrom()

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

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

กฎการเข้าถึงจะขึ้นอยู่กับการควบคุมการเข้าถึง ดังนี้

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

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

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

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

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

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

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

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

การกักกันและการลบรายการ

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

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

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

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

กฎการเข้าถึงจะขึ้นอยู่กับการควบคุมการเข้าถึง ดังนี้

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

รูปที่ 2 setInheritFrom() ที่ใช้อยู่

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

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

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

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

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

รูปที่ 3 การลบรายการและการรับค่า ACL

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

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

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

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