Mở rộng công cụ Activiti cho đặc tả và cài đặt chính sách an ninh

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (2.01 MB, 59 trang )

(1)<div class='page_container' data-page=1>

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

ĐỖ ANH VIỆT

MỞ RỘNG CÔNG CỤ ACTIVITI CHO

ĐẶC TẢ VÀ CÀI ĐẶT CHÍNH SÁCH AN NINH

Ngành: Cơng nghệ Thông tin

Chuyên ngành: Kỹ thuật phần mềm

Mã số: 60480103

LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN

NGƯỜI HƯỚNG DẪN KHOA HỌC: TS. ĐẶNG ĐỨC HẠNH

</div>
(2)<div class='page_container' data-page=2></div>
(3)<div class='page_container' data-page=3>

LỜI CAM ĐOAN

Tôi xin cam đoan luận văn thạc sĩ “Mở rộng cơng cụ Activiti cho đặc tả và cài

đặt chính sách an ninh” là cơng trình nghiên cứu của riêng tôi và được sự hướng dẫn

của TS. Đặng Đức Hạnh. Các nội dung nghiên cứu và kết quả trong đề tài là trung
thực và chưa từng được ai công bố trong bất kỳ cơng trình nào khác.

Những phân tích, đánh giá được tác giả thu thập từ các nguồn khác nhau có ghi rõ
trong tài liệu tham khảo.

Học viên thực hiện

Đỗ Anh Việt

</div>
(4)<div class='page_container' data-page=4>

Để hoàn thành được luận văn thạc sĩ, bên cạnh sự nỗ lực của bản thân cịn có sự
hướng dẫn nhiệt tình của q Thầy Cơ, cũng như sự động viên ủng hộ của gia đình và
bạn bè trong suốt quá trình nghiên cứu và thực hiện luận văn.

Tơi xin chân thành bày tỏ lịng biết ơn sâu sắc đến Thầy TS. Đặng Đức Hạnh,
người đã tận tình hướng dẫn và tạo mọi điều kiện tốt nhất cho tơi hồn thành luận văn
này. Xin chân thành cảm ơn các thầy cô khoa Công nghệ thông tin, Trường đại học
Công Nghệ đã truyền đạt những kiến thức quý báu cũng như giúp đỡ tơi trong q
trình học tập nghiên cứu tại trường.

Xin chân thành cảm ơn Trung tâm Tư vấn Thiết kế Mobifone đã cho phép và
tạo điều kiện để triển khai kết quả nghiên cứu của luận văn.

Cuối cùng, xin gửi lời cảm ơn đến gia đình, bạn bè, đồng nghiệp, những người
đã hỗ trợ tôi trong suốt quá trình học tập, nghiên cứu và thực hiện luận văn.

Học viên thực hiện

Đỗ Anh Việt

</div>
(5)<div class='page_container' data-page=5>

Trang

LỜI CAM ĐOAN...i

LỜI CẢM ƠN...ii

MỤC LỤC...iii

DANH SÁCH CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT...v

DANH SÁCH CÁC HÌNH VẼ...vi

MỞ ĐẦU...1

CHƯƠNG 1. KIẾN THỨC NỀN TẢNG...3

1.1. Giới thiệu chương...3

1.2. Mơ hình hóa chun biệt miền...3

1.2.1. Khái niệm...3

1.2.2. Ngơn ngữ mơ hình hóa chun biệt miền...6

1.3. Mơ hình hóa đặc tả chính sách truy nhập RBAC...8

1.3.1. RBAC và các ràng buộc phân quyền...8

1.3.2. MetaModel cho RBAC...10

1.4. Mơ hình hóa và thực thi quy trình nghiệp vụ với Activiti...11

1.4.1. Mơ hình hóa quy trình nghiệp vụ...12

1.4.2. Cơng cụ Activiti...17

1.5. Kết luận chương...20

CHƯƠNG 2. TÍCH HỢP MƠ ĐUN CHÍNH SÁCH TRUY CẬP RBAC VỚI

ACTIVITI...21

2.1. Giới thiệu chương...21

2.2. Phương pháp tích hợp RBAC vào BPM...21

2.3. Tích hợp RBAC vào Activiti BPM...23

2.3.1. Một số khái niệm...24

2.3.2. Mơ hình hóa các chính sách truy nhập RBAC...25

2.4.3. Thực thi các chính sách truy nhập RBAC...35

2.4. Tổng kết chương...37

CHƯƠNG 3. CÀI ĐẶT VÀ THỰC NGHIỆM...38

</div>
(6)<div class='page_container' data-page=6>

3.2. Bài toán vận tải...38

3.3. Cài đặt trên Activiti...39

3.3.1. Cài đặt Activiti BPM...39

3.3.2. Mô hình hóa quy trình trên Activiti Designer...41

3.3.3. Triển khai quy trình trên Activiti Explorer...47

3.4. Kết quả thực nghiệm...48

3.5. Tổng kết chương...52

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN...53

TÀI LIỆU THAM KHẢO...54

</div>
(7)<div class='page_container' data-page=7>

Từ viết

tắt Thuật ngữ Ý nghĩa

API Application Programming Interface Giao diện lập trình ứng dụng

BoD Binding Of Duty Ràng buộc các nhiệm vụ được

thực hiện bởi một người
BPM Business Process Management Quản lý quy trình nghiệp vụ
BPMN Business Process Model and Notation Tiêu chuẩn và mơ hình quy trình

nghiệp vụ

DSM Domain-Specific Modeling Mơ hình hóa chun biệt miền
DSML Domain-Specific Modeling Language Ngơn ngữ mơ hình hóa chun

biệt miền

EMF Eclipse Model Framework Nền tảng mơ hình hóa Eclipse
PEP Policy Enforcement Point Điểm thực thi chính sách
SoA Service Oriented Architecture Kiến trúc hướng dịch vụ

SLA Service-level agreement Cam kết chất lượng dịch vụ

SoD Separation Of Duty Tách biệt nhiệm vụ

RBAC Role-Based Access Control Điều khiển truy cập dựa theo vai
trò

REST REpresentational State Transfer

WSBPEL Web Services Business Process
Execution Language

Ngôn ngữ thực thi quy trình
nghiệp vụ bằng Web services
XACML eXtensible Access Control Markup

Language

DANH SÁCH CÁC HÌNH VẼ

</div>
(8)<div class='page_container' data-page=8>

Hình 1.3: Core RBAC

Hình 1.4: MetaModel của RBAC
Hình 1.5: MetaModel 2 của RBAC
Hình 1.6: Quy trình nghiệp vụ
Hình 1.7: Vịng đời BPM

Hình 1.8: Metamodel của BPMN
Hình 1.9: Các thành phần của Activiti

Hình 1.10: Các thành phần của Activiti Engine

Hình 2.1: Yêu cầu an ninh kết hợp với ký hiệu

Hình 2.2: Metamodel của BPMN tích hợp với một số chính sách an ninh
Hình 2.3: Ecore Diagram của RBAC trong Eclipse

Hình 2.4: Mơ hình Ecore của RBAC thu được từ EcoreDiagram
Hình 2.5: Lớp JAVA được sinh ra từ mơ hình

Hình 2.6: Tab Security trong Patelle
Hình 2.7: Tab Security trong Properties

Hình 3.1: Cơ cấu tổ chức trung tâm Tư vấn Thiết kế
Hình 3.2: Màn hình đăng nhập Activiti Designer

Hình 3.3: Màn hình quản lý Task trên Activiti Designer
Hình 3.4: Màn hình quản lý Process trên Activiti Designer
Hình 3.5: Màn hình quản lý cấu hình trên Activiti Designer
Hình 3.6: Tạo dự án Activti BPM trên Eclipse

Hình 3.7: Tạo sơ đồ Activiti Diagram trên Eclipse
Hình 3.8: Visual Editor của Activiti

Hình 3.9: Quy trình điều xe trên Activiti Designer

Hình 3.10: Khai báo các data objects của quy trình điều xe

Hình 3.11: Cấu hình rẽ nhánh cho Gateway

Hình 3.12: Cấu hình kết quả phê duyệt của Manager Approval
Hình 3.13: Cấu hình Security cho Manager Approval

</div>
(9)<div class='page_container' data-page=9>

Hình 3.15: Cấu hình Form thơng tin của CarSupervisor Approval
Hình 3.16: Cấu hình MailTask

Hình 3.17: Tạo nhóm người dùng trên Activiti Explorer
Hình 3.18: Tạo người dùng trên Activiti Explorer
Hình 3.19: Triển khai quy trình trên Activit Explorer
Hình 3.20: Biểu mẫu thơng tin u cầu

Hình 3.21: Màn hình Task Manager Approval
Hình 3.22: Thơng báo vi phạm chính sách RBAC
Hình 3.23: Chọn người thực hiện Task

Hình 3.24: Thực hiện phê duyệt u cầu

Hình 3.25: Mail thơng báo kết quả phê duyệt

</div>
(10)<div class='page_container' data-page=10>

MỞ ĐẦU

Quy trình nghiệp vụ đóng một vai trị then chốt để doanh nghiệp có thể quản lý
và vận hành một cách nhịp nhàng, đạt hiệu quả cao. Có thể khẳng định, một doanh
nghiệp xây dựng được quy trình tốt sẽ phát triển bền vững và có tính cạnh tranh cao
hơn Để có thể triển khai thì trước tiên quy trình nghiệp vụ phải được mơ hình hóa. Mơ
hình hóa quy trình nghiệp vụ khơng những được sử dụng trong việc trao đổi các yêu
cầu giữa chuyên gia nghiệp vụ và chuyên gia hệ thống mà còn được sử dụng để cài đặt
hệ thống thực tế. Các quy trình nghiệp vụ hiện đại thường kết hợp các tác vụ của con
người với các tác vụ tự động (ví dụ, được cài đặt bởi webservice), nên ngơn ngữ mơ
hình hóa quy trình nghiệp vụ cần phải thu hẹp khoảng cách giữa giữa chuyên gia

nghiệp vụ và chuyên gia hệ thống [2].

Mơ hình hóa quy trình nghiệp vụ thường tập trung vào mơ hình hóa chính xác
chức năng của quy trình mà bỏ qua các yêu cầu về an ninh. Nguyên nhân chủ yếu là do
thực tế rằng các chuyên gia trong lĩnh vực quy trình nghiệp vụ không phải là chuyên
gia về an ninh. Các yêu cầu về an ninh thường xuyên được xem xét sau khi định nghĩa
hệ thống. Cách tiếp cận này dẫn đến các lỗ hổng an ninh và rõ ràng cần thiết phải tăng
cường nỗ lực an ninh trong các giai đoạn trước phát triển do việc sửa lỗi sẽ hiệu quả và
tiết kiệm chi phí hơn. Các nghiên cứu thực nghiệm cho thấy tại mức thiết kế quy trình
nghiệp vụ thì khách hàng và người dùng cuối có thể biểu diễn các yêu cầu an ninh của
họ và sau đó có thể thể hiện tại mức cao, các yêu cầu an ninh dễ dàng xác định bởi
người mơ hình hóa quy trình nghiệp vụ [2].

Các yêu cầu an ninh có thể được mơ hình hóa trong quy trình nghiệp vụ và cần
thiết phải xem xét các yêu cầu an ninh này trong bất kì ứng dụng nào tại mức độ trừu
tượng cao nhất. Một trong các yêu cầu an ninh là điều khiển truy nhập tức là kiểm soát
việc truy cập và thực hiện các hành động trên các nguồn tài nguyên hệ thống được
được bảo vệ. RBAC (Role-Based Access Control) điều khiển truy cập theo vai trò là
một phương pháp điều khiển truy cập hiệu quả nhất hiện nay [3,4]. Tuy nhiên, các nền
tảng cho phép mơ hình hóa quy trình nghiệp vụ hiện nay như Oracle BPM, Acitivi
BPM đều chưa tích hợp đầy đủ điều khiển truy cập theo vai trị RBAC [5]. Chính vì
vậy, tơi xin chọn đề tài “Mở rộng công cụ Activiti cho đặc tả và cài đặt chính sách

an ninh”.

</div>
(11)<div class='page_container' data-page=11>

Về phần bố cục, luận văn được chia thành 3 chương chính như sau:

Chương 1. Kiến thức nền tảng : Trình bày cơ sở lý thuyết và các cơng nghệ

chính được sử dụng trong luận văn. Bao gồm: Mơ hình hóa chun biệt miền, mơ hình

hóa đặc tả chính sách truy cập RBAC, mơ hình hóa quy trình nghiệp vụ và cuối cùng,
giới thiệu về công cụ mã nguồn mở Activiti BPM

Chương 2. Tích hợp mơ đun chính sách truy cập RBAC với Activiti : Trình

bày phương pháp tích hợp chính sách an ninh vào quy trình nghiệp vụ và ứng dụng của
phương pháp vào việc tích hợp chính sách truy cập RBAC vào Activiti BPM

Chương 3. Cài đặt và thực nghiệm : Trình bày bài tốn vận tải hiện đang được

</div>
(12)<div class='page_container' data-page=12>

CHƯƠNG 1. KIẾN THỨC NỀN TẢNG

1.1. Giới thiệu chương

Chương này sẽ trình bày cơ sở lý thuyết và các cơng nghệ chính được sử dụng
trong luận văn. Bao gồm ba nội dung chính là:

 Mơ hình hóa chun biệt miền: các khái niệm và kiến trúc của DSM; cú pháp và
ngữ nghĩa của một ngơn ngữ mơ hình hóa chun biệt miền DMSL.

 Mơ hình hóa và đặc tả chính sách truy cập RBAC: các khái niệm cơ bản về Core
RBAC và ràng buộc phân quyền. Từ đó, xây dựng mơ hình metamodel cho RBAC.

 Mơ hình hóa và thực thi quy trình nghiệp vụ với Activiti BPM: khái niệm, thành
phần, vòng đời và tiêu chuẩn ký hiệu BPMN của quy trình nghiệp vụ. Cuối cùng,
giới thiệu cơng cụ mã nguồn mở Activti BPM cho việc mơ hình hóa và thực thi quy
trình nghiệp vụ một cách tự động.

1.2. Mơ hình hóa chun biệt miền

Các hệ thống phần mềm hiện nay ngày càng trở nên phức tạp, muốn cải thiện

hiệu suất phát triển phần mềm không chỉ tốc độ mà còn chất lượng hệ thống được tạo
ra, các nhà nghiên cứu đã cố gắng tìm ra một phương pháp tự động chuyển từ mơ hình
sang code. Do đó, mơ hình hóa chun biệt miền (DSM) đã ra đời. DSM sử dụng một
ngơn ngữ mơ hình hóa chun biệt miền (DSML) để sinh code đầy đủ từ mơ hình và
code được sinh ra có ít lỗi hơn là code viết bằng tay [6].

1.2.1. Khái niệm

DSM chủ yếu tập trung vào hai vấn đề. Đầu tiên, nâng cao mức độ trừu tượng
trên cả lập trình bằng cách xác định một ngôn ngữ trực tiếp sử dụng các khái niệm và
các luật từ miền vấn đề cụ thể. Thứ hai, tạo ra sản phẩm cuối cùng trong một ngơn ngữ
lập trình đã chọn hoặc một hình thức khác từ các đặc tả mức cao đó. Thơng thường, bộ
sinh code tiếp tục được hỗ trợ bởi một số nền tảng (framework). Tự động hóa phát
triển phần mềm có thể trở nên phổ biến bởi vì ngơn ngữ mơ hình hóa, bộ sinh code và
code của framework đã phù hợp với các yêu cầu của miền ứng dụng. Nói cách khác
chúng là chuyên biệt miền và chúng hồn tồn được kiểm sốt bởi người dùng.

Các mức độ trừu tượng cao

</div>
(13)<div class='page_container' data-page=13>

các thời điểm khác nhau đã thu hẹp khoảng cách trừu tượng giữa ý tưởng trong miền
và cài đặt của chúng.

Hình 1.1: Thu hẹp khoảng cách trừu tượng giữa ý tưởng miền và cài đặt của chúng

Bước đầu tiên trong phát triển bất kỳ phần mềm nào luôn là nghĩ về giải pháp liên
quan đến miền vấn đề - một giải pháp ở mức độ trừu tượng cao nhất (bước 1). Ví dụ,
quyết định nên hỏi tên người trước hay hỏi phương thức thanh toán trước trong khi
đăng ký một hội thảo. Sau khi tìm ra giải pháp sẽ ánh xạ sang đặc tả của một số ngôn
ngữ (bước 2). Trong lập trình truyền thống, bước này các nhà phát triển ánh xạ các
khái niệm miền vào việc code các khái niệm. Trong UML hoặc các ngơn ngữ mơ hình

hóa mục đích chung khác, các nhà phát triển ánh xạ giải pháp miền vấn đề vào đặc tả
trong ngôn ngữ mô hình hóa. Bước 3, cài đặt đầy đủ giải pháp: đưa ra các điều kiện
đúng và nội dung code cho các vịng lặp. Tuy nhiên, nếu sử dụng các ngơn ngữ mơ
hình hóa mục đích chung, thì cần ánh xạ bổ sung từ mơ hình sang code. Điều đáng chú
nhất ở đây là các nhà phát triển vẫn phải thực hiện từ bước 1 mà khơng có bất kì cơng
cụ nào hỗ trợ, đặc biệt để giải quyết các lỗi phát sinh trong giai đoạn phát triển thường
tốn nhiều chi phí nhất.

Tự động sinh code

</div>
(14)<div class='page_container' data-page=14>

DSM khơng kỳ vọng rằng tất cả code có thể được sinh ra từ các mơ hình nhưng bất cứ
gì mơ hình hóa được từ quan điểm của người mơ hình hóa thì đều sinh ra code hồn
chỉnh. Trong DSM, code được sinh ra dễ đọc và hiệu quả - lý tưởng là giống như code
được viết bởi những nhà phát triển giàu kinh nghiệm, những người định nghĩa ra bộ
sinh code. Code được sinh ra thường được hỗ trợ bởi framework với mục đích nhất
định cũng như bởi các nền tảng, thư viện, thành phần và các code kế thừa khác. Bộ
sinh code khơng chỉ giới hạn bất kì ngơn ngữ hay kiểu lập trình nào. Ví dụ kết quả của
bộ sinh code có thể là ngơn ngữ lập trình hướng đối tượng hoặc ngơn ngữ lập trình cấu
trúc hay chức năng, nó có thể là ngơn ngữ lập trình truyền thống, một ngôn ngữ kịch
bản, các định nghĩa dữ liệu hoặc một file cấu hình.

Tóm lại, DSM về cơ bản nâng cao mức độ trừu tượng trong khi thu hẹp không
gian thiết kế (thường là các sản phẩm trong một cơng ty). Cùng với ngơn ngữ mơ hình
hóa chun biệt miền DSML, vấn đề sẽ được giải quyết khi việc mơ hình hóa trực
quan giải pháp mà chỉ sử dụng các khái niệm miền quen thuộc. Sản phẩm cuối cùng
được sinh tự động bởi các bộ sinh code chuyên biệt miền. Với DSM, không cần ánh xạ
từ khái niệm miền sang khái niệm thiết kế và cuối cùng sang khái niệm ngơn ngữ lập
trình. DSM tn theo cơng thức: cung cấp mức độ trừu tượng cao hơn và thực hiện ánh
xạ tự động từ các khái niệm mức cao hơn sang các khái niệm mức thấp hơn đã biết và
sử dụng trước đó.

Kiến trúc của DSM gồm 3 thành phần chính là ngơn ngữ, bộ sinh code và
framework miền như hình 1.2 :

Hình 1.2: Kiến trúc cơ bản của DSM

</div>
(15)<div class='page_container' data-page=15>

lập trình nhất định. Nhìn chung, các khái niệm miền chính ánh xạ lên các đối tượng
của ngơn ngữ mơ hình hóa, trong khi các khái niệm miền khác sẽ được coi như thuộc
tính đối tượng, các kết nối, các mơ hình con hoặc các đường dẫn đến mơ hình. Bởi
vậy, ngơn ngữ này cho phép nhà phát triển làm việc trực tiếp với các khái niệm miền.
Ngôn ngữ này được định nghĩa như một metamodel với các ký hiệu và công cụ hỗ trợ.

Bộ sinh code xác định làm sao thông tin được lấy ra từ mơ hình và chuyển đổi sang
code. Trong trường hợp đơn giản nhất, mỗi symbol (ký tự) mô hình hóa tạo ra code
nhất định, bao gồm các giá trị được nhập vào trong symbol là các tham số. Bộ sinh
code cũng có thể tạo ra các code khác nhau phụ thuộc vào các giá trị trong symbol, các
mối quan hệ nó có với các symbol khác, hoặc thơng tin khác trong mơ hình. Code này
sẽ được liên kết với framework và được biên dịch thành mã thực thi hồn chỉnh. Trong
giải pháp DSM, mục tiêu chính là sau khi sinh code không cần bổ sung code bằng tay
để thay đổi và mở rộng code đã sinh. Bởi vậy, code đã sinh chỉ đơn giản là một sản
phẩm trung gian trên con đường đưa ra sản phẩm cuối cùng.

Framework miền: cung cấp giao diện giữa code được sinh ra và các nền tảng phía
dưới. Trong một số trường hợp, khơng cần thêm code của framework: code sinh ra có
thể trực tiếp gọi các thành phần nền tảng nếu nó có đủ các dịch vụ. Mặc dù vậy, việc
định nghĩa code hoặc thành phần tiện ích bổ sung giúp code sinh ra dễ dàng hơn.

Code sinh ra không được thực hiện một mình mà cịn cùng với code thêm vào trong
một số mơi trường đích. Điều này được sử dụng bất kể việc cài đặt được thực hiện như
thế nào, bằng tay hay sử dụng các bộ sinh. Sản phẩm đã phát triển có thể sử dụng một

phần của một nền tảng lớn (như J2EE), toàn bộ nền tảng (như Tomcat server) hay một
số nền tảng khác.

1.2.2. Ngôn ngữ mơ hình hóa chun biệt miền

Ngơn ngữ chun biệt miền (DSL) là một ngơn ngữ lập trình hoặc một ngơn ngữ
đặc tả thực thi, thơng qua các ký hiệu thích hợp và trừu tượng, tập trung vào biểu diễn;
và thường được giới hạn trong một miền cụ thể. DSL làm tăng mức độ trừu tượng
bằng cách sử dụng các khái niệm quen thuộc với chun gia miền. Trong mơ hình hóa
chuyên biệt miền, DSL được gọi là DSML được sử dụng cho việc xây dựng mơ hình
đồ họa cho một hệ thống phần mềm.

</div>
(16)<div class='page_container' data-page=16>

Cú pháp

Cú pháp định nghĩa các thành phần hợp lệ trong một ngôn ngữ nhất định. Tuy
nhiên, tự nó khơng liên quan đến cấu trúc có ý nghĩa gì. Cú pháp chỉ xác định một cấu
trúc có hợp lệ nhưng nó có thể có ngữ nghĩa khơng hợp lệ.

Cú pháp trừu tượng: xác định cấu trúc khái niệm của một ngôn ngữ: cấu trúc của một

ngơn ngữ mơ hình hóa, các thuộc tính của nó và các kết nối của chúng với nhau. Cú
pháp của một ngơn ngữ chun biệt miền có ý nghĩa không chỉ là các từ dành riêng mà
thường được xem như các quy tắc (rule) ngữ pháp cần được tn theo trong khi xác
định mơ hình. Các quy tắc này bắt nguồn từ miền và chúng ràng buộc việc mơ hình
được tạo ra như thế nào: định nghĩa các giá trị, các mối quan hệ giữa các khái niệm và
các khái niệm nhất định được sử dụng như thế nào. Một khi các quy tắc được định
nghĩa, ngôn ngữ mơ hình hóa của cơng cụ hỗ trợ sẽ đảm bảo tất cả các nhà phát triển
tuân theo cùng các quy tắc đó trong miền. Việc có các quy tắc sẽ giảm đáng kể không
gian thiết kế, giúp cho cài đặt của bộ sinh trở nên dễ dàng hơn do các bộ sinh không
cần bắt đầu bằng việc kiểm tra lại tính chính xác của mơ hình. Trong DSM, các quy

tắc được kiểm tra sớm nhất có thể bởi vì việc phát hiện và ngăn nữa lỗi ở mơ hình sẽ
đơn giản và hiệu quả chi phí hơn việc tìm lỗi trong code đã sinh.

Ngơn ngữ metamodel được sử dụng để xác định cú pháp trừu tượng của ngơn ngữ mơ
hình hóa. Một metamodel là một mơ hình của ngơn ngữ mơ hình hóa chứa tất cả các
thuộc tính và tính năng cần thiết bao gồm các khái niệm ngơn ngữ mà nó hỗ trợ, cú
pháp và ngữ nghĩa.

Cú pháp cụ thể: Cú pháp và ngữ nghĩa thuần khơng đủ cho việc định nghĩa ngơn ngữ:

mơ hình phải được truy cập thông qua một vài dạng trực quan. Cú pháp cụ thể xác
định các thành phần từ cú pháp trừu tượng được biểu diễn trực quan như thế nào. Mỗi
ngơn ngữ mơ hình hóa tn theo một số dạng biểu diễn cũng với một ký hiệu. Dạng
biểu diễn của hầu hết các ngơn ngữ mơ hình hóa là đồ họa kết hợp với text. Các ngơn
ngữ mơ hình hóa cũng có thể dựa trên các dạng khác như ma trận, bảng biểu và các
biểu mẫu hoặc là văn bản thuần túy. Lựa chọn ký hiệu cho ngôn ngữ DSM nên gắn
liền với biểu diễn thực tế của các khái niệm miền, ví dụ nút điều khiển trong hệ thống
giải trí xe nên giống với nút điều khiển trong ngơn ngữ mơ hình hóa. Một cách lý
tưởng, mỗi khái niệm trong ngơn ngữ mơ hình hóa nên có ký hiệu biểu diễn chính xác
nó. Ngun tắc này tối thiểu hóa sự quá tải các ký tự và đảm bảo rằng tất cả các khái
niệm có thể được biểu diễn trong ngôn ngữ.

Ngữ nghĩa

</div>
(17)<div class='page_container' data-page=17>

nếu phát triển một hệ thống giải trí cho xe, các khái niệm mơ hình hóa như “menu”,
“event”,..đã có ý nghĩa rõ ràng trong miền ứng dụng.

Sử dụng ngữ nghĩa miền trong ngôn ngữ không chỉ giới hạn là các khái niệm miền mà
cịn bao gồm các kết nối giữa kiến trúc mơ hình hóa cũng như các quy tắc liên quan.
Ví dụ, ở hệ thống giải trí cho xe ở trên, một “menu” có thể kích hoạt một hành động

hoặc mở ra một submenu thì trong ngơn ngữ mơ hình chun biệt miền một menu có
thể kết nối đến một hành động hoặc một menu khác.

Ngữ nghĩa của miền vấn đề không phải là nguồn duy nhất cho ngữ nghĩa DSM. Giống
như sinh code đích cho tất cả ngơn ngữ mơ hình hóa, nhất thiết phải nhận ra ngữ nghĩa
của phía cài đăt; làm sao các kiến trúc mơ hình được ánh xạ lên miền vấn đề. Sự ánh
xạ này được thực hiện khơng chỉ trên miền vấn đề mà cịn trên các ngơn ngữ lập trình
khác. Sau đó, ngơn ngữ mơ hình hóa sẽ thực sự được ánh xạ 1-1 lên ngơn ngữ lập trình
được sinh ra. Sự trừu tượng là giống nhau và code sinh ra là tối thiểu. Một ví dụ điển
hình là việc ánh xạ một lớp trong sơ đồ sang một lớp trong code. Nhà phát triển người
mà tạo ra mơ hình đã nghĩ về các khái niệm và ngữ nghĩa của code. Nếu muốn tăng
mức độ trừu tượng và cải thiện hiệu suất, ngữ nghĩa của miền vấn đề có quan hệ nhiều
hơn ngữ nghĩa của miền giải pháp.

1.3. Mơ hình hóa đặc tả chính sách truy nhập RBAC

Việc sử dụng các cơ chế kiểm sốt truy nhập trong các tổ chức có quy mơ từ
trung bình đến lớn ln là một vấn đề rất quan trọng. Nghiên cứu [3,4] cho thấy điều
khiển truy nhập dựa trên vai trị RBAC là một mơ hình hiệu quả và linh hoạt cho việc
kiểm soát truy nhập vào các nguồn tài cần được bảo vệ và việc thực thi chính sách các
chính sách an ninh của tổ chức.

1.3.1. RBAC và các ràng buộc phân quyền

Điều khiển truy cập dựa theo vai trị RBAC là một mơ hình điều khiển truy cập,
trong đó việc quản trị an ninh có thể được đơn giản hóa bằng cách sử dụng các vai trò
để tổ chức các quyền truy nhập và cuối cùng giảm bớt sự phức tạp và chi phí quản trị
an ninh [3]. Mơ hình tham chiếu RBAC được định nghĩa dưới dạng 3 thành phần mơ
hình : Core RBAC (RBAC lõi), Hierachy RBAC (RBAC phân cấp) và Authorization
Constraints (các ràng buộc phân quyền).

</div>
(18)<div class='page_container' data-page=18>

Hình 1.3: Core RBAC

Core RBAC bao gồm các tập của 5 phần tử dữ liệu cơ bản được gọi là user (USERS),
roles (ROLES), objects (OBS), operations (OPS) và permissions (PRMS).

 Một user được định nghĩa là một con người.

 Một role là một chức năng công việc trong ngữ cảnh của tổ chức, liên quan đến
quyền hạn và trách nhiệm của người dùng được gán vai trị đó.

 Một object là một thực thể chứa hoặc nhận thông tin. Trong hệ thống cài đặt
RBAC, đối tượng có thể là container chứa thông tin (file, thư mục, …) hoặc có thể
đại diện cho các nguồn tài nguyên hệ thống (máy in, ổ cứng,…)

 Một permission là một sự chấp nhận để thực hiện một hành động trên một hoặc
nhiều đối tượng được RBAC bảo vệ.

 Một operation là một hành động trên một đối tượng được bảo vệ, ví dụ trong hệ
thống file, các hoạt động có thể là đọc file, ghi file và xóa file.

Tổng thể mơ hình RBAC được định nghĩa dưới dạng từng USERS được gán cho
ROLES và PRMS được gán cho ROLES. Như vậy, ROLES là phương tiện để đặt tên
cho các quan hệ nhiều – nhiều giữa USERS và PRMS. Ngồi ra, mơ hình Core RBAC
cịn bao gồm 1 tập các phiên làm việc (SESSIONS) mà mỗi phiên là một sự ánh xạ
giữa USER và một tập các ROLE con đã kích hoạt được gán cho USER.

Một mơ hình RBAC được sử dụng rộng rãi do Sandhu và các cộng sự [4] giới thiệu :

 Các tập hợp USERS, ROLES, PRMS, SESSIONS ( người dùng, vai trò, quyền và

phiên làm việc tương ứng)

 UA ⊆ USERS x ROLES (mối quan hệ gán người dùng với vai trò)
 PA ⊆ PRMS x ROLES (mối quan hệ gán quyền với vai trò)

 RH ⊆ ROLES x ROLES (mối quan hệ phân cấp vai trị)

</div>
(19)<div class='page_container' data-page=19>

mình trong một SESSION. Các PRMS có sẵn cho USER là sự kết hợp của PRMS từ
tất cả các ROLES được kích hoạt trong SESSION. Các phân cấp vai trị có thể được
hình thành bởi quan hệ RH, ví dụ vai trị của bác sĩ trưởng khoa kế thừa tất cả các
quyền từ vai trò của bác sĩ .

Authorizaiton Constraints là một khía cạnh quan trọng của RBAC và thỉnh
thoảng được xem như là động lực chính đằng sau RBAC[7]. Mục đích của
Authorizaiton Constraints khơng chỉ để giảm nguy cơ gian lận hoặc vi phạm an ninh
mà còn tăng cơ hội phát hiện lỗi trong cấu trúc an ninh của tổ chức. Authorizaiton
Constraints có thể cần được áp dụng với các chức năng và mối hệ RBAC để ngăn chặn
việc sử dụng thông tin sai lệch và các hành động gian lận. Một vài loại Authorizaiton
Constraints như ràng buộc SoD tĩnh và động, ràng buộc ngữ cảnh, ràng buộc
cardinality. Trong đó, SoD (tách biệt nhiệm vụ) là nguyên tắc cơ bản trong các hệ
thống an ninh, các hành động bắt buộc được chia cho hai hoặc nhiều người khác nhau
thực hiện để khơng có cá nhân nào có thể tự thỏa hiệp an ninh. Ví dụ, trong một tổ
chức u cầu khơng có người dùng nào được gán 3 trong 4 vai trò cho chức năng mua
hàng tức là vừa đăng ký yêu cầu mua hàng và vừa phê duyệt yêu cầu. Các ràng buộc
SoD được sử dụng để thực thi các chính sách mâu thuẫn với lợi ích. Một phương tiện
để ngăn chặn mâu thuẫn lợi ích thơng qua SoD tĩnh, nghĩa là thực thi các ràng buộc về
gán USERS cho ROLES. Mặt khác, các ràng buộc SoD động giới hạn PRMS có sẵn
cho một USER bằng cách đặt các ràng buộc trên các ROLES được kích hoạt trong
phiên làm việc của USER.

1.3.2. MetaModel cho RBAC

Metamodel là một mơ hình của ngơn ngữ mơ hình hóa. Một metamodel của
RBAC với các khái niệm tương ứng : Subject (mở rộng khái niệm User thành các đối
tượng cùng vai trị có thể là User hoặc nhóm User được gọi là Group), Role,
Permission, Action, Authorization, Resource và mối quan hệ giữa các khái niệm gọi là
references. Ví dụ, một User có nhiều vai trị, tương ứng với reference là asignRole.

</div>
(20)<div class='page_container' data-page=20>

Một Permission là một đối tượng kết nối một Role tới một tập Action được thực
hiện trên một Resource của hệ thống. Ngữ nghĩa của Permission được xác định bởi
thành phần Action. Mỗi Action đại diện cho mỗi kiểu hành động an ninh thích hợp
trên tài nguyên được bảo vệ, ví dụ như việc thực thi phê duyệt quy trình. Action cũng
có thể đại diện cho nhiều lớp khái niệm của các hoạt động ở mức trừu tượng cao. Mỗi
lớp có thể có nhiều phương thức và thuộc tính. Lớp này được gán cho Permission cho
phép Permission có quyền gọi tất cả các phương thức và đọc các giá trị của tất cả các
thuộc tính của lớp. Ví dụ, trong quy trình quản lý nghiệp vụ, Action là lớp cha đại diện
cho nhiều lớp Action như ActivityAction, ProcessAction, mỗi lớp Action con chứa các
phương thức và thuộc tính đại diện cho các hành động trên tài nguyên của quy trình.

AuthorizationContraint là một phần của chính sách kiểm soát truy cập thể hiện
điều kiện tiên quyết đối với mọi lời gọi thực hiện hành động của tài nguyên cụ thể
thơng qua việc gán nó cho các Permission. Ví dụ, SoD được gán cho một Permission
A và Permission B để ràng buộc người thực hiện hai permission này phải khác nhau;
ngược lại nếu BoD được gán cho hai permission này thì bắt buộc người thực hiện
permision A cũng phải thực hiện luôn permission B.

Các khái niệm RBAC được đại diện trực tiếp như các kiểu metamodel. Để xây
dựng mô hình, cần phải thêm vào trong miền các khái niệm đại diện cho mơ hình và
các thuộc tính, kiểu thuộc tính, cuối cùng là các khái niệm trừu tượng của miền [1].
Kết quả thu được là MetaModel 2 của RBAC như sau:

Hình 1.5: MetaModel 2 của RBAC

1.4. Mơ hình hóa và thực thi quy trình nghiệp vụ với Activiti

</div>
(21)<div class='page_container' data-page=21>

1.4.1. Mơ hình hóa quy trình nghiệp vụ

Quy trình nghiệp vụ được định nghĩa là một tập các sự kiện, hành động và quyết
định liên quan đến các tác nhân và nguồn tài nguyên, tất cả tạo ra một kết quả mang lại
giá trị cho tổ chức hoặc khách hàng của tổ chức [9]. Quy trình nghiệp vụ đóng vai trị
cốt lõi để căn cứ theo đó doanh nghiệp quản lý và vận hành một cách nhịp nhàng và
đạt hiệu quả cao.

Hình 1.6: Quy trình nghiệp vụ

Quản lý quy trình nghiệp vụ BPM chính là các ngun tắc, các phương pháp và
các công cụ để thiết kế, phân tích, thực thi và giám sát các quy trình nghiệp vụ. Mục
đích của quản lý quy trình nghiệp vụ BPM là giảm sai sót của con người và sự gián
đoạn của quy trình để tập trung các bên liên quan vào vai trò nhiệm vụ của họ. Với sự
giúp đỡ của BPM, các tổ chức doanh nghiệp có thể hoạt động hiệu quả hơn và có khả
năng thích nghi tốt với những thay đổi.

1.4.1.1. Vịng đời quy trình nghiệp vụ

</div>
(22)<div class='page_container' data-page=22>

Hình 1.7: Vịng đời BPM

Pha thiết kế chịu trách nhiệm xác định các hành động; phân tích các thay đổi có
thể xảy ra trong tổ chức; định nghĩa cam kết mức độ dịch vụ SLA; và xác định chi tiết
các thành phần của quy trình như các tác nhân, sự thơng báo, sự leo thang. Mục đích
chính của pha này là đảm bảo một thiết kế lý thuyết đúng và hiệu quả được chuẩn bị.

Pha này được thực hiện bởi chủ quy trình (process owners), người mà quyết định
luồng đi của quy trình trong doanh nghiệp.

Pha mơ hình hóa là pha thứ hai của vịng đời BPM, trong đó quy trình nghiệp vụ
được kiểm tra lại và xác định đầy đủ. Pha thiết kế chuẩn bị một thiết kế lý thuyết cịn
pha mơ hình hóa, quy trình nghiệp vụ lý thuyết được thiết kế sử dụng các thành phần
của tiêu chuẩn ký hiệu BPMN. Pha này chủ yếu thuộc trách nhiệm của nhà phân tích
và nhà tích hợp hệ thống.

Một khi thiết kế lý thuyết được chuyển đổi thành mơ hình, nó có thể được cài đặt
trong ứng dụng quy trình nghiệp vụ để tự động hóa việc thực thi của quy trình. Pha
thực thi là pha mà các dịch vụ được định nghĩa để tự động hóa quy trình nghiệp vụ.
Các ngơn ngữ được sử dụng để tạo các dịch vụ này là WSBPEL và BPMN 2.0. Pha
này thuộc trách nhiệm của các nhà phát triển người mà phát triển hệ thống.

Pha giám sát theo dõi hoạt động của các quy trình riêng lẻ. Giám sát hiệu năng
của mỗi và mọi quy trình để cung cấp các thông tin thống kê, đồng thời các trạng thái
của quy trình cũng có thể được duy trì. Trong pha giám sát, các vấn đề của quy trình
nghiệp vụ có thể được xác định và có các biện pháp khắc phục để cải thiện nó.

</div>
(23)<div class='page_container' data-page=23>

pha thiết kế đến khi vịng đời hồn tất. Cứ thế, vịng đời BPM là một q trình liên tục,
thích nghi tốt với những sự thay đổi trong môi trường kinh doanh.

1.4.1.2. Tiêu chuẩn ký hiệu BPMN

Có nhiều tiêu chuẩn BPM khác nhau được giới thiệu cho việc phát triển quy trình
nghiệp vụ nhưng BPMN 2.0 là tiêu chuẩn được sử dụng rộng rãi nhất do nó hỗ trợ cả
thiết kế và các tính năng của ngơn ngữ lập trình. Trước đây, các nhà phân tích nghiệp
vụ thiết kế quy trình nhưng rất khó cho các nhà phát triển có thể thêm các chi tiết kĩ
thuật vào nó. Tiêu chuẩn BPMN 2.0 khiến điều này trở nên dễ dàng hơn bao giờ hết

nhờ việc cho phép định nghĩa các component biểu diễn các thuộc tính và logic kỹ
thuật.

Một sơ đồ BPMN đơn giản bao gồm các thành phần đại diện cho luồng cơng
việc, đem lại hữu ích cho cả người sử dụng và người phát triển quy trình. Hình 1.8 mơ
tả metamodel của BPMN bao gồm bốn thành phần cơ bản là: Flow objects,

Connecting objects, Swim lanes và Artifacts [10].

Hình 1.8: Metamodel của BPMN

Flow objects

</div>
(24)<div class='page_container' data-page=24>

 Events có thể được coi như các hành động xảy ra trong quy trình nghiệp vụ. Trong
sơ đồ BPMN, chúng được biểu diễn bằng một hình trịn. Có ba loại events : là Start

Event, Intermediate Event và End Event

Loại Biểu diễn Ý nghĩa

Start Event Cho biết sự bắt đầu của quy trình nghiệp vụ. Nên có

ít nhất một Start Event trong quy trình.

Intermediat
e Event

Liên quan đến các sự kiện xảy ra giữa thời điểm bắt
đầu và kết thúc của quy trình nghiệp vụ. Những sự
kiện này khơng ảnh hưởng đến quy trình do chúng

khơng bắt đầu hoặc kết thúc.

End Event Cho biết sự kết thúc của quy trình nghiệp vụ. Nên có

ít nhất một End Event trong quy trình.

 Activities biểu diễn các nhiệm vụ hoặc cơng việc đang được thực hiện trong quy

trình nghiệp vụ. Trong sơ đồ BPMN, chúng được biểu diễn bằng hình chữ nhật trịn
góc. Các loại activities khác nhau là Task, Sub-Process và Call-Activity

Loại Biểu diễn Ý nghĩa

Task

Được sử dụng khi có một Activity được cài đặt
trong một quy trình. Các loại Tasks khác nhau
được cung cấp bởi BPMN là :

 Script task: sử dụng để tự động hóa 1 Task,

các logic được cài đặt ở đây.

 User task: sử dụng khi quy trình yêu cầu
tương tác với con người.

 Mail task: Là một loại dịch vụ để gửi e-mails

hoặc thơng báo từ quy trình

 Service task: Là một Task tùy chỉnh khi muốn

một số hoạt động cụ thể được thực hiện

Sub-Process

Biểu diễn các mức trong quy trình, giúp sơ đồ
hiển thị đơn giản và dễ hiểu hơn.

Call-Activity

</div>
(25)<div class='page_container' data-page=25>

 Gateways được sử dụng để xử lý rẽ nhánh hoặc nối các Paths trong quy trình. Mục

đích chính của gateways là điều khiển luồng đi của quy trình. Các loại gateway là

Exclusive GW, Inclusive GW, Parallel GW và Event-based GW.

Loại Biểu diễn Ý nghĩa

Exclusive
GW

Được sử dụng khi chúng ta muốn thực hiện duy nhất
một Path trong nhiều Paths. (câu lệnh If-else)

Inclusive
GW

Được sử dụng khi chúng ta muốn thực hiện các

Paths thỏa mãn điều kiện. (câu lệnh nhiều If)

Parallel
GW

Tất cả các Paths đi ra sẽ được thực hiện mà không
cần kiểm tra bất kì điều kiện nào.

Event-based
GW

Paths sẽ được thực hiện dựa trên các sự kiện thỏa

mãn điều kiện.

Connecting objects

Được dùng để biểu diễn kiến trúc quy trình nghiệp vụ. Mỗi Flow objects được
kết nối với nhau sử dụng các Connecting objecs. Có ba loại Connecting objects là

Sequence flow, Message flow, và Associations

Loại Biểu diễn Ý nghĩa

Sequence
flow

Biểu diễn thứ tự thực hiện của Activities trong quy

trình nghiệp vụ

Message

flow Thể hiện các bản tin đang trao đổi trong quy trình
Association

s

Biểu diễn mối quan hệ giữa Flow object và Artifacts
hoặc dữ liệu trong quy trình nghiệp vụ

Swim lanes

Được sử dụng cho mục đích hiển thị hóa. Nhờ có Swim lanes mà có thể dễ dàng
tổ chức các Activites của một nghiệp vụ. Swim lanes bao gồm 2 đối tượng là Pool và

Lanes

Loại Biểu diễn Ý nghĩa

Pool

</div>
(26)<div class='page_container' data-page=26>

Lanes

Một phân vùng của Pool, được sử dụng để tổ
chức quy trình nghiệp vụ theo các vai trò hoặc
chức năng đang thực hiện

Artifacts

Được sử dụng để cung cấp thông tin bổ sung trong sơ đồ BPMN, việc sử dụng
các ký hiệu trong quy trình nghiệp vụ có thể chú thích rõ ràng và mọi người cùng hiểu
được. Có ba loại Artifacts là Data object, Group và Anotation

Loại Biểu diễn Ý nghĩa

Data object Hữu ích cho việc xem thông tin liên quan đến dữ liệu

được yêu cầu trong Activity

Group Nhóm các Activities hoặc các Node cùng loại hay

cùng mục đích lại với nhau

Anotation Thêm một số nhận xét, chú thích vào quy trình

1.4.2. Cơng cụ Activiti

Activiti được phát triển bởi Tom Baeyens và Joram Barez [11] dưới dạng mã
nguồn mở, để thực thi các quy trình nghiệp vụ được biểu diễn bằng BPMN 2.0. Activti
là nền tảng tốt nhất để xây dựng BPM cho giao tiếp giữa con người với con người. Nó
có thể được sử dụng rất dễ dàng trong mọi mơi trường Java, hỗ trợ tất cả các khía cạnh
của BPM trong ngữ cảnh phát triển phần mềm. Người dùng có thể xây dựng bất kì
ngơn ngữ quy trình tùy chỉnh nào phù hợp với yêu cầu của mình vì nó cho phép họ sử
dụng các cơng cụ đã biết thay vì việc thay thế bằng một cơng cụ hồn tồn mới. Thậm
chí, nếu người dùng thiếu kiến thức về kỹ thuật thì họ cũng có thể dễ dàng cài đặt và
chạy quy trình với tiện ích cài đặt. Activi có một cơ chế xử quy trình BPMN 2.0 siêu
nhanh và ổn định, cung cấp nền tảng tốt nhất cho sự hợp tác giữa người dùng ít hiểu
biết về kỹ thuật và nhà phát triển kỹ thuật.

</div>
(27)<div class='page_container' data-page=27>

Hình 1.9: Các thành phần của Activiti

Activiti Engine

Activiti Engine là framework bền vững chịu trách nhiệm cho việc triển khai các
định nghĩa về quy trình, bắt đầu quy trình và thực thi các Task. Một số chức năng quan
trọng của Activiti Engine là :

 Thực hiện các Tasks khác nhau của process engine
 Thực thi nhanh chóng

 Dễ dàng tích hợp với các công nghệ khác
 Dễ dàng truy vấn thông tin lịch sử

 Hỗ trợ thực thi không đồng bộ

 Khả năng kiểm tra sự thực thi của quy trình
 Thực thi workflow sử dụng các services

</div>
(28)<div class='page_container' data-page=28>

Hình 1.10: Các thành phần của Activiti Engine

Có thể tương tác với Acitivi bằng cách sử dụng các services có sẵn. Process Engine
được khởi tạo bởi ProcessEngineConfiguration và nó cung cấp một số services sau:

 RespositoryService: chịu trách nhiệm cho việc lưu trữ và truy suất thơng tin về
quy trình nghiệp vụ từ repository

 RuntimeService: Được sử dụng để bắt đầu và truyền thơng tin về quy trình
đang thực hiện

 TaskService: xác định các hoạt động cần thiết để quản lý các tác vụ của con
người như yêu cầu, hoàn thành và gán tác vụ.

 IndentityService: Quản lý người dùng, nhóm và quan hệ giữa chúng.

 ManagementService: Quản lý thơng tin về Process Engine, admin và các hoạt
động duy trì.

 HistoryService: Cung cấp các service cho việc lấy thông tin về các instance của
quy trình đã và đang xảy ra.

 FormService: Cung cấp truy cập tới dữ liệu biểu mẫu (form data) và hiển thị
các biểu mẫu cho việc bắt đầu các instance quy trình mới và cho việc hồn
thành các Tasks

Activiti Modeler

Activiti Modeler là một cơng cụ mơ hình hóa mã dùng để quản lý Activiti Server
và việc triển khai các quy trình nghiệp vụ. Nó được xây dựng trên nền tảng web cho
phép quản lý các dự án Activiti, hỗ trợ thiết kế biểu mẫu, thay đổi và thiết kế workflow
của quy trình một cách dễ dàng.

Activiti Designer

Acitivi Designer được sử dụng để thêm các chi tiết kỹ thuật vào mơ hình quy
trình nghiệp vụ hoặc quy trình được tạo ra bởi Activiti Modeler. Activit Designer có
thể mơ hình đồ họa, kiểm thử và triển khai các quy trình BPMN 2.0 giống như Activiti
Modeler nhưng nó chủ yếu được sử dụng bởi các nhà phát triển để thêm chi tiết kỹ
thuật vào quy trình. Activiti Designer là một IDE chỉ được tích hợp với Eclipse Plugin.

Activiti Explorer

Activiti Explorer là một ứng dụng dựa trên nền tảng web, có thể truy cập dễ dàng
bởi người ít hiểu biết về kỹ thuật để chạy quy trình nghiệp vụ. Ngồi ra, nó cịn cung
cấp một giao diện quản lý các instance của quy trình và quản lý người dùng; cho phép
triển khai quy trình và sinh ra các báo cáo dựa trên dữ liệu lịch sử.

</div>
(29)<div class='page_container' data-page=29>

Activiti REST cung cấp REST API để truy cập vào Activit Engine, cho phép cấu
hình Activiti trên ứng dụng web.

1.5. Tổng kết chương

Chương này đã trình bày các kiến thức nền tảng được sử dụng trong luận văn.
Đầu tiên, các khái niệm và kiến trúc về mơ hình hóa chun biệt miền DSM đã được
giới thiệu. Mục đích của mơ hình hóa chun biệt là nâng cao mức độ trừu tượng trên
cả lập trình và tự động hóa việc sinh code để từ đó cải thiện được hiệu suất phát triển
phần mềm. Tiếp theo, mơ hình điều khiển truy nhập dựa trên vai trị cũng được trình
bày một cách chi tiết từ mơ tả các khái niệm RBAC và các ràng buộc phân quyền đến
xây dựng mơ hình metamodel cho RBAC. Cuối cùng, một phần rất quan trọng là mơ
hình hóa quy trình nghiệp vụ. Các cơng cụ quản lý quy trình nghiệp vụ giúp cho doanh
nghiệp vận hành các quy trình của họ một cách tự động. Activiti là một công cụ linh
hoạt, hiệu quả và hồn tồn miễn phí giúp để mơ hình hóa và thực thi các quy trình
nghiệp vụ.

</div>
(30)<div class='page_container' data-page=30>

CHƯƠNG 2. TÍCH HỢP MƠ ĐUN CHÍNH SÁCH TRUY CẬP RBAC

VỚI ACTIVITI

2.1. Giới thiệu chương

Ở chương này, các vấn đề an ninh trong quy trình nghiệp vụ sẽ được xem xét
trước tiên. Từ đó, một phương pháp tích hợp chính sách truy nhập RBAC vào quản lý
quy trình nghiệp vụ BPM sẽ được giới thiệu để giải quyết vấn đề trên. Cuối cùng, chi
tiết các bước thực hiện tùy chỉnh mã nguồn Actviti để ứng dụng phương pháp vào việc
tích hợp thêm mơ đun RBAC với Activiti.

2.2. Phương pháp tích hợp RBAC vào BPM

Các yêu cầu an ninh là mối quan tâm lớn trong việc thiết kế, xây dựng và thực thi
các hệ thống hướng quy trình nói chung và hệ thống BPM nói riêng, tuy nhiên chúng
thường coi là các yêu cầu phi chức năng. Chức năng của hệ thống và yêu cầu an ninh
thường không độc lập với nhau nên sự phân chia này khiến cho hệ thống khó đảm bảo
việc thỏa mãn tất cả các u cầu. Vì vậy, cần tích hợp các yêu cầu an ninh vào tất cả
các pha của vòng đời BPM nghĩa là từ pha thiết kế, mơ hình hóa đến pha thực thi đến
pha giám sát và pha tối ưu. Có rất nhiều các yêu cầu an ninh nhưng trong phạm vi luận
văn chỉ tập trung vào việc tích hợp các yêu cầu điều khiển dựa theo vai trị RBAC vào
pha thiết kế và mơ hình hóa quy trình bằng BPMN 2.0, ngồi ra, áp đặt các u cầu an
ninh vào pha thực thi.

Thiết kế và mơ hình hóa quy trình nghiệp vụ thường tập trung vào mơ hình hóa
chính xác chức năng của quy trình mà bỏ qua các yêu cầu về an ninh. Nguyên nhân
chủ yếu là do thực tế rằng các chuyên gia trong lĩnh vực quy trình nghiệp vụ khơng
phải là chun gia về an ninh. Các yêu cầu về an ninh thường xuyên được xem xét sau
khi định nghĩa hệ thống. Cách tiếp cận này dẫn đến các lỗ hổng an ninh và rõ ràng cần
thiết phải tăng cường nỗ lực an ninh trong các giai đoạn trước phát triển do việc sửa lỗi
sẽ hiệu quả và tiết kiệm chi phí hơn. Các nghiên cứu thực nghiệm cho thấy tại mức
thiết kế quy trình nghiệp vụ thì khách hàng và người dùng cuối có thể biểu diễn các
yêu cầu an ninh của họ và sau đó có thể thể hiện tại mức cao, các yêu cầu an ninh dễ
dàng xác định bởi người mơ hình hóa quy trình nghiệp vụ [2].

</div>
(31)<div class='page_container' data-page=31>

Artifacts có thể được sử dụng để biểu diễn các yêu cầu an ninh do Artifacts được thiết

kế để mở rộng ký hiệu mơ hình hóa cơ bản bằng việc thêm vào chúng khả năng biểu
diễn các tình huống cụ thể. Artifacts bao gồm DataObjects cho phép chứa dữ liệu được
yêu cầu hoặc được tạo ra bởi Activities; và Text Annotations cho phép cung cấp thông
tin bổ sung cho việc hiểu sơ đồ quy trình. Mặc dù Artifacts có thể được sử dụng để thể
hiện các yêu cầu an ninh nhưng chủ yếu là thông qua Text Annotations, điều này chỉ
giúp cho các chuyên gia quy trình và chuyên gia an ninh biểu diễn các u cầu đó cịn
rất khó cho các nhà phát triển hệ thống có thể cài đặt và triển khai được các yêu cầu an
ninh trong quy trình. Cách tốt nhất là định nghĩa một cách tường minh các yêu cầu an
ninh phải là một phần quy trình nghiệp vụ giống như Activity hay Event. Điều này
chính là mở rộng ngơn ngữ mơ hình hóa quy trình BPMN cho việc tích hợp thêm các
khái niệm về an ninh. Mơ hình các thành phần an ninh có thể có trong quy trình nghiệp
vụ theo hình 2.1.

Hình 2.1: Yêu cầu an ninh kết hợp với ký hiệu

Các yêu cầu an ninh được xem xét là chống thoái thác (No Repudiation), phát
hiện tấn công và tác hại của tấn công (Attack Harm Detection), tính tồn vẹn
(Integrity), tính bí mật (Privacy) và kiểm sốt truy cập (Access Control). Trong đó,
tính bí mật và kiểm sốt truy cập kết hợp với Security Role, Security Permission được
kết hợp với Security Role.

 Chống thoái thác: được xác định trên Message Flow, thể hiện giao dịch không
thể bị phủ nhận.

 Phát hiện tác hại của tấn công: tất cả các thành phần trong sơ đồ BPM phải xem
xét một cơ chế cho phép phát hiện, đăng kí và thơng báo về cuộc tấn cơng
mạng.

 Tính tồn vẹn: phải đảm bảo dữ liệu được bảo vệ, tránh sự gián đoạn và mất
mát nội dung.

</div>
(32)<div class='page_container' data-page=32>

 Kiểm soát truy nhập: tránh sự truy nhập trái phép vào các thành phần sơ đồ
BPMN như UserTask, MessageTask,…

Tất cả các yêu này hoàn tồn có thể thêm vào sơ đồ BPMN . Tuy nhiên, trong
phạm vi luận văn, tôi chỉ tập trung vào việc đặc tả và cài đặt các chính sách truy cập
RBAC vào BPM. Các yêu cầu về kiểm soát truy nhập bao gồm Acess Control (chính
là Core RBAC) và hai ràng buộc phân quyền Authorization Contraints là
SeparationOfDuty và BindingOfDuty sẽ được đưa xem xét và bổ sung vào metamodel
của BPMN để thu được metamodel mở rộng của BPMN tích hợp với các u cầu an
ninh RBAC hình 2.2.

Hình 2.2: Metamodel của BPMN tích hợp với một số chính sách an ninh

 Acess Control: Truy nhập hay thực hiện các hành động trên các nguồn tài nguyên
cần được giới hạn cho các vai trò nhất định. Trong sơ đồ BPMN, Acess Control
được yêu cầu trên Pool, Lane, Activity. Acess Control chứa các thành phần Core
RBAC: Role, Permission, Action

 Separation of Duty: Một người không được phép thực hiện nhiều vai trị trong quy
trình. SoD bao gồm nhiều Permission mà nó ràng buộc.

 Binding of Duty: Cùng một người phải thực hiện một số vai trò trong quy trình.
BoD cũng bao gồm nhiều Permission mà nó ràng buộc.

 Security Flow : thuộc thành phần Connecting Element, dùng để kết nối các đối
tượng cần ràng buộc chính sách truy cập RBAC với nhau.

</div>
(33)<div class='page_container' data-page=33>

an ninh. Trước khi thực hiện bất kì hành động nào trên nguồn tài nguyên được bảo vệ,
hệ thống phải gọi đến webservice này để kiểm tra xem hành động đó có hợp lệ hay
khơng. Webservice có thể sử dụng các thơng tin được cung cấp như Role, Permission,
Action và các thông tin hệ thống sẵn có để kiểm tra. Trường hợp, với hệ thống lớn, các
chính sách an ninh phức tạp phải sử dụng các công cụ hỗ trợ việc kiểm tra. Ví dụ, các
u cầu SoD và BoD của RBAC có thể tự động chuyển thành các chính sách XACML
và được ép buộc thực thi bởi một hoặc một vài điểm PEP [12]. Kết quả cuối cùng
được trả về cho hệ thống là hành động đó được thực hiện hay khơng được thực hiện và
hiển thị thông báo trả về cho người dùng.

Trong luận văn, việc thực thi các chính sách an ninh chỉ dừng lại ở việc kiểm tra
các trường hợp đơn giản như một người dùng được gán các vai trị khơng kế thừa và
việc kiểm tra được thực hiện tại chỗ không gọi đến các webservice được cung cấp bởi
bên thứ ba. Khi hệ thống lớn lên, các yêu cầu an ninh cũng trở nên phức tạp, cần có có
các cơng cụ hỗ trợ vừa đảm bảo việc kiểm tra tính đúng đắn, tính tồn vẹn của các yêu
cầu an ninh trong BPM vừa trả về kết quả nhanh nhất.

2.3. Tích hợp RBAC vào Activiti BPM

Ở phần này, đầu tiên một số khái niệm liên quan đến nền tảng phát triển Activiti
được giới thiệu. Sau đó, phương pháp tích hợp chính sách an ninh vào quy trình
nghiệp vụ được sử dụng để mở rộng công cụ Activiti BPM. Cụ thể, mở rộng Activiti
Designer cung cấp một môi trường tích hợp cho việc mơ hình hóa các u cầu an ninh
cho quy trình nghiệp vụ ngay ở bước thiết kế và mở rộng Activiti Explorer cho việc
thực thi các quy trình đó.

2.3.1. Một số khái niệm

2.3.1.1. Data models và Eclipse EMF

Mơ hình dữ liệu (data model) là một mơ hình miền được dùng để biểu diễn dữ
liệu mà ta muốn làm việc với. Ví dụ: nếu phát triển một ứng dụng đặt chỗ trực tuyến,
mơ hình miền có thể được mơ hình hóa với đối tượng như “Person, Fight,

Booking…”. Eclipse Modeling Framework (EMF) là một nền tảng giúp cho việc định

nghĩa tường mình mơ hình miền và khả năng hiển thị mơ hình một cách trực quan. Bộ
sinh code cho các mơ hình EMF có thể được điều chỉnh hoặc sử dụng cấu hình mặc
định. EMF sinh ra các lớp interfaces và một lớp factory phục vụ việc tạo ra các đối
tượng, bởi vậy giúp cho ứng dụng khơng cần phải có các lớp cài đặt cụ thể. Một ưu
điểm nữa là code Java có thể được sinh ra từ mơ hình tại bất kì thời điểm nào [13].

</div>
(34)<div class='page_container' data-page=34>

cấu trúc của mơ hình. Một mơ hình là một thể hiện cụ thể của metamodel này. EMF
cho phép nhà phát triển tạo metamodel thông qua các phương tiện khác nhau như
XMI, Java annotations, UML hoặc lược đồ XML.

Sinh dữ liệu từ EMF model: thông tin lưu trữ trong EMF model có thể được sử
dụng để sinh ra các đầu ra. Cụ thể ở đây là sử dụng EMF định nghĩa mơ hình miền của
ứng dụng và sinh các lớp Java tương ứng từ mơ hình. EMF hỗ trợ code sinh ra có thể
được chỉnh sửa nếu cần thiết. EMF model gồm 2 file mô tả là ecore và genmodel.

 Ecore file chứa thông tin về các lớp đã định nghĩa. Ecore file định nghĩa các thành

phần sau:

 EClass: biểu diễn một lớp, chứa không hoặc một vài thuộc tính cũng như

các tham chiếu.

 EAttribute: biểu diễn một thuộc tính với tên và loại thuộc tính.

 EReference: biểu diễn một association giữa hai lớp.

 EDataType: biểu diễn một loại dữ liệu của thuộc tính như kiểu int, string,..

 Genmodel file chứa thông tin bổ sung cho việc sinh code như thông tin về file và

đường dẫn. Genmodel file cũng chứa các tham số cấu hình việc code được sinh ra
như thế nào.

Eclipse EMF là một nền tảng mơ hình hóa và cơ sở sinh code cho việc xây dựng các
công cụ và các ứng dụng dựa trên mơ hình dữ liệu có cấu trúc.

2.3.1.2. Eclipse Plug-in

</div>
(35)<div class='page_container' data-page=35>

Plug-in Development Environment (PDE) cung cấp các công cụ để tạo, phát
triển, kiểm thử, debug, build và triển khai các Eclipse Plug-in. Các thành phần của
PDE bao gồm :

 PDE Build: các công cụ và kịch bản Ant để tự động hóa các q trình build

 PDE UI: Các models, builders, editors và các tiện ích khác hỗ trợ phát triển plug-in
trong Eclipse IDE

 PDE API Tools: cơng cụ tích hợp với Eclipse IDE và q trình build để duy trì API

 PDE Incubator: phát triển các cơng cụ mới nhưng chưa sẵn sàng tích hợp vào
Eclipse SDK

2.3.2. Mơ hình hóa các chính sách truy nhập RBAC

Các bước để tích hợp RBAC vào mơ-đun thiết kế của Activiti bao gồm:

 Bước 1: Sử dụng Eclipse EMF để mơ hình hóa mơ hình miền metamodel của
RBAC. Sau khi EMF metamodel của RBAC được xây dựng, Eclipse EMF cho
phép tự động sinh ra các lớp Java từ mô hình này. Bước này được thực hiện ở
mơ-đun “org.activiti.designer.model”.

 Bước 2: Sử dụng các lớp Java được sinh ra từ mơ hình để xây dựng các mơ tả
RBAC cho quy trình.

 Bước 3: Các lớp Java mơ tả RBAC của quy trình cần được export dưới định
dạng .xml cho phép triển khai trên Activiti Explorer

2.3.2.1. Xây dựng mơ hình dữ liệu RBAC sử dụng Eclipse EMF

 Tạo Ecore diagram : Mở mô-đun “org.activiti.designer.model”, chọn Folder
“model” trong cửa sổ Package Explore > New/Other…/ Ecore Tools/Ecore
Diagram > đặt tên cho Ecore diagram là SecureBPMN20

</div>
(36)<div class='page_container' data-page=36>

Hình 2.3: Ecore Diagram của RBAC trong Eclipse

 Mơ hình Ecore tương ứng thu được từ ecorediagram

Hình 2.4: Mơ hình Ecore của RBAC thu được từ EcoreDiagram

 Tạo EMF Generator Model: mã nguồn Activiti đã tạo ra file bpmn20.genmodel nên
chỉ cần Reload dữ liệu là đủ. Chuột phải bpmn20.genmodel > Reload…> chọn
Ecore model > chọn tất cả các package xuất hiện > finish

</div>
(37)<div class='page_container' data-page=37>

Hình 2.5: Lớp JAVA được sinh ra từ mơ hình

2.3.2.2. Xây dựng mơ tả RBAC trong quy trình

Mơ-đun “activiti-engine” của Activiti thực hiện nhiệm vụ xây dựng các mơ tả
RBAC trong quy trình nghiệp vụ. Bao gồm hai phần : một là các ký tự và ngữ nghĩa
của các chính sách RBAC trong tab Security của Patelle; hai là các thuộc tính RBAC
trong tab Security của Properties.

 Xây dựng ký tự và ngữ nghĩa cho RBAC trong tab Security của Patelle:

Hình 2.6: Tab Security trong Patette

</div>
(38)<div class='page_container' data-page=38>

vng, màu xanh nước biển, có icon và text thể hiện ý nghĩa của chúng : .
Để làm được điều này cần thực hiện các bước sau:

 Bước 1: Tạo 2 lớp AddSecuritySodFeature và AddSecuritySodFeature

chứa mơ về hình dạng, kích thước của SoD và BoD khi được kéo thả vào
Visual Editor.

 Bước 2: Tạo 2 lớp CreateSecurityBodFeature và

CreateSecuritySodFeature chứa mơ tả thuộc tính của SoD và BoD như tên,
Id, icon... Khi người dùng kéo thả icon của nó trên Patelle, các lớp tương ứng sẽ
tự động tạo ra các đối tượng BindingOfDuty và SeparationOfDuty chứa thông
tin mặc định :

 Bước 3: Tạo tab Security và các component của nó.

 Xây dựng các thuộc tính RBAC trong tab Security của Properties:

Hình 2.7: Tab Security trong Properties

Được thực hiện bằng cách khai báo thêm propertyTab và propertySection trong
file plugin.xml :

<extension

point="org.eclipse.ui.views.properties.tabbed.propertyTabs">

<propertyTabs
...

<propertyTab

afterTab="org.activiti.designer.mainConfigTab"
category="Activiti"

id="org.activiti.designer.securityTab"
label="Security">

</propertyTab>

</propertyTabs>

</extension>

<extension

point="org.eclipse.ui.views.properties.tabbed.propertySections">
...

<propertySection

</div>
(39)<div class='page_container' data-page=39>

filter="org.activiti.designer.security.property.PropertyRbacFilter"
id="org.activiti.designer.securityTab.usertask"

tab="org.activiti.designer.securityTab">

</propertySection>
<propertySection

class="org.activiti.designer.security.property.PropertySodBoDSection"

filter="org.activiti.designer.security.property.PropertySodBoDFilter"
id="org.activiti.designer.securityTab.sodbod"

tab="org.activiti.designer.securityTab">

</propertySection>

</extension>
...

</plugin>

Trong đó, lớp PropertyXXXSection được dùng để mơ tả các thuộc tính cịn
lớp PropertyXXXFilter được dùng lọc các component nào sẽ có các thuộc tính đó.
Cụ thể nếu component là UserTask thì PropertyRbacSection sẽ được dùng để
hiển thị tab Security cịn nếu component là SoD/BoD thì PropertySodBoDSection
sẽ thực hiện nhiệm vụ này.

2.3.2.3. Lưu mô tả RBAC dưới dạng xml

Mô-đun “org.activiti.designer.export.bpmn20” của Activiti thực hiện nhiệm vụ
lưu tồn bộ mơ tả về quy trình dưới dạng các lớp Java sang định dạng xml. Bao gồm
export các thuộc tính RBAC trong tab Security của Properties và export mơ tả hình
dạng, vị trí, kích thước các component Security trong Palette.

 Export các thuộc tính Security trong tab Security của Properties được mơ tả bởi các
lớp Java sinh ra từ mơ hình:

<process id="QuyTrinhDieuXe" name="QuyTrinhDieuXe">
...

<seperationOfDuty id="Sod1" name="sod" outgoingSecurityFlow="sf1 sf2 "

permissions="permission_id_1 permission_id_2 dynamicEnforcement="false">
</seperationOfDuty>

<securityFlow id="sf1" name="sf1" sourceRefNode="Sod1"

targetRefNode="usertask2">

</securityFlow>

<pemission id="permission_id_1" pName="Perm-usertask1-Full Access"

roles="role_id_1" actions="action_id_1"></pemission>

<role id="role_id_1" name="Manager" permissions="permission_id_1"></role>
<atomicActivityAction id="action_id_1" actionName="Full Access"

activityId="usertask2" permissions=" permission_id_1"

</div>
(40)<div class='page_container' data-page=40>

<pemission id=" permission_id_2" pName="Perm-usertask2-Full Access"

roles="role_id_2" actions="action_id_2"></pemission>
<role id="role_id_2" name="CarSupervisor"

permissions="permission_id_2"></role>
...

</process>

Mỗi đối tượng thuộc lớp đó chứa các thuộc tính và giá trị được cấu hình được biểu
diễn tương ứng dưới dạng xml là <tên đối tượng: thuộc tính= “giá trị”/>. Ví dụ, lớp
Permission chứa thuộc tính tên permission, danh sách các role và action gán cho nó:

public interface Permission extends BaseElement {
List<Role> getRoles();

List<Action> getActions();

List<AuthorizationConstraint> getAuthorizationConstraints();
String getPName();

void setPName(String value);

} // Permission

Permission sẽ được lưu dưới dạng xml :

<pemission id="permission_id_1" pName="Perm-usertask1-Full Access"

roles="role_id_1" actions="action_id_1"></pemission>

Không phải tất cả các thông tin trong Permission đều được export. Tùy thuộc vào cơ
chế khơi phục quy trình từ mơ tả xml mà chọn các thông tin cần thiết. Cơ chế lưu mô
tả quy trình dưới dạng xml là tạo một đối tượng XMLStreamWriter, đọc tất cả các
đối tượng trong sơ đồ Diagram đã tạo, nếu đối tượng là một thể hiện của lớp Role thì
gọi hàm createRole của lớp RoleExport còn nếu đối tượng là thể hiện của lớp
SeparationOfDuty thì gọi hàm createSoDTask của lớp SecuritySoDExport. Tương tự,
đối với tất cả các đối tượng còn lại.

Các lớp export sử dụng đối tượng XMLStreamWriter để ghi các thông tin của đối
tượng cần export thành định dạng xml. Ví dụ, lớp SecuritySoDExport dùng để ghi
các đối tượng SeparationOfDuty sang xml :

public class SecuritySoDExport implements ActivitiNamespaceConstants {

public static void createSoDTask(EObject object, XMLStreamWriter xtw){
SeparationOfDuty sodTask = (SeparationOfDuty) object;

xtw.writeStartElement("seperationOfDuty");
xtw.writeAttribute("id", sodTask.getId());
if (sodTask.getName() != null) {

xtw.writeAttribute("name", sodTask.getName());
}

if(sodTask.getOutgoingSecurityFlow().size()>0){
String outgoingSecurityFlow ="";

</div>
(41)<div class='page_container' data-page=41>

outgoingSecurityFlow = outgoingSecurityFlow+a.getId()+" ";
}

xtw.writeAttribute("outgoingSecurityFlow", outgoingSecurityFlow);
}

if(sodTask.getPermissions() !=null &&
sodTask.getPermissions().size()>0){

String permissions ="";

for(Permission p : sodTask.getPermissions()){
permissions = permissions+p.getId()+" ";
}

xtw.writeAttribute("permissions", permissions);
}
}
...
xtw.writeEndElement();

}
}

 Export mơ tả hình dạng, vị trí, kích thước các component Security trong Palette:

<bpmndi:BPMNDiagram id="BPMNDiagram_QuyTrinhDieuXe">

<bpmndi:BPMNPlane bpmnElement="QuyTrinhDieuXe"

id="BPMNPlane_QuyTrinhDieuXe">
...

<bpmndi:SecurityShape

securityElement="Sod1"id="SecurityShape_securitySod1">

<omgdc:Bounds height="60" width="60" x="372"

y="237"></omgdc:Bounds>

</bpmndi:SecurityShape>

<bpmndi:SecurityEdge securityElement="sf1" id="sf1">

<omgdi:waypoint x="402" y="237"></omgdi:waypoint>

<omgdi:waypoint x="544" y="225"></omgdi:waypoint>

</bpmndi:SecurityEdge>

<bpmndi:SecurityEdge securityElement="sf2" id="sf2">

<omgdi:waypoint x="402" y="237"></omgdi:waypoint>

<omgdi:waypoint x="242" y="225"></omgdi:waypoint>
</bpmndi:SecurityEdge>

...

</bpmndi:BPMNPlane>
</bpmndi:BPMNDiagram>

Hàm writeBpmnElement thực hiện đọc tất cả các đối tượng trong sơ đồ Diagram, nếu
một đối tượng là thể hiện của SecurityFlowNode thì nó sẽ được lưu các thơng tin vị trí,
kích thước trong tag xml “SecurityShape” :

private static void writeBpmnElement(FlowNode flowNode, ContainerShape
parent){

ILinkService linkService = Graphiti.getLinkService();
...

for (Shape shape : parent.getChildren()) {
EObject shapeBO =

</div>
(42)<div class='page_container' data-page=42>

if (shapeBO instanceof FlowNode) {

FlowNode shapeFlowNode = (FlowNode) shapeBO;

if (shapeFlowNode.getId().equals(flowNode.getId())) {

if(shapeFlowNode instanceof SecurityFlowNode){

xtw.writeStartElement(BPMNDI_PREFIX, "SecurityShape",

BPMNDI_NAMESPACE);

xtw.writeAttribute("securityElement", flowNode.getId());

xtw.writeAttribute("id", "SecurityShape_" + flowNode.getId());
}else{

xtw.writeStartElement(BPMNDI_PREFIX, "BPMNShape",

BPMNDI_NAMESPACE);

xtw.writeAttribute("bpmnElement", flowNode.getId());

xtw.writeAttribute("id", "BPMNShape_" + flowNode.getId());
}

xtw.writeStartElement(OMGDC_PREFIX, "Bounds", OMGDC_NAMESPACE);
xtw.writeAttribute("height",

shape.getGraphicsAlgorithm().getHeight());
xtw.writeAttribute("width",

shape.getGraphicsAlgorithm().getWidth());
xtw.writeEndElement();
...
 xtw.writeEndElement();

}
}
}

Sau khi bước này hồn thành thì tồn bộ các mơ tả về quy trình cũng như chính sách
truy cập RBAC đều được lưu dưới dạng xml, sẵn sàng cho việc triển khai quy trình
trên Activiti Explorer.

2.3.3. Thực thi các chính sách truy nhập RBAC

Các bước để tích hợp RBAC vào mô-đun quản lý của Activiti phục vụ cho việc
thực thi các chính sách truy cập RBAC bao gồm:

 Bước 1: “activiti-engine” phải cung cấp các chức năng khôi phục mơ tả RBAC của
quy trình từ fie xlml. Lớp BpmnParse thực hiện nhiệm vụ này:

</div>
(43)<div class='page_container' data-page=43>

Hàm checkSoD trong lớp ReassignAssigneeListener thực hiện nhiệm vụ
này:

public class ReassignAssigneeListener implements ClickListener {
...

private boolean checkSoD(String selectedUser) {

boolean result = false;
...

List<AuthorizationConstraint> acs = new

ArrayList<AuthorizationConstraint>();

for (Entry<String, AuthorizationConstraint> entry :
securityList.entrySet()){

Map<String, List<Permission>> permissions =
entry.getValue().getSod();

if (permissions.containsKey(task.getTaskDefinitionKey())) {
acs.add(entry.getValue());

}
}

List<String> roles = new ArrayList<String>();

for (AuthorizationConstraint ac : acs) {

if (ac.getType().equals(AuthorizationConstraint.SoD)) {
ac.getSod().remove(task.getTaskDefinitionKey());

for (Entry<String, List<Permission>> entry :
ac.getSod().entrySet()) {

for (Permission p : entry.getValue()) {

if

(p.getAction().equals(Permission.PERMISSION_FULL_ACCESS)){
roles.add(p.getRole());

}}}}

List<User> users = new ArrayList<User>();

for (String role : roles) {

List<User> usersTmp = ProcessEngines.getDefaultProcessEngine()
.getIdentityService().createUserQuery().memberOfGroup(role).l
ist();

users.addAll(usersTmp);
}

for (User u : users) {

if (selectedUser.equals(u.getId())) {
result = true;

}
}

return result;
}

...
}

2.4. Tổng kết chương

</div>
(44)<div class='page_container' data-page=44>

dùng, nhóm người dùng và phân quyền cho người dùng – có thể coi là một chức năng
của cơng cụ. Điều này khác hồn tồn với phương pháp tích hợp chính sách an ninh
vào BPM ở chỗ các yêu cầu an ninh sẽ được mơ hình hóa ngay tại pha thiết kế và được
thực thi tại pha triển khai quy trình.

</div>
(45)<div class='page_container' data-page=45>

CHƯƠNG 3. CÀI ĐẶT VÀ THỰC NGHIỆM

3.1. Giới thiệu chương

Mục tiêu chính của chương này là triển khai kết quả của luận văn vào việc quản
lý và vận hành các quy trình nghiệp vụ thực tế tại doanh nghiệp. Từ đó, chứng minh
tính hữu ích và khả năng hoàn toàn áp dụng được nghiên cứu vào thực tiễn. Nội dung
chính của chương bao gồm đưa ra một bài toán thực tế đang diễn ra tại doanh nghiệp,
các bước cài đặt quy trình trên Activiti để giải quyết bài toán và cuối cùng, kết quả
thực nghiệm được thể hiện dưới các số liệu thống kê hoạt động của quy trình.

3.2. Bài tốn vận tải

Trung tâm Tư vấn Thiết kế Mobifone – Chi nhánh Tổng Công ty Viễn thông
Mobifone là đơn vị trực thuộc Tổng Công ty Viễn thơng Mobifone, tiền thân là Xí
nghiệp thiết kế - Công ty Thông tin Di động. Chức năng của trung tâm là thực hiện
thiết kế kiến trúc cơng trình; tư vấn khảo sát, thiết kế mạng cơng trình thơng tin, bưu
chính viễn thơng; tư vấn đầu tư xây dựng chun ngành bưu chính viễn thơng; lắp đặt
thiết bị cơng trình, lắp đặt thiết bị cơng nghệ, giám sát thi cơng xây dựng các dự án,
phương án, cơng trình cho các đơn vị trực thuộc Tổng Công ty Viễn thông Mobifone.
Cơ cấu tổ chức của trung tâm gồm có 01 Giám đốc, 01 Phó Giám đốc, và 5 đơn vị
-mỗi đơn vị có 1 trưởng phịng và các nhân viên.

Hình 3.1: Cơ cấu tổ chức trung tâm Tư vấn Thiết kế

</div>
(46)<div class='page_container' data-page=46>

việc quản lý trở nên khó khăn, thủ tục rườm rà, gây lãng phí tiền bạc và cơng sức. u

cầu cần có một cơng cụ tự động quá quy trình nghiệp vụ tại trung tâm. Với ưu điểm là
đơn giản, triển khai nhanh chóng, Activiti BPM là lựa chọn phù hợp. Được sự cho
phép của lãnh đạo trung tâm, tôi đã triển khai thử nghiệm hai quy trình là quy trình
điều xe và quy trình đặt văn phịng phẩm. Trong phạm vi luận văn, tơi xin trình bày chi
tiết việc triển khai quy trình điều xe.

Mơ tả quy trình điều xe đang được thực hiện như sau:

 Khi nhân viên có yêu cầu đặt xe, nhân viên làm giấy yêu cầu xin xe có chữ ký của
người quản lý (trưởng phịng). Nếu trưởng phịng/giám đốc có u cầu đặt xe thì
khơng cần chữ ký này.

 u cầu được chuyển sang nhân viên phòng tổng hợp để trình và chờ trưởng phịng
tổng hợp điều xe.

 Trưởng phịng tổng hợp sẽ xem xét và chỉ định xe

 Nhân viên phịng tổng hợp gọi điện cho lái xe thơng báo về thời gian điều xe.

3.3. Cài đặt trên Activiti

Các bước cài đặt và triển khai một quy trình trên Activiti bao gồm:

 Bước 1: Cài đặt Activiti BPM trên server

 Bước 2: Mơ hình hóa quy trình trên Activiti Designer
 Bước 3: Triển khai quy trình trên Activiti Explorer

3.3.1. Cài đặt Activiti BPM

Sử dụng hai mô-đun Activiti BPM là Activiti Desginer để mơ hình hóa quy trình
và Activiti Explorer để thực thi quy trình. Trong đó, Activiti Designer là Plugin của
Eclipse đã được tích hợp chính sách an ninh, có nhiệm vụ tạo ra một tệp .bpmn chứa
tất cả mơ tả về quy trình. Sau đó, tệp .bpmn sẽ được triển khai trên Activiti Explorer –
một nền tảng web cho phép tự động thực thi quy trình. Các bước cài đặt Activiti
Explorer là:

 Bước 1: Chuẩn bị Tomcat server và tạo một Mysql database tên “activiti”

 Bước 2: Export module activiti-webapp-explorer2.war từ Eclipse

 Bước 3: Triển khai Activiti Explorer trên Tomcat server bằng cách copy file

activiti-webapp-explorer2.war vào thư mục webapp của Tomcat.

 Bước 4: Chạy Mysql database và Tomcat server. Truy cập vào địa chỉ

</div>
(47)<div class='page_container' data-page=47>

Hình 3.2: Màn hình đăng nhập Activiti Designer

Sau khi đăng nhập thành công, giao diện của Activiti Explorer như sau:

 Tasks: Tab này quản lý tất cả các chức năng liên quan đến task bao gồm: Inbox
chứa tất cả các task được gán cho người dùng, các tasks được gán cho nhóm user
được chứa trong Queued.

Hình 3.3: Màn hình quản lý Task trên Activiti Designer

 Processes: Tab này quản lý các quy trình. Cho phép xem quy trình đang được thực
thi và cung cấp các chức năng cho việc triển khai quy trình. Vì vậy, quy trình được
phát triển sử dụng cơng cụ Eclipse có thể được triển khai trong Activiti Explorer

</div>
(48)<div class='page_container' data-page=48>

 Manage: Tab này cung cấp các chức năng cho người quản trị hệ thống có thể quản
lý databases, quản lý việc triển khai quy trình và cơng việc, quản lý người dùng và
nhóm.

Hình 3.5: Màn hình quản lý cấu hình trên Activiti Designer

3.3.2. Mơ hình hóa quy trình trên Activiti Designer

Quy trình điều xe trên sẽ được mơ hình hóa trên Activiti Designer như sau:

 Chạy Activiti Desginer trên Eclipse bằng cách chuột phải vào module
“org.activiti.designer.eclipse” > Run As > Eclipse Appliction. Một giao diện
Eclipse mới được mở ra.

 Tạo dự án tên “TVTK_Project” mới : File > New > Others > Activiti Project

Hình 3.6: Tạo dự án Activti BPM trên Eclipse

</div>
(49)<div class='page_container' data-page=49>

Hình 3.7: Tạo sơ đồ Activiti Diagram trên Eclipse

 Giao diện mơ hình hóa quy trình nghiệp vụ bao gồm Editor, Palette và Properties.
Trong đó, Palette và Properties đã mở rộng thêm tab “Security” cho việc định
nghĩa các chính sách an ninh SoD và BoD.

Hình 3.8: Visual Editor của Activiti

</div>
(50)<div class='page_container' data-page=50>

Hình 3.9: Quy trình điều xe trên Activiti Designer

 Một Form được sử dụng để mơ tả phiếu u cầu. Để thêm/sửa/xóa các thuộc tính

cho Form, nhấn chuột vào nút New/Edit/Delete. Activiti chỉ hỗ trợ một số loại dữ
liệu như boolean, long, string, enum và date. Các thuộc tính này có thể Readable,
Writeable và Required. Form được cài đặt tại Start Event cho phép bất kỳ người
dùng vào bắt đầu quy trình sẽ nhìn thấy Form và được u cầu điền thơng tin.

Hình 3.10: Khai báo các data objects của quy trình điều xe

</div>
(51)<div class='page_container' data-page=51>

đầu ra từ gateway, một nếu chức vụ là “Nhân viên” thì yêu cầu phải được chuyển
đến trưởng phòng; hai nếu chức vụ đã là “Trưởng phòng” thì yêu cầu được chuyển
trực tiếp đến quản lý điều xe.

Hình 3.11: Cấu hình rẽ nhánh cho Gateway

Trường hợp chức vụ là nhân viên, yêu cầu sẽ được chuyển đến task Manager
Aproval. Task này được gán cho người dùng hoặc nhóm người dùng có quyền thực
hiện. Task chỉ thực hiện đồng ý hoặc từ chối yêu cầu nên cần thuộc tính bắt buộc
result kiểu enum có hai giá trị true và false. Để xem lại thông tin của Form yêu cầu,
sử dụng id của thuộc tính tại trường Value/Expression. Chú ý, các thuộc tính Form
yêu cầu chỉ được xem không được sửa nên phải xét trường Writable bằng False.

</div>
(52)<div class='page_container' data-page=52>

 Để thiết lập Permission cho UserTask vào tab Security, chọn Action và Role và ấn
nút Add. Một Permission được định nghĩa bởi một Action và một Role, một
UserTask có thể chứa nhiều Permission.

Hình 3.13: Cấu hình Security cho Manager Approval

</div>
(53)<div class='page_container' data-page=53>

Hình 3.14: Cấu hình Separation Of Duty

 Nếu Manager đã đồng ý yêu cầu thì luồng sẽ chuyển đến Car Supervisor Approval
- một UserTask, được cấu hình tương tự với Manager Approval.

Hình 3.15: Cấu hình Form thơng tin của CarSupervisor Approval

 Cuối cùng, dựa vào quyết định của Manager và Car Supervisor mà quy trình sẽ tự
động gửi thông báo bằng mail cho những người liên quan sử dụng Mail Task. Nếu
u cầu được chấp nhận thì thơng báo sẽ được gửi cho cả lái xe và người u cầu
về lịch trình. Cịn nếu u cầu bị từ chối thì người u cầu sẽ nhận được thơng báo
về lý do bị yêu cầu bị từ chối.

</div>
(54)<div class='page_container' data-page=54>

3.3.3. Triển khai quy trình trên Activiti Explorer

Quy trình điều xe trên sẽ được triển khai trên Activiti Designer như sau:

 Đăng nhập hệ thống dưới vai trò Admin

 Tạo các nhóm người dùng tương ứng với các vai trị trong quy trình: Staff,
Manager và Car Supervisor. Vào Manage > Groups > Create Group

Hình 3.17: Tạo nhóm người dùng trên Activiti Explorer

 Tạo người dùng và gán cho các nhóm người dùng: Vào Manage > Users > Create
User

Hình 3.18: Tạo người dùng trên Activiti Explorer

</div>
(55)<div class='page_container' data-page=55>

Hình 3.19: Triển khai quy trình trên Activit Explorer

3.4. Kết quả thực nghiệm

Sau khi triển khai, quy trình sẽ được thực thi như sau:



Bất kì người dùng nào trong tổ chức đăng nhập vào hệ thống đều có quyền đều có

khởi tạo riêng một instance của quy trình cho yêu cầu của mình. Vào Process >
Process definitions > chọn quy trình > Start process, một Form xuất hiện, người
dùng cần điền đầy đủ thông tin.

</div>
(56)<div class='page_container' data-page=56>

 Phê duyệt yêu cầu: Từ thông tin mà người yêu cầu xe cung cấp, hệ thống sẽ kiểm
tra trường Role, nếu Role là Staff thì yêu cầu sẽ được chuyển cho người có vai trị
Manager để phê duyệt. Người này đăng nhập hệ thống, vào Tasks > Queued. Do
task này được gán cho Group nên chưa có một Assignee cụ thể nào được gán, vì
vậy mọi thơng tin trong task đều ẩn.

Hình 3.21: Màn hình Task Manager Approval

 Gán người thực hiện quy trình: Khi nhấn Reassign, hệ thống sẽ bắt đầu kiểm tra
chính sách an ninh của người được gán cho Task. Ở đây, Separation Of Duty được
dùng để ràng buộc cho Manager và CarSupervisior nên bất kì người dùng nào
thuộc cả hai nhóm này đều khơng có quyền thực hiện Task. Nếu user đăng nhập vi
phạm, thơng báo hiện ra :

Hình 3.22: Thơng báo vi phạm chính sách RBAC

</div>
(57)<div class='page_container' data-page=57>

đăng nhập lại chọn một user vi phạm Separation Of Duty thì thơng báo lỗi lại hiện
ra, cịn khơng thì Task sẽ được gán cho user vừa được chọn. Khi user đó đăng nhập
thì mọi thơng tin trong task đều hiện lên và user có quyền thực hiện Task.

Hình 3.23: Chọn người thực hiện Task

</div>
(58)<div class='page_container' data-page=58>

 Gửi thông báo cho các bên liên quan: thực hiện bởi MailTask, cấu hình gửi mail

được thiết lập trong Activiti Designer, kết quả nhận được là :

Hình 3.25: Mail thơng báo kết quả phê duyệt

Như vậy, quy trình đã được thực thi cơng, các chính sách an ninh đã được kiểm tra
trước khi gán cho người dùng.

Sau gần 5 tháng thử nghiệm quy trình, kết quả thu được có 22 lần quy trình được
thực hiện. Phân bố theo các tháng như sau:

Hình 3.26: Thống kê số lần quy trình được thực hiện theo tháng

Số liệu trên được lấy trực tiếp từ việc truy vấn cơ sở dữ liệu của Acitivti:

SELECT MONTH(START_TIME_) Month_ ,COUNT(PROC_INST_ID_) TotalCount
FROM ACT_HI_PROCINST

</div>
(59)<div class='page_container' data-page=59>

Tỷ lệ thực hiện thành cơng của quy trình là 100% chứng tỏ độ ổn định khi triển khai
quy trình trên Activiti. Nói cách khác, Activiti là một công cụ đơn giản và hiệu quả
cho việc thực thi các quy trình nghiệp vụ của doanh nghiệp.

3.5. Tổng kết chương

</div>
(60)<div class='page_container' data-page=60>

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN

BPM là một công cụ giúp cho việc quản lý và vận hành doanh nghiệp được hiệu
quả hơn. Vấn đề an ninh là một trong các vấn đề quan trọng cần phải được xem xét
trong tất cả các pha của vịng đời BPM và việc cài đặt chính sách an ninh vào BPM là
thực sự cần thiết. Luận văn đã trình bày phương pháp tích hợp các chính sách truy
nhập (cụ thể là điều khiển truy nhập theo vai trị RBAC) vào pha mơ hình hóa của

vịng đời BPM bằng mở rộng ngôn ngữ BPMN 2.0 cho các yêu cầu an ninh. Ứng dụng
phương pháp để mở rộng công cụ Activiti BPM cho việc cài đặt các chính sách an
ninh. Tại pha mơ hình hóa của Activti, xây dựng metamodel cho BPMN tích hợp
RBAC và sinh ra cú pháp trừu tượng; sau đó, tại pha thực thi quy trình, kiểm tra một
số chính sách an ninh trước khi phân quyền cho người sử dụng. Kết quả của luận văn
đã được ứng dụng vào việc xây dựng một số quy trình nghiệp vụ tại Trung tâm Tư vấn
Thiết kế Mobifone.

Tuy nhiên, trong luận văn mới chỉ dừng lại ở bước tích hợp các chính sách an
ninh vào pha mơ hình hóa của BPM và tại pha thực thi, việc kiểm tra tính thỏa mãn
của các chính sách an ninh khi phân quyền cho người dùng đang dừng lại ở các trường
hợp đơn giản. Hệ thống lớn lên, các chính sách an ninh ngày càng phức tạp thì việc
kiểm tra, phát hiện việc vi phạm các ràng buộc lại trở nên nan giải hơn. Ví dụ, trong
trường hợp, người dùng được gán nhiều quyền, các quyền lại được kế thừa lẫn nhau,...
Để giảm sự phức tạp của việc quản lý an ninh, cần phải sử dụng các công cụ hỗ trợ
việc kiểm tra tính đúng đắn, tính tồn vẹn của các yêu cầu an ninh trong BPM. USE
tool là một cơng cụ cho phép mơ hình hóa phần mềm và kiểm tra tính chính xác của
các mơ tả UML, USE rất đơn giản và hiệu quả cho việc kiểm tra các chính sách an
ninh. Vì vậy, hướng phát triển tiếp theo của luận văn là sử dụng USE tool cho việc
thực thi chính sách an ninh của BPM. Hy vọng trong thời gian tới, tơi có thể phát triển
và hồn thiện nội dung này.

</div>
(61)<div class='page_container' data-page=61>

TÀI LIỆU THAM KHẢO

Tiếng Việt

1. Chu Thị Minh Huệ. (2011), “Ngơn ngữ mơ hình chun biệt miền cho mơ hình

bảo mật RBAC”, Đại học Quốc Gia Hà Nội, Luận văn thạc sĩ trên Thư viện số

Đại học Quốc Gia Hà Nội.

Tiếng Anh

2. Alfonso RODRIGUEZ, Eduardo FERNANDEZ-MEDINA, Marlo PIATTINI.
(2007) “A BPMN Extension for the Modeling of Security Requirement in

Business Processes”.

3. American National Standards Institute Inc.(2004) “Role Based Access

Control”, ANSI-INCITS 359-2004.

4. R. Sandhu, E. Coyne, H. Feinstein, C. Youman. (1996) “Role-based access

control models”, IEEE Computer, vol. 29, no. 2, pp. 38–47.

5. Achim D.Brucker, Isabelle Hang, Gero Luckemeyer, Raj Ruparel. (2012)
“SecureBPMN: Modeling and Enforcing Access Control Requirements in

Business Processes”.

6. Steven Kelly, Juha-Pekka Tolvanen. (2008), “Domain-Specific Modeling”,
pp. 1-92.

7. Tanveer Mustafa, Karsten Sohr, Duc-Hanh Dang, Michael Drouineaud. (2008),

“Implementing Advanced RBAC Administration Functionality with USE”.

8. Achim D. Brucker and Jăurgen Doser. (2012),“Metamodel-based UML

Notations for Domain-specific Languages”.

9. Marlon Dumas. (2014), “Business Process Management Course - Lecture 1:

Introduction to BPM”.

10.Object Management Group. (2011), “Business process model and notation

(BPMN)”, version 2.0.

11. Zakir Laliwala. (2014),” Activiti 5.x Business Process Management”.

12. OASIS. (2005), “eXtensible Access Control Markup Language (XACML)”.

13. Vogella. (2016), “ />

Last visit was on 12/4/2018.

</div>


<a href='http://localhost:8080/activiti-webapp-explorer2-5.8'>http://localhost:8080/activiti-webapp-explorer2-5.8 </a>

Mở rộng công cụ Activiti cho đặc tả và cài đặt chính sách an ninh

ĐẠI HỌC QUỐC GIA HÀ NỘI

<b>TRƯỜNG ĐẠI HỌC CÔNG NGHỆ</b>

<b>ĐỖ ANH VIỆT</b>

<b>MỞ RỘNG CÔNG CỤ ACTIVITI CHO</b>

<b>ĐẶC TẢ VÀ CÀI ĐẶT CHÍNH SÁCH AN NINH</b>

Ngành: Cơng nghệ Thông tin

Chuyên ngành: Kỹ thuật phần mềm

Mã số: 60480103

<b>LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN</b>

<b>NGƯỜI HƯỚNG DẪN KHOA HỌC: TS. ĐẶNG ĐỨC HẠNH</b>

<b>LỜI CAM ĐOAN</b>

LỜI CAM ĐOAN...i

LỜI CẢM ƠN...ii

MỤC LỤC...iii

DANH SÁCH CÁC KÝ HIỆU VÀ CHỮ VIẾT TẮT...v

DANH SÁCH CÁC HÌNH VẼ...vi

MỞ ĐẦU...1

CHƯƠNG 1. KIẾN THỨC NỀN TẢNG...3

CHƯƠNG 2. TÍCH HỢP MƠ ĐUN CHÍNH SÁCH TRUY CẬP RBAC VỚI

ACTIVITI...21

CHƯƠNG 3. CÀI ĐẶT VÀ THỰC NGHIỆM...38

KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN...53

TÀI LIỆU THAM KHẢO...54

<b>DANH SÁCH CÁC HÌNH VẼ</b>

<b>MỞ ĐẦU</b>

<b>CHƯƠNG 1. KIẾN THỨC NỀN TẢNG</b>

<b>1.1. Giới thiệu chương</b>

<b>1.2. Mơ hình hóa chun biệt miền </b>

<i><b>1.2.1. Khái niệm</b></i>

<i><b>1.2.2. Ngôn ngữ mơ hình hóa chun biệt miền</b></i>

<b>1.3. Mơ hình hóa đặc tả chính sách truy nhập RBAC</b>

<i><b>1.3.1. RBAC và các ràng buộc phân quyền</b></i>

<i><b>1.3.2. MetaModel cho RBAC </b></i>

<b>1.4. Mơ hình hóa và thực thi quy trình nghiệp vụ với Activiti</b>

<i><b>1.4.1. Mơ hình hóa quy trình nghiệp vụ</b></i>

<i><b>1.4.2. Cơng cụ Activiti</b></i>

<b>1.5. Tổng kết chương</b>

<b>CHƯƠNG 2. TÍCH HỢP MƠ ĐUN CHÍNH SÁCH TRUY CẬP RBAC</b>

<b>VỚI ACTIVITI</b>

<b>2.1. Giới thiệu chương</b>

<b>2.2. Phương pháp tích hợp RBAC vào BPM</b>

<b>2.3. Tích hợp RBAC vào Activiti BPM</b>

<i><b>2.3.1. Một số khái niệm</b></i>

<i><b>2.3.2. Mơ hình hóa các chính sách truy nhập RBAC</b></i>

<i><b>2.3.3. Thực thi các chính sách truy nhập RBAC</b></i>

<b>2.4. Tổng kết chương</b>

<b>CHƯƠNG 3. CÀI ĐẶT VÀ THỰC NGHIỆM </b>

<b>3.1. Giới thiệu chương</b>

<b>3.2. Bài tốn vận tải</b>

<b>3.3. Cài đặt trên Activiti</b>

<i><b>3.3.1. Cài đặt Activiti BPM</b></i>

<i><b>3.3.2. Mơ hình hóa quy trình trên Activiti Designer</b></i>

<i><b>3.3.3. Triển khai quy trình trên Activiti Explorer</b></i>

<b>3.4. Kết quả thực nghiệm</b>



<b>3.5. Tổng kết chương</b>

<b>KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN</b>

<b>TÀI LIỆU THAM KHẢO</b>

<b>Tiếng Việt</b>

<b>Tiếng Anh</b>

Tài liệu liên quan

Tài liệu bạn tìm kiếm đã sẵn sàng tải về