Luận văn Mở rộng công cụ Activiti cho đặc tả và cài đặt chính sách an ninh - Đỗ Anh Việt

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 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 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. 16 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 Associations 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 Đạ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 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 17 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ụ 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. 18 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  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 19 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 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ụ. 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 REST 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. 20 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. 21 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 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 22 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 23 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 24 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. 25 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 26  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 27  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. 28  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 29 Đượ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"> <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 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"> ... 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 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. 30  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: ... <seperationOfDuty id="Sod1" name="sod" outgoingSecurityFlow="sf1 sf2 " permissions="permission_id_1 permission_id_2 dynamicEnforcement="false"> <pemission id="permission_id_1" pName="Perm-usertask1-Full Access" roles="role_id_1" actions="action_id_1"> <atomicActivityAction id="action_id_1" actionName="Full Access" activityId="usertask2" permissions=" permission_id_1" > <pemission id=" permission_id_2" pName="Perm-usertask2-Full Access" roles="role_id_2" actions="action_id_2"> ... 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à . 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 getRoles(); List getActions(); List 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"> 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. 31 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: ... ... 32 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. 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 33 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 acs = new ArrayList(); for (Entry entry : securityList.entrySet()){ Map> permissions = entry.getValue().getSod(); if (permissions.containsKey(task.getTaskDefinitionKey())) { acs.add(entry.getValue()); } } List roles = new ArrayList(); for (AuthorizationConstraint ac : acs) { if (ac.getType().equals(AuthorizationConstraint.SoD)) { ac.getSod().remove(task.getTaskDefinitionKey()); for (Entry> entry : ac.getSod().entrySet()) { for (Permission p : entry.getValue()) { if (p.getAction().equals(Permission.PERMISSION_FULL_ACCESS)){ roles.add(p.getRole()); }}}} List users = new ArrayList(); for (String role : roles) { List usersTmp = ProcessEngines.getDefaultProcessEngine() .getIdentityService().createUserQuery().memberOfGroup(role).list(); users.addAll(usersTmp); } for (User u : users) { if (selectedUser.equals(u.getId())) { result = true; } } return result; } ... } 2.4. Tổng kết chương Đ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 34 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. 35 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 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. 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 36 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  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ỉ . Activiti Explorer yêu cầu đăng nhập, user/password mặc định là kermit/kermit: 37 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 Hình 3.4: Màn hình quản lý Process trên Activiti Designer 38  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  Tạo Diagram tên “QuyTrinhDieuXe” : chuột phải thư mục diagram chọn File > New > Others > Activiti Diagram 39 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  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. 40 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, 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 41 đầ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. Hình 3.12: Cấu hình kết quả phê duyệt của Manager Approval 42  Để 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  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. 43 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 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 44 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  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. 45 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. Hình 3.20: Biểu mẫu thông tin yêu cầu 46  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 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 47 đă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 Hình 3.24: Thực hiện phê duyệt yêu cầu 48  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 GROUP BY MONTH(START_TIME_) ORDER BY month_; 49 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 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. 50 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 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. 51 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. 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. 14.Eclipse.(2018), “”, Last visit was on 8/6/2018