การควบคุมการเข้าถึงตามบทบาทที่ได้รับอนุญาต

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

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

ความกังวลของฉัน:

(1) "เลวร้าย" เกี่ยวกับการตรวจสอบบทบาทสำหรับการควบคุมการเข้าถึงอย่างไร จะได้ประโยชน์อะไรบ้างจากการตรวจสอบการอนุญาตแทน กล่าวอีกนัยหนึ่งอะไรคือความแตกต่างระหว่างตัวอย่างโค้ดด้านล่าง:

if(SecurityUtils.hasRole(user)) {
    // Grant them access to a feature
}

// vs.
if(SecurityUtils.hasPermission(user)) {
    // Grant them access to a feature
}

และ:

(2) ในสถานการณ์นี้บทบาทที่มีประโยชน์มีประโยชน์อย่างไร เราไม่สามารถกำหนดสิทธิ์ 1+ ให้กับผู้ใช้โดยตรงได้หรือ อะไรที่เป็นรูปธรรมบทบาทไม่คุ้มค่าของนามธรรมนำเสนอ (ตัวอย่างเช่นคนที่สามารถให้เฉพาะเจาะจง)?

(1) "เลวร้าย" เกี่ยวกับการตรวจสอบบทบาทสำหรับการควบคุมการเข้าถึงอย่างไร จะได้ประโยชน์อะไรบ้างจากการตรวจสอบการอนุญาตแทน

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

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

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

หากคุณตัดสินใจในภายหลังว่าบทบาทที่fooไม่ควรได้รับอนุญาตbaz, fooคุณจะต้องเปลี่ยนรหัสซึ่งการตรวจสอบทุกกรณีที่ผู้ใช้เป็น

(2) ในสถานการณ์นี้บทบาทที่มีประโยชน์มีประโยชน์อย่างไร เราไม่สามารถกำหนดสิทธิ์ 1+ ให้กับผู้ใช้โดยตรงได้หรือ บทบาทที่เป็นนามธรรมของการเสนอนามธรรมคืออะไร (ใครบางคนสามารถให้ตัวอย่างที่เฉพาะเจาะจงได้)

บทบาทแสดงแนวคิดของการอนุญาตที่มีชื่อ

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

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

หากคุณใช้บทบาทคุณจะต้องเพิ่มการอนุญาตให้กับAdministratorบทบาทซึ่งง่ายต่อการปฏิบัติงานเพิ่มพื้นที่มีประสิทธิภาพมากขึ้นและมีแนวโน้มที่จะเกิดข้อผิดพลาดน้อยลง

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

if(SecurityUtils.hasRole(developer)) {
    // Grant them access to a feature
} else if(SecurityUtils.hasRole(manager)) {
    // Grant them access to a feature
} else if...

(ข้อความswitchในภาษาที่คุณเลือกจะดีกว่า แต่ก็ยังไม่ค่อยเป็นระเบียบ)

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

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

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

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