2010-07-29 5 views
3

이러한 종류의 요구 사항이 있다고 가정 해 보겠습니다.기존의 세분화 된 액세스 제어 라이브러리/프레임 워크?

A1의 사용자 A는 A1 유형의 모든 엔티티를 업데이트 할 수 있어야합니다.

역할 BB의 사용자 B는 A1 ("2")라고하는 주 식별자가 "2"인 A1 유형의 엔티티 만 업데이트 할 수 있어야합니다. A1을 입력하되 유형 B2의 하위 엔티티를 엔티티 A1 ("2")에 추가하거나 삭제할 수 있습니다.

역할 CC의 사용자 C는 엔티티 A1 ("2")에 속하는이 하위 B2 엔티티의 대부분은 편집 할 수 있어야하며, 역할 CC의 구성원은 A1에서 B2 엔티티를 추가하거나 제거 할 수 없어야합니다 ("2").

사용자 D는 역할 BB와 역할 CC에 있으며 조합 된 구성원 자격의 결과로 두 가지 권한 집합 (이 경우 역할 CC 권한은 역할 BB, 이것은 사용자 D가 역할 BB에 허용 된 모든 것을 할 수 있음을 의미합니다).

등등. 이러한 정책은 배포 후에 변경 될 수 있으므로 변경 사항을 구현하기 위해 대규모 재개발 작업 (예 :이 문제를 해결하는 데 필요한 선언적 방법)이 필요하지 않습니다.

ACL (액세스 제어 목록)은 보호되는 개체의 옆 또는 내부에 저장된다고 가정합니다.

나는 코드를 작성하는 개발자가 현재의 주인을 식별하는 인수, 고려 대상의 객체, 고려중인 작업과 함께 단일 메소드/함수/연산/프로 시저를 명령 적으로 (선언적으로) 쿼리 할 수 ​​있어야한다고 가정한다. 어쩌면 우리는 이것을 특권이라고 부름), 연산이 허용되어야하는지 아니면 거부되어야 하는지를 나타내는 하나의 부울 값을 검색합니다.

내 가정에 자유롭게 의견을 말하십시오.

이제는 이미 간단하지만 효과적인 독점적 인 솔루션을 염두에두고 있습니다. (이미 제작에 전념했으며 잘 작동하고 있습니다.) 나는 이것을 오픈 소스 프로젝트로 발표 할 것을 고려 중이다.

하지만 다음 레벨로 가져 가서이 짐승 같은 물건을 만들기 전에 널리 받아 들여지는 시스템, 모듈 또는 라이브러리 (반드시 .NET 일 필요는 없음)를 이미 알고 있었는지 궁금했습니다. 엔티티에 대한 이러한 종류의 세분화 된 제어 (ORM에있는 데이터베이스 레코드 또는 객체를 의미하든간에)를 구현합니다.

P.W. 이것을 SO에 게시하기 전에 답을 검토하면서 Zend_Acl이 LAMP 프로젝트를위한 이런 종류의 기능을 가지고 있다고 제안한 다른 곳에서 (SO LINK) 답변을 찾았지만 대신 .NET/Windows 솔루션을 선호합니다.

답변

1

필자가 필요로했던 것 (그리고 내가 왜 그것을 보지 못했는지 알지 못함)이 Windows AzMan 이었음을 나타냅니다. 상속 가능한 ACL과 같은 작업을 수행하는 방법을 파악하는 데 약간의 작업이 필요했지만 스코프를 창의적으로 사용하면 관리가 쉽고 유연하며 빠른 시스템을 갖게되었습니다.

AzMan은 완전히 흔들리지 만 문서의 내용은 조금 남습니다.

0

Rhino Security보세요. 가정을 바꿀 수도 있습니다 ...

+0

Rhino Security를 ​​보았지만 NHibernate를 사용하고 있지 않습니다. Rhino Security가이를 위해 빌드 된 것처럼 보입니다. 그것이 사실이라면, 내가하려는 일에 충분히 목적이있는 것은 아닙니다.나는 틀린가? –