สิทธิ์ / รูปแบบ / รูปแบบที่ถูกต้องสำหรับ. NET application


9

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

จนถึงตอนนี้ฉันได้นำ MembershipProvider และ RoleProviders มาใช้ นี่เจ๋ง แต่ฉันจะไปไหนต่อ

ฉันรู้สึกว่าฉันต้องการเพิ่มคำว่า "Priviledge" และมากกว่า hardcode ที่อยู่ในแอปพลิเคชัน ผู้ใช้จะกำหนดค่าบทบาทเพื่อเพิ่มสิทธิ์ให้กับบทบาทและกำหนดบทบาทให้กับผู้ใช้

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

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

กระสุนเงินสำหรับระบบเช่นนี้? และทำไม Microsoft ไม่ไปไกลกว่านี้เพียงแค่ผู้ให้บริการสมาชิกและบทบาท?

ความคิดอื่น: ปล่อยให้บทบาทเป็นผู้ถือ "priviledge" และ hardcode พวกเขา จากนั้นฉันสามารถโค้ดไปยังบทบาทเหล่านั้นภายในแอปโดยใช้มาร์กอัพ / คุณลักษณะที่มีอยู่ทั้งหมด - Microsoft ทั้งหมด

เพิ่มเอนทิตีใหม่ "กลุ่ม" และสร้างความสัมพันธ์เช่นนี้

  • ผู้ใช้
  • กลุ่มผู้ใช้
  • กลุ่ม
  • RoleGroups
  • บทบาท

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

  • AddUsersToRoles
  • RemoveUsersFromRoles

และบางสิ่งก็ไม่สมเหตุสมผลอีกต่อไปเพราะมันจะถูกเข้ารหัสยาก

  • DeleteRole
  • CreateRole

คำตอบ:


5

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

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

ในรุ่นนี้การอ้างสิทธิ์เทียบเท่ากับสิ่งที่คุณเรียกว่า "สิทธิ์" และคุณจัดกลุ่มการเรียกร้องเป็นชุดการเรียกร้องซึ่งเทียบเท่ากับสิ่งที่คุณเรียกว่า "บทบาท" API เหล่านี้ทั้งหมดและอื่น ๆ อยู่ในSystem.IdentityModelเนมสเปซแล้ว

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

โดยปกติแล้วใน ASP.NET แนวคิดของ "สิทธิ์" จะถูกเข้ารหัสที่ระดับการดำเนินการหรือการดำเนินการซึ่งคุณประกาศบทบาทที่อนุญาตให้เรียกใช้การกระทำนั้นได้ นี่เป็นเรื่องง่ายมากที่จะจัดการกับใน ASP.NET MVC ที่คุณเพียงแค่ตบ[AuthorizeAttribute]ตัวควบคุมหรือการกระทำของตัวควบคุม; ใน "old-school" ASP.NET คุณกำลังจัดการกิจกรรมดังนั้นการให้สิทธิ์อาจเป็น ad-hoc หรือที่ระดับหน้า (หรือทั้งสองอย่าง)


ข้อมูลดีๆมากมายขอบคุณ! แอปเป็นแอป Silverlight ที่มีส่วนของเซิร์ฟเวอร์แสดงเป็นบริการ WCF RESTful การอ้างสิทธิ์ดูน่าสนใจ แต่ฉันไม่ได้สังเกตเห็นแนวคิดของผู้ใช้และการทำให้เป็นอัตโนมัติภายในนั้น บทความที่น่าสนใจที่ฉันเพิ่งค้นพบ: geekswithblogs.net/shahed/archive/2010/02/05/137795.aspx
katit

@katit: แทบทุกการตรวจสอบ / อนุมัติใน .NET จะขึ้นอยู่กับอินเตอร์เฟซ IPrincipal หากคุณกำลังดำเนินการให้สิทธิ์ตามการอ้างสิทธิ์คุณต้องใช้IClaimsPrincipalสำหรับการดำเนินการนั้นและส่งIPrincipalไปที่IClaimsPrincipalเมื่อคุณต้องการตรวจสอบการอ้างสิทธิ์ คุณจะเขียนโค้ดจำนวนมากของคุณเองหากคุณต้องการให้พอดีกับ (เช่น) การตรวจสอบสิทธิ์ของฟอร์ม แต่เห็นได้ชัดว่าสามารถทำได้ (ตามลิงค์)
Aaronaught

คำถามคือ .. อาจจะง่ายกว่าที่จะเพิ่มระดับ "กลุ่ม" อีกระดับให้กับผู้ให้บริการสมาชิก / บทบาทหรือเขียนผู้ให้บริการของตัวเอง? จำนวนงานที่
ค่อนข้างใกล้เคียง

3
@katit: คำสุดท้ายที่โด่งดัง อย่าประดิษฐ์ของคุณเองเว้นแต่คุณจะมีเหตุผลที่ดีในการคิดค้นของคุณเอง ("ดูง่ายขึ้น" ไม่ใช่เหตุผลที่ดีมันจะดูง่ายขึ้นเมื่อคุณไม่มีประสบการณ์โดยตรงเท่านั้นและไม่มีความสามารถในการตัดสิน ปริมาณงานที่ต้องการ)
Aaronaught
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.