.NET 애플리케이션의 권한 / 올바른 모델 / 패턴

유연하고 간단하게 구현해야하며 (가능한 경우) 내장 된 수단을 사용하십시오.

지금까지 MembershipProvider와 RoleProviders를 구현했습니다. 이것은 시원하지만 다음에 어디로 가야합니까?

"Priviledge"라는 용어를 추가하고 응용 프로그램 내부의 용어를 하드 코딩하는 것보다 느낌이 듭니다. 사용자는 권한을 역할에 추가하고 역할을 사용자에게 할당하도록 역할을 구성합니다.

좋은 모델처럼 들립니까? 역할에 권한을 추가하는 것 외에도 사용자 수준에서 권한을 추가하는 것에 대해 생각해야합니까? 설치 (혼동) 및 지원에 문제가있을 수 있습니다.

내가 그렇게하지 않으면 일부 특정 사용자에게는 권한이 덜 필요합니다. 관리자는 다른 역할 등을 만들어야합니다.

이와 같은 시스템에 대한 은색 총알이 있습니까? 그리고 왜 Microsoft가 회원 및 역할 제공 업체보다 더 나아 가지 않았습니까?

또 다른 아이디어 : 역할을 "프라이버시"보유자로두고 하드 코딩하십시오. 그런 다음 사용 가능한 모든 마크 업 / 속성 등 모든 Microsoft를 사용하여 앱 내에서 해당 역할을 코딩 할 수 있습니다.

새로운 엔티티 "그룹"을 추가하고 이와 같은 관계를 만듭니다

• 사용자
• 사용자 그룹
• 여러 떼
• 역할 그룹
• 역할

이를 통해 역할을 그룹으로 수집하고 해당 그룹을 사용자에게 할당 할 수 있습니다. 훌륭하게 들리고 다른 소프트웨어 패턴과 일치합니다. 그러나 RoleProvider 내부에서 실제로 다음과 같은 것을 구현할 수 없습니다.

• AddUsersToRoles
• 역할에서 사용자 제거

그리고 일부는 하드 코딩되어 더 이상 의미가 없습니다.

• 역할 삭제
• 역할 만들기

역할 기반 권한 부여가 충분하지 않은 경우 클레임 기반 권한 부여 사용을 고려하십시오 .

클레임은 ACL의 항목과 같은 일종의 자원 및 활동을 설명하지만 "자원"은 물리적 객체 일 필요는 없으므로 원하는대로 할 수 있으며 정보를 포함 할 수 있으므로 더 유연합니다. 당신이 원합니다.

이 모델에서 클레임은 "권한"이라고하는 것과 동일하며 클레임을 클레임 집합으로 그룹화합니다. 이는 "역할"이라고하는 것과 거의 같습니다. 이러한 모든 API 등은 이미 System.IdentityModel네임 스페이스에 있습니다.

물론 당신은 언급 MembershipProvider하고 RoleProvider와 (그 이름에서 알 수 있듯이) 당신은 모든 ASP.NET 회원 모델로이 벼락 공부하려는 경우, 다음 그냥 잊어. 해당 제공자 API를 사용하려면 자신의 방식으로 수행해야하며 역할의 개념보다 더 세분화되지는 않습니다.

대신 ASP.NET에서 "권한"개념은 실제로 작업 또는 작업 수준 에서 인코딩되어 해당 작업 을 실행할 수있는 역할을 선언합니다. ASP.NET MVC에서는 [AuthorizeAttribute]컨트롤러 나 컨트롤러 작업 을 처리하기가 훨씬 쉽습니다 . "구식"ASP.NET에서는 이벤트를 처리하고 있으므로 권한 부여는 임시 또는 페이지 수준 (또는 둘 다) 인 경향이 있습니다.