Nguyễn Văn Thanh



tải về 296.99 Kb.
trang5/11
Chuyển đổi dữ liệu05.09.2016
Kích296.99 Kb.
#31705
1   2   3   4   5   6   7   8   9   10   11

2.6. Role có cấp bậc




(a)



(b)



(c)

Hình 2.3: Các ví dụ của Role Hierarchies



(a) Role Hierarchies



(b) Quản lý Role Hierarchies



(c) Sự riêng tư và phạm vi của Role
Hình 2.4: Role Hierarchies cho một dự án

Mô hình RBAC1 giới thiệu role có thứ bậc (RH), giống như đã trình bày sơ qua trong Hình 2.1. Chúng cũng được cài đặt thông thường trong hệ thống như các role cung cấp. Role có thứ bậc có một nghĩa tự nhiên cho các role có cấu trúc để phản ánh một tổ chức của permission và trách nhiêm. Ví dụ về role có thứ bậc được thấy trong Hình 2.3. Bởi việc quy ước các role nhiều quyền lực hơn được hiện thị phía trên các sơ đồ và các role ít quyền lực hơn phía dưới sơ đồ. Trong Hình 2.3(a) role của người có chức vụ thấp là Health-care provider. RolePhysician là người có chức cao hơn Health-care provider và do đó thừa kế tất cả các permission từ Health-care provider. Thừa kế của permission nói rõ ra, cho ví dụ, trong Hình 2.3(a), rolePrimary-care Physician thừa kế permission từ PhysicianHealth-care provider. Cả Primary-care PhysicianSpecialist Physician đều thừa kế permission từ role của Physician, nhưng mỗi loại này sẽ có những permission khác nhau được gán trực tiếp tới chúng. Hình 2.3(b) giải thích đa thừa kế của permission, nơi mà role Project Supervisor thừa kế cả role của TesterProgrammer.

Bằng chứng là, những cấp bậc này thứ tự từng phần. Một thứ tự từng phần là một phản thân, bổ ngữ trực tiếp và không đối xứng. Sự thừa kế là phản thân bởi vì một role thừa kế permission riêng của nó, bổ ngữ trực tiếp là một yêu cầu tự nhiên trong ngữ cảnh này, và quy tắc không đối xứng ngoài các role mà thừa kế từ một cái khác và vì thế sẽ không cần thiết.

Công thức định nghĩa của RBAC1 được đưa ra bên dưới.

Định nghĩa 2 mô hình RBAC1 có những thành phần sau:


  • U, R, P, S, PA, UA, và user không được thay đổi từ RBAC0,

  • RH R x R là một phần thứ tự trên R gọi là role có cấp bậc hay mối quan hệ role có ưu thế hơn, cũng được viết như , và

  • roles : S2R được thay đổi từ RBAC0 để yêu cầu các role (si) { r | (r’ r)[(user(si), r’)UA]}.



Hình 2.5: Mô hình tổng quát của RH (RBAC1)

Chú ý rằng một user được cho phép tới thiết lập một session với nhiều sự kết hợp của role người chức vụ thấp tới user là thành viên của nó. Hơn nữa, các permission trong một session được gán trực tiếp tới các role của session cũng tốt như việc được gán tới các role của người cấp bậc thấp tới những cái này.



Điều này thỉnh thoảng có ích trong thứ bậc để hạn chế phạm vi của thừa kế. Xem xét thứ bậc của Hình 2.3(b) nơi mà role Project Supervisor là người cấp cao hơn role của cả TesterProgrammer. Bây giờ giả sử rằng Tester mong muốn giữ một vài permission riêng tư tới role của họ và chống lại sự thừa kế của họ trong thứ bậc tới người điều hành dự án. Tình hình này có thể tồn tại cho lý do chính đáng, cho ví dụ, truy cập tới một công việc chưa hoàn thành trong tiến trình có thể không thích hợp cho một người có chức vụ cao hơn trong khi RBAC có thể hữu ích có thể giống như truy cập tới Tester. Tình hình này có thể được giúp đỡ bởi việc định nghĩa một roleTest Engineer0 mới và liên quan tới nó tới Test Engineer như hiển thị trong Hình 2.3(c).

Permission riêng tư của các Test Engineer có thể được gán tới role Test Engineer0. Test Engineer được gán tới role Test Engineer0 và thừa kế permission từ roleTest Engineer, mà được thừa kế ở trên trong hệ thống thứ bậc bởi roleProject Supervisor. Permission của Test Engineer0, tuy nhiên, không được thừa kế bởi role Project Supervisor. Có thể gọi các role giống như Test Engine0 như các role riêng tư. Hình 2.3(c) cũng hiển thị một role riêng tư của Programmer0. Trong một vài hệ thống hiệu quả của các role riêng tư đạt được bởi khối bên trên thừa kế của các permission chắc chắn. Trong một vài trường hợp của hệ thống thứ bậc không mô tả sự phân phối của permission chính xác. Điều này thích hợp để giới thiệu các role riêng tư và giữ nghĩa của hệ thống thứ bậc liên quan xung quanh những role không thay đổi.

Hình 2.4 hiển thị, nhiều điểm chung, một hệ thống thừa kế con của các role có thể được xây dựng như thế nào. Hệ thống thứ bậc của Hình 2.4(a) có bốn role công việc, T1, T2, T3, T4, tất cả đều thừa kế permission từ role dự án phổ biến rộng P. Role S ở trên cùng của hệ thống thứ bậc dành cho Project Supervisor. Công việc T3T4 là một dự án con với P3 như role dự án con rộng, và S3 như role giám sát dự án con. Role T1’ trong Hình 2.4(c) là một role riêng tư cho những thành viên của những nhiệm vụ T1. Giả sử dự án con trong Hình 2.4(a) gồm có vai trog S3, T3, T4P3, yêu cầu một hệ thống thứ bậc con riêng tư trong các permission riêng tư của dự án có thể được chia sẻ ngoài hệ thống thứ bậc bởi S. Trong toàn thể hệ thống cấp bậc con được tái tạo trong dáng vẻ được hiện thị trong Hình 2.4(c). Các permission có thể thừa kế bởi S có thể được gán tới S3, T3, T4P3, thích hợp trong khi một trong các quyền riêng tư có thể được gán tới S3, T4, T4P3’, cho phép những sự thừa kế của chúng chỉ trong dự án con. Nhưng trước khi thành viên của đội dự án con được gán trực tiếp tới S3’, T3’, T4’, hay P3’. Hình 2.4(c) làm cho nó rõ ràng như các role riêng tư tồn tại trong hệ thống và trợ giúp trong việc truy cập để xem lại tới quyết định sự tự nhiên của các permission riêng tư là gì.


tải về 296.99 Kb.

Chia sẻ với bạn bè của bạn:
1   2   3   4   5   6   7   8   9   10   11




Cơ sở dữ liệu được bảo vệ bởi bản quyền ©hocday.com 2024
được sử dụng cho việc quản lý

    Quê hương