lib.uet.vnu.edu.vnlib.uet.vnu.edu.vn/.../123456789/999/1/Luan-van_v2.0.docx · Web viewlà công trình nghiên cứu của riêng tôi và được sự hướng dẫn của TS

ĐẠI HỌC QUỐC GIA HÀ NỘITRƯỜ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 tinChuyên ngành: Kỹ thuật phần mềmMã 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

Hà Nội – 2018

L

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

LỜI CẢM ƠNi

Để 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 quý 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 hoà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 quá 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

MỤC LỤC

ii

TrangLỜ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 chuyên biệt miền..............................................................................3

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

1.2.2. Ngôn ngữ mô hình hóa chuyên 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

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

iii

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

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

Từ viết tắt Thuật ngữ Ý nghĩaAPI Application Programming Interface Giao diện lập trình ứng dụng

iv

BoD Binding Of DutyRà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 NotationTiêu chuẩn và mô hình quy trình nghiệp vụ

DSM Domain-Specific Modeling Mô hình hóa chuyên biệt miền

DSML Domain-Specific Modeling LanguageNgôn ngữ mô hình hóa chuyên biệt miền

EMF Eclipse Model Framework Nền tảng mô hình hóa EclipsePEP Policy Enforcement Point Điểm thực thi chính sáchSoA 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

XACMLeXtensible Access Control Markup Language

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

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

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

v

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

Hình 3.14: Cấu hình SeparationOfDuty

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

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 yê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 yêu cầu

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

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

vii

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”.

Trong luận văn, tôi đã trình bày một phương pháp tích hợp chính sách an ninh RBAC vào quy trình nghiệp vụ BPM bằng cách mở rộng tiêu chuẩn BPMN cho đặc tả các chính sách an ninh [2], đồng thời ứng dụng của phương pháp này vào việc mở rộng công cụ Activiti BPM cho đặc tả và cài đặt RBAC dựa vào [5]. Kết quả cụ thể đạt được: thứ nhất, tích hợp các chính sách RBAC vào pha mô hình hóa để các yêu cầu an ninh có thể được xem xét ngay từ đầu. Thứ hai, đã kiểm tra các chính sách đó tại pha thực thi để đảm bảo an toàn an ninh cho hệ thống.

1

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 chuyên 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 toán vận tải hiện đang được triển khai tại Trung tâm Tư vấn Thiết kế Mobifone, ứng dụng kết quả của luận văn để giải quyết bài toán và cài đặt trên Activiti BPM. Cuối cùng là các kết quả đạt được.

2

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 chuyên 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 chuyên 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 chuyên 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 chuyên biệt miền (DSM) đã ra đời. DSM sử dụng một ngôn ngữ mô hình hóa chuyên 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 hoàn toàn được kiểm soát bởi người dùng.

Các mức độ trừu tượng caoSự trừu tượng rất quan trọng trong phát triển phần mềm. Trong suốt lịch sử phát

triển phần mềm, nâng cao mức độ trừu tượng là nguyên nhân của các bước nhảy vọt trong hiệu suất của nhà phát triển. Nếu nâng cao mức độ trừu tượng làm giảm tính phức tạp thì làm sao để tiếp tục nâng cao nó. Hình 1.1 thể hiện, các nhà phát triển tại

3

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 Trong bước 3, việc sinh code tự động từ thiết kế UML là không thể. Thay vì yêu

cầu nhà phát triển nắm vững cả miền vấn đề và lập trình, một giải pháp tốt hơn cho phép các nhà phát triển đặc tả ứng dụng dưới dạng đã từng biết và sử dụng, sau đó có các bộ sinh code sử dụng các đặc tả đó và tạo ra cùng loại code giống như họ viết bằng tay. Điều này sẽ làm tăng mức độ trừu tượng đáng kể; từ việc lập trình với byte/bit, thuộc tính và kết quả trả về; lên đến các khái niệm và luật lệ của miền vấn đề mà các nhà phát triển đang làm việc với. Sau đó, ngôn ngữ lập trình mới này hợp nhất với bước 1 và bước 2 và tự động hóa hoàn toàn ở bước 3. Mức độ trừu tượng được nâng lên gắn liền với code được sinh tự động là mục đích của DSM.

4

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 hoà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 chuyên 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 tuân 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

Ngôn ngữ chuyên biệt miền : cung cấp cơ chế trừu tượng để giải quyết sự phức tạp của miền cho trước. Điều này được thực hiện bằng cách cung cấp các khái niệm và các luật trong một ngôn ngữ biểu diễn miền ứng dụng hơn là các khái niệm của một ngôn ngữ

5

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 hoà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 chuyên biệt miền

Ngôn ngữ chuyên 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 chuyên 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.

DSML thường gồm cú pháp (syntax) và ngữ nghĩa (semantics). Cú pháp bao gồm cú pháp trừu tượng (abstract syntax) và cú pháp cụ thể (concrete syntax). Cú pháp trừu tượng biểu thị cấu trúc và các quy tắc ngữ pháp của một ngôn ngữ. Trong khi cú pháp cụ thể giải quyết các symbol ký hiệu và các biểu mẫu hiển thị mà ngôn ngữ sử dụng. Còn ngữ nghĩa biểu diễn ý nghĩa của các cụm từ và câu mà chuyên gia miền muốn diễn đạt. Để tăng sự trừu tượng thiết kế, cần mở rộng cả cú pháp và ngữ nghĩa.

6

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ữ chuyên 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 tuân 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 tuân 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ó. Nguyên 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ĩaMỗi khái niệm mô hình hóa đều có một số ý nghĩa, ngữ nghĩa. Khi thêm một

thành phần vào mô hình hoặc kết nối các phần tử với nhau, chúng ta tạo ra ý nghĩa. Trong DSM, ngữ nghĩa của ngôn ngữ mô hình hóa đến trực tiếp từ miền vấn đề. Ví dụ,

7

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 chuyên 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 soát truy nhập trong các tổ chức có quy mô từ trung bình đến lớn luôn 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).

Core RBAC [3] định nghĩa tối thiểu các phần tử, các tập phần tử và các mối quan hệ để đạt được một hệ thống điều khiển truy nhập dựa theo vai trò một cách hoàn chỉnh. Core RBAC được yêu cầu trong bất kì hệ thống RBAC nào nhưng các thành phần khác độc lập với nhau và có thể được cài đặt riêng rẽ. Các tập phần tử và các mối quan hệ của mô hình Core RBAC được thể hiện trong hình 3.

8

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. Ngoà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ò)

Một USER có thể là thành viên của nhiều ROLES và một ROLE có thể có nhiều USERS. Tượng tự, một ROLE có thể có nhiều PRMS và cùng PRMS có thể được gán cho nhiều ROLES. Một USER có thể kích hoạt một tập con các ROLES được gán cho

9

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 yê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.

Hình 1.4: MetaModel của RBAC

10

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

Môi trường kinh doanh hiện nay ngày càng trở nên gay gắt, doanh nghiệp luôn phải thay đổi để thích nghi và thỏa mãn nhu cầu của khách hàng. Nhằm xây dựng và duy trì lợi thế cạnh tranh của mình, doanh nghiệp cũng cần liên tục cải tiến các quy trình nghiệp vụ và BPM là một công cụ đắc lực hỗ trợ việc tối ưu các quy trình trong bộ máy vận hành của doanh nghiệp.

11

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 nguyên 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ụ

Việc tạo ra một quy trình nghiệp vụ bao gồm 5 pha được gọi là vòng đời BPM. Năm pha này là: Thiết kế, Mô hình hóa, Thực thi, Giám sát và Tối ưu. Mỗi pha được thiết kế để cài đặt một giải pháp quy trình thành công. Nhờ có vòng đời BPM, người ta có thể hiểu việc cài đặt một quy trình nghiệp vụ là một quá trình liên tục do những những thay đổi luôn xảy ra trong môi thường kinh doanh.

12

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ó.

Pha tối ưu là pha cuối cùng của vòng đời BPM. Trong pha này, thông tin hiệu năng của quy trình được lấy ra từ pha giám sát và các cải tiến, thay đổi trong quy trình được xác định. Một khi hoàn thành pha tối ưu, quy trình nghiệp vụ lại bắt đầu lại từ

13

pha thiết kế đến khi vòng đời hoàn tất. Cứ thế, vòng đời BPM là một quá 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 Chứa các các thành phần chính biểu diễn quy trình nghiệp vụ, đặc trưng cho hành

vi của một quy trình bao gồm : events, activities và gateways.

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

14

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

Start EventCho 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.

Intermediate 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 EventCho 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


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

Tái sử dụng các quy trình hoặc Task dùng chung và có sẵn trong hệ thống. Khi thực thi, hệ thống sẽ gọi tới các quy trình hoặc Task đó.

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ĩa15

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 GWTấ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ĩaSequence 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

AssociationsBiể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


Pool

Đại diện cho một thực thể trong quy trình nghiệp vụ. Pool có thể chứ một vài Lanes. Khi làm việc trong Pool, chúng ta không thể kết nối với các Activities bên ngoài Pool

LanesMộ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 16

Đượ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


Data objectHữu ích cho việc xem thông tin liên quan đến dữ liệu được yêu cầu trong Activity

GroupNhó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ụ hoàn toà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.

Activiti được chia thành các mô-đun khác nhau. Activiti Modeler, Activiti Designer, and Activiti Kickstart được sử dụng trong pha mô hình hóa để thiết kế quy trình. Activiti Engine được tích hợp với ứng dụng và được đặt tại vị trí trung tâm như một phần của pha thực thi. Để giám sát và quản lý quy trình, Activiti Explorer và Activiti Rest được sử dụng.

17

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

Activiti EngineActiviti 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 Sử dụng Activiti Engine APIs hoặc REST API để cấu hình process engine.

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

18

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 hoàn thành các Tasks

Activiti ModelerActiviti 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 DesignerAcitivi 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 ExplorerActiviti 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ụ. Ngoà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ử.

Activiti RESTActiviti 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.

19

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 chuyên biệt miền DSM đã được giới thiệu. Mục đích của mô hình hóa chuyên 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à hoàn toàn miễn phí giúp để mô hình hóa và thực thi các quy trình nghiệp vụ.

Các công cụ mô hình hóa quy trình nghiệp vụ hiện nay đang chỉ tập trung vào mô tả chính xác các yêu cầu chức năng của quy trình mà bỏ qua các yêu cầu an ninh. Chương tiếp theo của luận văn sẽ trình bày phương pháp tích hợp mô đun chính sách truy cập vào BPM nói chung và công cụ Activiti nói riêng.

20

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


Ở 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 yê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, ngoài ra, áp đặt các yê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à 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].

Để biểu diễn các yêu cầu an ninh trong mô hình hóa quy trình nghiệp vụ, cần một tiêu chuẩn kí hiệu có các khái niệm đồ họa cho phép biểu diễn ngữ nghĩa các yêu cầu an ninh. BPMN không có cơ chế biểu diễn các yêu cầu an ninh một cách tường minh. Tuy nhiên, trong tập các ký hiệu được sử dụng cho sơ đồ quy trình nghiệp vụ thì 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

21

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 yê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 toàn vẹn (Integrity), tính bí mật (Privacy) và kiểm soát truy cập (Access Control). Trong đó, tính bí mật và kiểm soá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 toà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.

Tính bí mật: phải xem xét một cơ chế tránh các lộ lọt thông trái phép. 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 toà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

22

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 yê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.

Sau khi các yêu cầu an ninh được tích hợp vào BPMN 2.0 cần thực thi các chính an ninh trong pha triển khai quy trình. Các hệ thống hiện đại thường chứa một tập các dịch vụ, cần ràng buộc các yêu cầu an ninh trên mỗi dịch vụ và bản thân việc kiểm tra các yêu cầu an ninh cũng là một dịch vụ được gọi bởi các dịch vụ khác. Áp dụng kiến trúc hướng dịch vụ SOA, xây dựng một webservice phục vụ việc kiểm tra các yêu cầu 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

23

yê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 toà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 yê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].

Eclipse Modeling Framework là một tập các Eclipse plug-ins được sử dụng để mô hình hóa một mô hình dữ liệu để sinh ra code hoặc các đầu ra khác dựa vào mô hình đó. EMF có sự khác biệt giữa metamodel và mô hình thực sự. Metamodel mô tả 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.

24

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

Eclipse là một môi trường phát triển Java và cũng là một nền tảng tích hợp công cụ được phát triển dưới dạng mã nguồn mở. Eclipse sẽ giúp tự động hóa các hoạt động tốn thời gian và cung cấp các công cụ sinh, chỉnh sửa và định vị mã nguồn Java. Tuy nhiên, Eclipse không chỉ là một môi trường phát triển tích hợp (IDE) [14]. Mục đích của nền tảng tích hợp công cụ Eclipse là tích hợp tất cả các công cụ hiện có của các nhà phát triển lại với nhau. Để thực hiện điều này, Eclipse chứa một nền tảng plug-in phức tạp cho phép các công cụ khác tích hợp liền mạch vào môi trường Eclipse dưới dạng các Plug-in. Plug-in đơn giản chỉ là một chương trình Java khác mở rộng chức năng của Eclipse theo một cách nào đó. Mỗi Eclipse plug-in có thể sử dụng các dịch vụ được cung cấp bởi các plug-in khác hoặc có thể mở rộng tính năng của nó để được sử dụng bởi các plug-in khác. Các plug-in đó được tải một cách tự động bởi Eclipse tại thời điểm run-time.

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 quá trình build

25

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à quá 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

Kéo thả các concept (Class, attribute, reference,..) từ Palette vào Visual Editor để xây dựng metamodel RBAC

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

26

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

Sinh code Java sau khi tạo được hai mô hình .ecore và .genmodel. Chuột phải nút gốc bpmn2 > Generate all.

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.

27

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

Tạo tab Security trong mô-đun “org.activiti.designer.gui” chứa hai component BindingOfDuty và SeparationOfDuty. Tương ứng khi kéo thả hai component này vào Visual Editor tạo ra các component của Eclipse được thiết kế có dạng hình

vuông, 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

28

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

<plugin> <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

class="org.activiti.designer.security.property.PropertyRbacSection" 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 toà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

29

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" ></atomicActivityAction>

<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ô

30

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 =""; for(SecurityFlow a : sodTask.getOutgoingSecurityFlow()){ 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>

31

<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 = linkService.getBusinessObjectForLinkedPictogramElement(…); 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 hoàn thành thì toà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.

32

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:

Bước 2: Trong quá trình quy trình được chạy, các chính sách truy nhập RBAC phải được kiểm tra. SoD và BoD được kiểm tra khi người thực hiện UserTask được chọn để gán. Đầu tiên, hệ thống sẽ liệt kê tất cả người dùng có quyền thực hiện task này. Sau khi lựa chọn, hệ thống sẽ kiểm tra xem người dùng có thỏa mãn ràng buộc SoD hay BoD hay không bằng cách kiểm tra người đó có nằm trong danh sách người dùng có quyền thực hiện các task tiếp theo. Ví dụ, UserTaskA và UserTaskB bị ràng buộc SoD, khi gán người thực hiện UserTaskA hệ thống cũng sẽ liệt kê tất cả người có quyền thực hiện UserTaskB; nếu người được chọn thực hiện UserTaskA cũng nằm trong danh sách thực hiện UserTaskB thì sẽ vi phạm SoD và hệ thống hiển thị thông báo lỗi: không cho phép người dùng đó được thực Task. 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()

33

.getIdentityService().createUserQuery().memberOfGroup(role).list();users.addAll(usersTmp);

}

for (User u : users) {if (selectedUser.equals(u.getId())) {

result = true;}

}return result;}...

}


Điểm cần nhấn mạnh ở chương này là đã có nhiều phương pháp tích hợp chính sách an ninh vào BPM và phương pháp sử dụng trong luận văn là một phương pháp đơn giản và hiệu quả nhất [3]. Hiện nay, các công cụ hỗ trợ quản lý quy trình nghiệp vụ như Oracle BPM, Activiti BPM hầu hết chỉ mới dừng lại hỗ trợ quản lý người 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 hoàn toà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.

Sau khi tích hợp mô đun chính sách truy nhập RBAC vào Activiti, hứa hẹn mang lại một công cụ mã nguồn mở, hoàn toàn miễn phí đáp ứng cả các yêu cầu chức năng cũng như các yêu cầu về an ninh trong quản lý và vận hành quy trình nghiệp vụ của doanh nghiệp. Ở chương tiếp theo, công cụ Activiti mới được tích hợp RBAC sẽ được cài đặt và chạy thử trong môi trường thực nghiệm.

34

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


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 toá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 chuyên 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.

35

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

Hiện tại, trong trung tâm đang thực thi rất nhiều quy trình nghiệp vụ, tuy nhiên, hầu hết các quy trình được thực hiện một cách thủ công và không hiệu quả dẫn đến 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. Yê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ó yêu cầu đặt xe thì không cần chữ ký này.

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

36

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ỉ http://localhost:8080/activiti-webapp-explorer2-5.8 . Activiti Explorer yêu cầu đăng nhập, user/password mặc định là kermit/kermit:

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.

37

http://localhost:8080/activiti-webapp-explorer2-5.8

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

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

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

38

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

Tạo Diagram tên “QuyTrinhDieuXe” : chuột phải thư mục diagram chọn File > New > Others > Activiti Diagram

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.

39

Hình 3.8: Visual Editor của Activiti

Kéo thả các component trong Palette để mô hình hóa quy trình điều xe. Các thuộc tính của từng component phải được cung cấp đầy đủ, bao gồm id, form,.. Sử dụng SeparationOfDuty và Security Flow để ràng buộc phân quyền đối với trưởng phòng và người quản lý điều xe.

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 yê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,

40

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 yê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

Định nghĩa một exclusive gateway sau khi người dùng điền thông tin vào Form. Nó sẽ kiểm tra chức vụ của người yêu cầu là “Nhân viên” hay “Trưởng phòng”. Có hai đầ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

41

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.

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

Để 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

42

SoD được dùng để ràng buộc người đã có quyền thực hiện task Manager Approval thì không có quyền hiện task Car Supervisor Approval. SoD sử dụng các SecurityFlow để xác định các task phải ràng buộc; sau đó,liệt kê tất cả các Permission được định nghĩa trong các task và lựa chọn các Permission mà SoD sẽ thực hiện.

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

43

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 yê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 yêu cầu về lịch trình. Còn nếu yêu cầu bị từ chối thì người yêu cầu sẽ nhận được thông báo về lý do bị yêu cầu bị từ chối.

Hình 3.16: Cấu hình MailTask

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

44

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

Triển khai quy trình : Manage > Deployments > Upload New và lựa chọn tệp QuyTrinhDieuXe.bpmn20.xml đã được mô hình hóa trong Activti Designer. Sau đó, quy trình đã sẵn sàng được thực thi.

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 >

45

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.

Hình 3.20: Biểu mẫu thông tin yêu cầu

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

46

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

Còn nếu không vi phạm thì người đăng nhập có thể gán lại task cho người khác trong cùng nhóm. Cửa sổ hiện lên danh sách người dùng thuộc nhóm. Nếu người đă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 Task47

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

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:

48

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_PROCINSTGROUP BY MONTH(START_TIME_)ORDER BY month_;

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.


Kết quả của thực nghiệm đã chứng minh công cụ Activiti tích hợp thêm mô đun RBAC đã giải quyết được bài toán vận tải nói riêng và các bài toán liên quan đến quy trình nghiệp vụ trong doanh nghiệp nói chung. Các yêu cầu an ninh đã được mô hình hóa ngay từ ban đầu tại pha thiết kế và từ sơ đồ BPMN cả chuyên gia nghiệp vụ, chuyên gia an ninh và chuyên gia hệ thống đều có thể hiểu chung một ngôn ngữ. Việc thực thi các chính sách RBAC cũng đã được thực hiện ở pha triển khai, cung cấp các thông báo thân thiện với người dùng về các vi phạm chính sách an ninh. Các bước cài đặt quy trình trên Activiti khá không quá phức tạp giúp cho một người không hiểu sâu về kỹ thuật cũng có thể tự thực hiện được.

49

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

50

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 toà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à hoàn thiện nội dung này.

Qua việc thực hiện luận văn, tôi đã thu được rất nhiều kiến thức bổ ý về hệ thống quản lý quy trình nghiệp vụ trong doanh nghiệp cũng như kiến thức về các kỹ thuật phát triển phần mềm hiện đại. Tuy nhiên, do kiến thức có hạn nên trong luận văn không thể tránh khỏi những sai sót, khiếm khuyết, tôi rất mong nhận được sự góp ý của quý thầy cô để luận văn được hoàn thiện hơn.

TÀI LIỆU THAM KHẢO

Tiếng Việt

1. Chu Thị Minh Huệ. (2011), “Ngôn ngữ mô hình chuyên 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.

51

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), “http://www.vogella.com/tutorials/EclipseEMF/article.html ” , Last visit was on 12/4/2018.

14.Eclipse.(2018), “http://www.eclipse.org/pde/”, Last visit was on 8/6/2018

52

http://www.vogella.com/tutorials/EclipseEMF/article.html

https://www.youtube.com/channel/UCRb628oyDYpbfJ-Shtn43WQ

Documents

lib.uet.vnu.edu.vnlib.uet.vnu.edu.vn/.../123456789/999/1/Luan-van_v2.0.docx · Web viewlà công trình nghiên cứu của riêng tôi và được sự hướng dẫn của TS