2012-11-25 5 views
3

누구나 MongoDB에서 모델링 액세스 제어 예제가 있습니까? 내가 생각하고있는 상황은 다음과 같습니다.MongoDB에서 액세스 제어 모델링

각자 고유 한 문서 (예 : 자동차, 사람, 나무 등)가 있습니다.

사용자는 명시 적 승인을 통해 자원에 액세스하거나 다른 소유자 (예 : 역할) 또는 다른 암시적인 방법으로 존재하는 자원의 소유자가 됨으로써 암시 적으로 자원에 액세스 할 수 있습니다.

건너 뛰기 및 제한 옵션이 적용될 수있는 collection.find() 메서드에서 이러한 모든 명시 적 및 암시 적 경로를 확인하고 사용자가 액세스 할 수있는 리소스의 결과를 생성하는 방법이 있습니까?

MySQL에서는 리소스 ID, 사용자 ID 부여, 허가 된 사용자 ID 및 작업 (읽기, 쓰기 등)을 포함한 권한 테이블을 사용하여이를 모델링했습니다. 그런 다음 하나의 쿼리에서 적어도 하나의 하위 쿼리가 참인 모든 리소스를 선택하면 하위 쿼리는 액세스 할 수있는 모든 다른 경로를 확인합니다. 보조금에 대해 하나 개의 검사, 소유권에 대한 하나 개의 검사 등

난 그냥 MongoDB의에서이 일을 주위에 내 머리를 정리 할 수없는, 나는 그것도 가능하다면 확실하지 않다 ...

감사

답변

3

한 번에 둘 이상의 문서를 쿼리 할 수 ​​없습니다. 이상적으로는 비즈니스 로직의 일부로 컨트롤에 액세스해서는 안됩니다. 백엔드 PHP/C#/언어는 현재 요청이 승인되어야합니다. 그렇다면 요청 된 문서를 쿼리하면됩니다.

만약 당신이 mongodb에서 똑같은 구조체를 구현할 필요가 있다면, 그렇게하지 말 것을 제안합니다. 그런 다음 모든 필드들을 임베드해야합니다 (다른 mysql 테이블의 것들을 포함해야합니다. 요청은 모든 컬렉션의 모든 문서에서 승인됩니다. 데이터 복제 (비정규 화). 어느 것이 모든 사본이 업데이트되고 동일한 가치를 지니고 있는지 확인해야한다는 두통을 불러옵니다.

편집 1 :

자동차 문서에 대해 이야기 해 보겠습니다. 소유자를 추적하려면 owner 속성이 있어야합니다 (소유자 문서의 _id 포함). 자동차를 '사용'(명시 적 승인) 할 수있는 모든 사용자를 추적하려면 배열 allowerdDrivers (각 user 문서의 _id 포함)이 있어야합니다. 요청을하는 현재 사용자가 'admin'역할에 속한다고 가정합니다. user 문서의 applicableRoles 배열은 적용 가능한 각 역할 문서의 _id을 저장합니다.

사용자가 액세스 할 수있는 모든 차량을 검색하려면 검색어를 두 번 만들어야합니다. 하나는 그의 역할을 가져옵니다. 관리자 인 경우 모든 차량을 반환하십시오. 그렇지 않다면 owner과 그의 ID가 같음 orallowedDrivers에 id가 들어있는 다른 쿼리를 만듭니다.

실제 사용 사례가 더 복잡 할 수도 있음을 알고 있습니다 만,이를 해결할 문서 지향적 인 방법이 있습니다. 데이터를 문서에서 모델링하는 방식이 RDbMS에서 모델링하는 방식과 크게 다르다는 것을 인식해야합니다.

+0

나는 이것이 사실일지도 모른다라고 생각했다. 비즈니스 로직에서 그렇게하는 것은 고통스럽고 느리고 비효율적입니다. 이러한 리소스를 검색하거나 나열하는 경우 해당 리소스를 모두 또는 하나씩 읽은 다음 비즈니스 논리를 적용하고 실패 할 경우 비즈니스 논리를 적용하고 페이지 매김 제한이있을 때까지 계속 읽어야합니다. 질의시 데이터 계층에서 처리하는 것이 훨씬 더 복잡하지만 가치가 있습니다. 전체 또는 일부를 업데이트하려는 경우 복제가 트랜잭션없이 위험 해 보입니다. MongoDB가 우리의 유스 케이스에 적합하지 않은 것 같습니다. – Tyler

+0

내 대답이 업데이트되었습니다. 그냥 제안, mongodb 구글 사용자 그룹에이 질문을 할 수 있습니다. 나는 대부분의 애플 리케이션에서 더 좋지 않다면 문서 데이터베이스가 잘 작동 할 수 있다고 생각한다. 그리고 앱이 규칙의 예외는 아닐 수도 있습니다. –

+0

답변을 수락 - 키가 나를 데려가는 것은 1 개 이상의 쿼리를 수행하는 것이 좋습니다. :) – Tyler

0

비즈니스 논리에서 수행하는 것은 매우 느리고 비효율적입니다.

어떻습니까?이것은 비즈니스 로직입니다. 사용자 a가 게시물 B를 소유하고 있다면 액션 (MVC 스타일)을 수행하고, 그렇지 않으면 수행하지 않습니다.

저에게 비즈니스 로직처럼 들리지만 대부분의 프레임 워크는이 비즈니스 로직을 (MVC 패러다임의) 컨트롤러 액션 내에 배치한다고 생각합니다. 즉 PHP Yii :

Yii::app()->roles->hasAccess('some_view_action_for_a_post', $post) 

데이터베이스 끝에서 처리하면 비즈니스 계층과 저장소 계층이 혼동을 야기한다고 생각합니다.

또한 일부 역할 기반 권한 동작이 커밋 된 쿼리를 얼마나 복잡하게 만들지는 여부는 많은 하위 선택으로 상당히 커야합니다. MySQL이 결과 집합을 생성하고 처리하는 방법 (하위 선택은 조인이 아님)을 고려할 때 이러한 쿼리가 특히 잘 확장되지 않는다는 느낌이 들었습니다.

또한 역할을 변경하려는 경우 또는 특정 개체에 액세스 할 수있는 역할을 정의하는 기능을 고려해야 할 경우 역할 테이블에 역할을 추가하는 대신 직접 SQL 쿼리를 변경해야합니다 해당 역할에 대한 객체 속성을 할당하고 그 역할 (AKA 코드 변경)을 사용자에게 할당하는 것입니다.

다른 언어 (및 사용자 자신의)에서 다른 프레임 워크가 RBAC를 수행하는 방법에 대해 심각하게 생각해 보았습니다. 선을 흐리게 만들었고 수행 한 작업을 상당히 힘들게 만들었 기 때문에 사실 여기에 시작할 수있는 좋은 장소 : Group/rule-based authorization approach in node.js and express.js