Quy tắc Biểu thức
r1: luồng công việc yêu cầu có ít nhất bốn người dùng tham gia (một người nhận và kiểm tra bài báo, hai người phản biện, và một người nữa sẽ quyết định cuối cùng).
r1: cannot_access(_, r, _, _) ← type(r)='workflow', card(getRoles(r)) < 4 ;
r2: người dùng mà nhận bài (T1) cũng sẽ kiểm tra sơ bộ bài đó (T2).
r2: cannot_access(s, getCurrentTasks(r), {RUN},_) ← type(r)='workflow', not
isRun(s, r, T1), getTask-
Name(getCurrentTask(r)) = T2 r3: Hai tác giả phản biện các bài (T3 và T4)
phải là hai người khác nhau.
r3: cannot_access(s, getCurrentTasks(r), {RUN},_) ← type(r)='workflow',
isRun(s, r, T3), getTask-
Name(getCurrentTask(r)) = T4;
r3.2: cannot_access(s, getCurrentTasks(r), {RUN},_) ← type(r)='workflow', isRun(s, r, T4), getTask-Name(getCurrentTask(r)) = T3;
123
Thành phần chính trong thiết kế này là Security component, được thiết kế tuân theo kiến trúc tiêu chuẩn của các hệ thống ABAC (attributed-based access control) XACML (eXtensible Access Control Markup Language) [43], bao gồm ba module:
- PEP (Policy Enforcement Point): module thực hiện các điều khiển truy nhập, bao gồm các bước như sau: đầu tiên, nó tiếp nhận các lời gọi của các dịch vụ bên ngoài (data flow (1)) từ các tiến trình trong G-ODE engine. Sau đó, các lời gọi này sẽ được dịch thành các yêu cầu (requests) ở dạng chuẩn (well-defined forms) (luồng dữ liệu (2)). Các yêu cầu này sau đó sẽ được chuyển cho module PDP.
- PDP (Policy Decision Point): Sau khi tiếp nhận các yêu cầu từ PEP, module này sẽ đánh giá chúng dựa trên các chính sách an ninh (bao gồm tập các quy tắc truy nhập), để từ đó đưa ra quyết định trả về cho PEP (luồng dữ liệu (3)). Quyết định này thường là chấp nhận hoặc từ chối truy nhập.
- PIP (Policy Information Point): module này hoạt động như một nguồn giá trị cho các thuộc tính. Nó cũng chứa tập các hàm tiện ích của hệ thống.
Ý nghĩa của các luồng dữ liệu trao đổi giữa các module (từ (1) đến (6)) được tóm tắt trong Bảng 4-5.