2010-09-10 34 views
16

Tôi hiện đang phát triển quản trị thành viên cho một hiệp hội địa phương tại đây và tôi đang phát triển lược đồ cơ sở dữ liệu vào lúc này. Tôi muốn chia sẻ nó với bạn để cải thiện nó và đưa ra một ví dụ khác về Mô hình Truy cập Dựa trên Vai trò (RBAC). Tôi đánh giá cao bất kỳ lời chỉ trích mang tính xây dựng đặc biệt là về các mối quan hệ tôi đã sử dụng giữa các bảng.Lược đồ DB của điều khiển truy cập dựa trên vai trò

Liên kết đến highres: http://i.stack.imgur.com/WG3Vz.png

Heres schema: DB Schema

Cách hoạt động:

Tôi đang lập bản đồ các khách hàng hiện có (trên thực tế các thành viên của hiệp hội) từ một ứng dụng bên ngoài vào chính quyền của tôi ứng dụng. (bảng khách hàng)

Hiệp hội được cấu trúc trong Phân khu, Phân khu, v.v. (bảng nội bộ). Mỗi khách hàng có thể là thành viên trong nhiều Phòng, Phân khu, Chi tiết, v.v.

Mỗi khách hàng có thể có một hoặc nhiều vai trò trong các thành viên như vậy (đơn vị, ...) như Chủ tịch, Hiệu trưởng, Thủ quỹ, v.v ... các đặc quyền mà chủ sở hữu vai trò có thể áp dụng cho những người khác trong Bộ phận, Phân ngành, Mục, v.v.

Thông tin xác thực của bạn được kết nối với một hành động nhất định của ứng dụng. Chủ sở hữu chứng chỉ có thể thực thi hành động này đối với các thành viên khác trong phạm vi của mình. Có thể có nhiều ứng dụng "độc lập" nhưng tất cả đều có cùng hệ thống xác thực/ủy quyền.

Ứng dụng được cấu trúc trong Mô-đun/Mô-đun con/Tác vụ v.v. Ví dụ có thể là mô-đun "Chi tiết cá nhân" và mô-đun này chứa mô-đun con được gọi là "Hình ảnh" và bạn có thể áp dụng các hành động "xem, xóa, chỉnh sửa" bức ảnh này Nhưng bạn không thể xóa bất kỳ hình ảnh nào trừ khi người mà hình ảnh bạn cố xóa nằm trong một bộ phận/phần mà bạn có vai trò phù hợp để làm như vậy.

Cấu trúc bên trong và ứng dụng là cả hai cây, được triển khai dưới dạng danh sách kề nhau bộ lồng nhau. Danh sách adjacency đảm bảo tính toàn vẹn và tập hợp lồng nhau cho phép tôi đi ngang qua cây một cách nhanh chóng.

Một ngoại lệ là bạn có thể trực tiếp cung cấp cho ai đó thông tin đăng nhập nhất định (client_credentials). Điều này là cần thiết nếu ai đó cần thực hiện một số hành động nhất định đối với ai đó không có trong phần/phần của mình.

Vì vậy, ai đó có thể là thành viên trong nhiều divsions/section và có được nhiều vai trò trong mỗi bộ phận/phần anh ấy là thành viên. Tôi sẽ hợp nhất tất cả các thông tin cá nhân mà ai đó có thông qua nhiều vai trò của mình. Và thông tin đăng nhập luôn là tích cực, có nghĩa là thông tin đăng nhập hạn chế là không thể.

+0

Đây là khái niệm về hệ thống RBAC đơn giản: http://stackoverflow.com/questions/28157798/is-my-role-based-access-control-a-feasible-solution/28159647#28159647 – sled

Trả lời

3

Tôi sẽ đưa ra một ví dụ khác về hệ thống RBAC mà tôi thực sự thích. hãy kiểm tra khung công tác radicore của Tony Marston here.

Tôi không chắc liệu nó có đáp ứng tất cả các yêu cầu của bạn hay không nhưng thứ bạn có thể so sánh với công việc của mình có thể hữu ích.

0

tôi dường như không thể nhìn thấy hầu hết các ánh xạ RBAC, chẳng hạn như:

Operation = Any action, such as CRUD operations 
Object  = Reference to any object instance 

Permission = Mapping of 'Operation' + 'Object' 

Tôi không chắc chắn những gì tất cả các bảng "ủy nhiệm" của bạn? Thông tin xác thực thường giữ các thuộc tính để chứng minh danh tính của một người (ví dụ: tên người dùng/mật khẩu). Tại sao bạn có thông tin đăng nhập cho vai trò?

Các vấn đề liên quan