การควบคุมการเข้าถึงตามบทบาท (RBAC) กับการควบคุมการเข้าถึงตามการอ้างสิทธิ์ (CBAC) ใน ASP.NET MVC

ประโยชน์หลักของการใช้CBACกับRBACคืออะไร ควรใช้ CBAC เมื่อใดและเมื่อไรควรใช้ RBAC เมื่อใดดีกว่า

ฉันพยายามที่จะเข้าใจแนวคิดทั่วไปของโมเดล CBAC แต่แนวคิดทั่วไปยังไม่ชัดเจนสำหรับฉัน

ฉันจะพยายามแสดงให้คุณเห็นว่าคุณจะได้ประโยชน์จากการควบคุมการเข้าถึงโดยอ้างสิทธิ์ในบริบทของ ASP.NET MVC อย่างไร

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

[Authorize(Roles="Sale")]
public ActionResult CreateCustomer()
{
    return View();
}

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

[Authorize(Roles = "Sale", "Marketing")]
public ActionResult CreateCustomer()
{
    return View();
}

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

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

การควบคุมการเข้าถึงตามการอนุญาตเป็นวิธีหนึ่งในการกำหนดสิทธิ์ต่าง ๆ ให้กับผู้ใช้ที่หลากหลายและตรวจสอบว่าผู้ใช้มีสิทธิ์ในการดำเนินการจากโค้ดในเวลาทำงานหรือไม่ หลังจากที่คุณกำหนดสิทธิ์ต่าง ๆ ให้กับผู้ใช้หลายคนคุณรู้ว่าคุณต้องอนุญาตให้ผู้ใช้บางคนเรียกใช้รหัสบางอย่างถ้าผู้ใช้มีคุณสมบัติบางอย่างเช่น "ผู้ใช้ Facebook", "ผู้ใช้เป็นเวลานาน" เป็นต้นให้ฉันยกตัวอย่าง สมมติว่าคุณต้องการอนุญาตให้เข้าถึงหน้าใดหน้าหนึ่งหากผู้ใช้ลงชื่อเข้าใช้ด้วย Facebook ตอนนี้คุณจะสร้างการอนุญาต 'Facebook' สำหรับผู้ใช้รายนั้นหรือไม่ ไม่ 'Facebook' ดูเหมือนจะไม่ได้รับอนุญาต ทำมัน ? มันฟังดูเป็นข้ออ้าง ในเวลาเดียวกันการอนุญาตสามารถฟังเหมือนอ้างสิทธิ์ด้วย !! ดังนั้นจึงเป็นการดีกว่าที่จะตรวจสอบการอ้างสิทธิ์และอนุญาตการเข้าถึง

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

คุณสามารถกำหนดชุดของการเคลมได้ดังนี้:

"CanCreateCustomer", "CanDeleteCustomer", "CanEditCustomer" .. เป็นต้น

ตอนนี้คุณสามารถตกแต่งวิธีการกระทำของคุณเช่นนี้:

        [ClaimAuthorize(Permission="CanCreateCustomer")]
        public ActionResult CreateCustomer()
        {
            return View();
        }

(โปรดทราบว่า [ClaimAuthorize (Permission = "CanCreateCustomer")] อาจไม่ถูกสร้างขึ้นในไลบรารีคลาส MVC ฉันเพิ่งแสดงเป็นตัวอย่างคุณสามารถใช้ไลบรารีคลาสที่มีนิยามคลาสแอตทริบิวต์ดังกล่าว)

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

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

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

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

ตอนนี้ฉันใช้โมเดลความปลอดภัยมาหลายครั้งแล้ว ต้องทำหลายครั้งนี่คือความเข้าใจของฉันเกี่ยวกับแนวคิดเหล่านี้

บทบาทคืออะไร

บทบาท = สหภาพของผู้ใช้และการอนุญาต

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

ในทางกลับกันบทบาทก็เป็นกลุ่มของผู้ใช้เช่นกัน ถ้าฉันเพิ่ม Bob และ Alice ในบทบาท "Managers" ดังนั้น "Managers" จะมีกลุ่มผู้ใช้สองกลุ่มเรียงกันเป็นกลุ่ม

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

กลุ่มคืออะไร

กลุ่ม = กลุ่มผู้ใช้

"กลุ่ม" เป็นการรวบรวมผู้ใช้อย่างเคร่งครัด ความแตกต่างระหว่างกลุ่มและบทบาทก็คือบทบาทนั้นมีชุดของการอนุญาต แต่กลุ่มจะมีกลุ่มผู้ใช้งานเท่านั้น

การอนุญาตคืออะไร

การอนุญาต = วิชาสามารถทำอะไรได้บ้าง

ชุดอนุญาตคืออะไร

ชุดการอนุญาต = ชุดของการอนุญาต

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

ผู้ใช้กลุ่มบทบาทและสิทธิ์อนุญาตมารวมกันได้อย่างไร

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

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

วัตถุประสงค์ทั้งหมดของบทบาทคือการแต่งงานกับผู้ใช้งานเพื่ออนุญาต ดังนั้นบทบาทคือสหภาพของผู้ใช้และการอนุญาต

อะไรคือข้อเรียกร้อง

อ้างสิทธิ์ = สิ่งที่หัวเรื่อง "คือ"

การอ้างสิทธิ์ไม่ใช่การอนุญาต ตามที่ระบุไว้ในคำตอบก่อนหน้าการอ้างสิทธิ์คือสิ่งที่หัวเรื่อง "คือ" ไม่ใช่สิ่งที่หัวเรื่อง "สามารถทำได้"

การอ้างสิทธิ์ไม่ได้แทนที่บทบาทหรือการอนุญาต แต่เป็นข้อมูลเพิ่มเติมที่สามารถใช้ในการตัดสินใจอนุมัติ

เมื่อใดจึงจะใช้การเรียกร้อง

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

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

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

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

หากจำเป็นต้องเพิ่ม / ลบห้องบางบทบาทด้วยเหตุผลใดก็ตามสิ่งนี้สามารถทำได้โดยใช้ RBAC แต่มันไม่เหมาะสำหรับการเรียกร้อง

สิทธิ์ในซอฟต์แวร์

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

โน้ตตัวสุดท้าย

แกรนท์ vs ปฏิเสธ

ระบบ RBAC ที่แข็งแกร่งและแม้แต่ระบบ CBAC ควรแยกความแตกต่างระหว่าง Grants และ Denials

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

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

จริง ๆ แล้วนี่จะเป็นผู้สมัครที่ดีสำหรับการเรียกร้อง หากผู้ใช้มีการอ้างสิทธิ์ "gender = male" ดังนั้นการอยู่ในบทบาทผู้จัดการจะให้สิทธิ์การเข้าถึงห้องพักทุกห้อง แต่ห้องน้ำของเลดี้จะต้องใช้ Claim gender = female และห้องน้ำของผู้ชายนั้นต้องการ Claim gender = male ด้วยวิธีนี้เราไม่จำเป็นต้องกำหนดค่าสิทธิ์ DENY ให้กับผู้ใช้ชายเนื่องจากการบังคับใช้การเรียกร้องจะดูแลสิ่งนั้นสำหรับทุกคนด้วยกฎการให้สิทธิ์เดียว อย่างไรก็ตามสามารถทำได้ทั้งสองทาง

ประเด็นก็คือด้วย DENIAL ของการอนุญาตจะทำให้การจัดการบทบาทง่ายขึ้นเนื่องจากสามารถทำการยกเว้นได้

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

ฉันหวังว่านี่จะช่วยได้.

นี่คือไดอะแกรมของ RBAC ที่อธิบายไว้ข้างต้น

อัปเดตเมื่อวันที่ 7 เมษายน 2019 อ้างอิงจากคำติชมจาก @Brent (ขอบคุณ) ... ลบการอ้างอิงที่ไม่จำเป็นไปยังคำตอบก่อนหน้าและอธิบายพื้นฐานดั้งเดิมของคำอุปมา "ไนท์คลับ" ที่ได้รับจาก @CoderSoft เพื่อให้คำตอบนี้เข้าใจได้โดยไม่ต้อง เพื่ออ่านคำตอบอื่น ๆ

ฉันไม่เห็นด้วยกับคำตอบของ Emran

[Authorize(Roles="Sale")]

ไร้เดียงสา

คำถามคืออย่างไร

  [Authorize(Roles="CustomerCreator")]

แตกต่างจาก

 [ClaimAuthorize(Permission="CanCreateCustomer")]

หากทั้งสองอย่างเท่าเทียมกันดีทำไมเราต้องเรียกร้อง

ฉันคิดว่าเพราะ

แนวคิดการอ้างสิทธิ์นั้นเป็นเรื่องทั่วไปมากกว่าเมื่อเปรียบเทียบกับบทบาท

ในบริบทของตัวอย่างข้างต้นเราสามารถพูดได้ว่า "CustomerCreator" เป็นการอ้างสิทธิ์ประเภท "บทบาท" ที่จัดทำโดย "Asp.NETroleProvider"

ตัวอย่างเพิ่มเติมของการเรียกร้อง

1. "AAA" เป็นการอ้างสิทธิ์ประเภท "MYExamSite.Score" โดย "MYExamSite.com"

2. "Gold" เป็นประเภทของ "MYGYM.Membershiptype" ซึ่งจัดทำโดย "MYGYMApp"

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

บทบาทมีอยู่และเข้าท่าภายในขอบเขตโดยนัยเท่านั้น โดยทั่วไปนั่นคือแอปพลิเคชันหรือขอบเขตองค์กร (เช่น Role = Administrator) ในทางตรงกันข้ามการเรียกร้องสามารถทำได้โดยใครก็ตาม ตัวอย่างเช่นการรับรองความถูกต้องของ Google อาจผลิตการเรียกร้องรวมถึง "อีเมล" ของผู้ใช้ดังนั้นการแนบอีเมลนั้นกับข้อมูลประจำตัว Google ดำเนินการเรียกร้องแอปพลิเคชันจะเลือกว่าจะเข้าใจและยอมรับข้อเรียกร้องนั้นหรือไม่ แอปพลิเคชันเองอาจแนบการอ้างสิทธิ์ที่เรียกว่า "วิธีการรับรองความถูกต้อง" (เช่นเดียวกับ ASP.NET MVC Core Identity) ด้วยค่าของ "Google" การอ้างสิทธิ์แต่ละครั้งมีขอบเขตเพื่อให้สามารถระบุได้ว่าการอ้างสิทธิ์นั้นมีความหมายจากภายนอกท้องถิ่นหรือทั้งสองอย่าง (หรือมากกว่านั้นเป็นเม็ดเล็กตามต้องการ)

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

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

ในวงกว้างคุณควรพิจารณาการควบคุมการเข้าถึงตามคุณลักษณะ (ABAC) RBAC และ ABAC เป็นแนวคิดที่กำหนดโดย NIST สถาบันมาตรฐานและเทคโนโลยีแห่งชาติ ในทางกลับกัน CBAC เป็นรุ่นที่ Microsoft ผลักดันซึ่งคล้ายกับ ABAC มาก

อ่านเพิ่มเติมได้ที่นี่:

• การควบคุมการเข้าถึงตามบทบาทหน้า NIST
• การควบคุมการเข้าถึงตามคุณสมบัติหน้า NIST

พื้นฐานระหว่าง RBAC และ CBAC คือ:

อาร์แบค : ผู้ใช้จะต้องถูกกำหนดให้กับบทบาทที่ได้รับอนุญาตให้ดำเนินการ

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

นอกจากนั้นการอ้างสิทธิ์จะถูกส่งไปยังแอปพลิเคชันโดยบริการการอนุมัติ (Security Service Token STS) ที่แอปพลิเคชันของคุณเชื่อถือได้ (Relying Party)

บทบาทเป็นเพียงการอ้างสิทธิ์ประเภทเดียว เช่นนั้นอาจมีประเภทการอ้างสิทธิ์อื่น ๆ อีกมากมายตัวอย่างเช่นชื่อผู้ใช้เป็นหนึ่งในประเภทการอ้างสิทธิ์

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

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

การอนุญาตตามบทบาท https://docs.microsoft.com/en-us/aspnet/core/security/authorization/roles 10/14/2016 เมื่อมีการสร้างข้อมูลประจำตัวอาจเป็นของบทบาทอย่างน้อยหนึ่งบทบาท ตัวอย่างเช่นเทรซี่อาจอยู่ในบทบาทผู้ดูแลระบบและผู้ใช้ในขณะที่สก็อตต์อาจเป็นของบทบาทผู้ใช้เท่านั้น วิธีสร้างและจัดการบทบาทเหล่านี้ขึ้นอยู่กับที่เก็บข้อมูลสำรองของกระบวนการให้สิทธิ์ บทบาทมีการเปิดเผยต่อผู้พัฒนาผ่านวิธี IsInRole ในคลาส ClaimsPrincipal

การอนุญาตตามการอ้างสิทธิ์ https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims 10/14/2016 เมื่อมีการสร้างตัวตนมันอาจได้รับการเรียกร้องอย่างน้อยหนึ่งการเรียกร้องที่ออกโดยบุคคลที่เชื่อถือได้ การอ้างสิทธิ์คือคู่ค่าชื่อที่แสดงถึงสิ่งที่เป็นหัวเรื่องไม่ใช่สิ่งที่หัวเรื่องสามารถทำได้ ตัวอย่างเช่นคุณอาจมีใบขับขี่ซึ่งออกโดยหน่วยงานออกใบขับขี่ในประเทศ ใบขับขี่ของคุณมีวันเดือนปีเกิดของคุณ ในกรณีนี้ชื่อการอ้างสิทธิ์จะเป็น DateOfBirth ค่าการอ้างสิทธิ์จะเป็นวันเดือนปีเกิดของคุณเช่น 8 มิถุนายน 2513 และผู้ออกจะเป็นผู้มีอำนาจใบขับขี่ ง่ายที่สุดในการตรวจสอบค่าของการเรียกร้องและอนุญาตให้เข้าถึงทรัพยากรตามมูลค่านั้น ตัวอย่างเช่นหากคุณต้องการเข้าไนท์คลับกระบวนการอนุญาตอาจเป็น:

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

ข้อมูลระบุตัวตนสามารถมีการอ้างสิทธิ์หลายครั้งที่มีหลายค่าและสามารถมีการอ้างสิทธิ์หลายครั้งที่เป็นประเภทเดียวกัน

นอกจากนี้ยังเป็นไปได้ที่จะจัดการบทบาทในลักษณะการเรียกร้อง

แทนที่จะสร้างบทบาทการอนุญาตที่สะท้อนถึงบทบาททางธุรกิจให้สร้างบทบาทที่สะท้อนถึงบทบาทของการกระทำเช่น CreateCustomer, EditCustomer, DeleteCustomer อธิบายวิธีการตามที่ต้องการ

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

คุณสามารถแทนที่บทบาทธุรกิจและเพิ่มบุคคลในบทบาทการดำเนินการโดยตรง

เนื่องจากคุณสร้างสิ่งที่ได้ผลอยู่แล้วคุณจึงไม่เลิกทำการอนุญาตที่มีอยู่ คุณต้องมีอีกสองสามตารางเพื่อใช้วิธีนี้

ฉันคิดว่าคำถามนี้สามารถตอบได้จากฐานข้อมูลที่คาดหวัง หากคุณสังเกตเห็นว่าตารางที่เกี่ยวข้องกับการปลูกถ่ายคุณจะพบสิ่งต่อไปนี้

1. AspNetUsers: ผู้ใช้แต่ละคนมีหนึ่งแถวพร้อมคุณลักษณะทั้งหมดที่ผู้ใช้ทุกคนต้องการเช่นอีเมลโทรศัพท์ที่อยู่รหัสผ่าน .....
2. AspNetRoles; กำหนดบทบาทที่แตกต่างกันตามข้อกำหนดของแอปพลิเคชันเช่น GM, CTO, HRM, ADMIN, EMP สิ่งที่แต่ละบทบาทกำหนดนั้นเป็นไปตามความต้องการของแอปพลิเคชัน
3. AspNetUserRoles: แต่ละแถวเชื่อมโยง AspNetUsers และ AspNetRoles และเชื่อมโยงอย่างมีประสิทธิภาพระหว่างผู้ใช้หนึ่งคนและบทบาทมากมาย
4. AspNetUserClaims: แต่ละแถวมีคีย์ไปยัง AspNetUsers และหนึ่งประเภทและค่า เพิ่มแอตทริบิวต์หนึ่งรายการสำหรับผู้ใช้แต่ละรายที่สามารถเพิ่ม / ลบได้ในขณะใช้งาน

การใช้งานของตารางนี้สามารถปรับเปลี่ยนในช่วงเวลาหนึ่งของเวลาผู้ใช้ / แอปพลิเคชันเพื่อให้ตรงกับความต้องการเฉพาะ

พิจารณาช่วงแรกของ "ผู้จัดการฝ่ายจัดซื้อ" (PM) เราอาจมีสามวิธี

1. แอปพลิเคชันเติม AspNetUserRoles ด้วยหนึ่งแถวเพื่อให้สิทธิ์ 'PM' ในการซื้อ ในการออกคำสั่งซื้อด้วยจำนวนเงินใด ๆ ผู้ใช้จะต้องมีบทบาท "PM" เท่านั้น

2. แอปพลิเคชันเติม AspNetUserRoles ด้วยหนึ่งแถวเพื่อให้ได้สิทธิ์ 'PM' ในการซื้อและเติม AspNetUserClaims เพื่อเรียกร้องประเภท TYPE 'Purchase Amount' ประเภทและค่า "<1000" เพื่อกำหนดวงเงินจำนวน ในการออกคำสั่งซื้อผู้ใช้จะต้องมี 'PM' และจำนวนการสั่งซื้อจะน้อยกว่ามูลค่าการอ้างสิทธิ์ TYPE 'จำนวนการซื้อ'

3. แอปพลิเคชันเติม AspNetUserClaims ด้วยการอ้างสิทธิ์ประเภท 'จำนวนการสั่งซื้อ' และค่า "<1,000" ผู้ใช้สามารถออกคำสั่งซื้อโดยกำหนดจำนวนเงินให้น้อยกว่ามูลค่าการเคลมของประเภทการเรียกร้อง 'จำนวนการซื้อ' สำหรับผู้ใช้รายนี้

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

การควบคุมการเข้าถึงตามบทบาท (RBAC)

ในองค์กรของคุณคุณอาจมีบทบาทดังต่อไปนี้

ลูกจ้าง

ผู้จัดการ

ทรัพยากรบุคคล

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

ใน ASP.NET Core เพื่อใช้การอนุญาตตามบทบาทเราใช้แอตทริบิวต์อนุญาตกับพารามิเตอร์บทบาท

[Authorize(Roles = "Admin")]
public class AdministrationController : Controller
{
}

เรียกร้องการควบคุมการเข้าถึงตาม (CBAC)

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

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

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

[Authorize(Policy = "DeleteRolePolicy")]
public async Task<IActionResult> DeleteRole(string id)
{
}