ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
NGUYỄN THỊ THU PHƯƠNG
NGHIÊN CỨU PHƯƠNG PHÁP ĐIỀU KHIỂN
TRUY CẬP DỰA VAI TRÒ TRONG VIỆC
ĐẢM BẢO AN TOÀN CHO CÁC ỨNG DỤNG
DỰA THÀNH PHẦN Ngành: Công nghệ thông tin
Chuyên ngành: Công nghệ phần mềm
Mã số: 60 48 10 LUẬN VĂN THẠC SĨ
NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS. TS. Nguyễn Việt Hà
Hà Nội - 2011
iii


3.2.3. Thiết kế dữ liệu 36
3.2.4. Thiết kế hướng đối tượng 36
3.3. Điều khiển truy cập cho hệ thống 39
3.3.1. Phương pháp điều khiển truy cập hiện tại 39
3.3.2. Áp dụng RBAC cho hệ thống 41
KẾT LUẬN 47
TÀI LIỆU THAM KHẢO 49
iv Danh mục hình vẽ
Hình 1.1: Các thành phần EJB trong các ứng dụng đa tầng 6
Hình 1.2: Trình chứa EJB 8
Hình 1.3. Tương tác giữa client và thành phần EJB 8
Hình 2.1: Điều khiển truy cập truyền thống và Điều khiển truy cập dựa vai trò 16
Hình 2.2: Mô hình RBAC
0
17
Hình 2.3: Mô hình RBAC
1
20
Hình 2.4: Mô hình SSD 22
Hình 2.5: Mô hình DSD 23
Hình 2.6: Quan hệ giữa các mô hình RBAC 23
Hình 2.7: Mô hình RBAC
3
24
Hình 2.8: RBAC làm giảm độ phức tạp trong việc quản trị hệ thống 24
Hình 2.9: Các thành phần EJB trong hệ thống eBank
26

EJB Enterprise JavaBeans
IDL Interface Definition Language
J2EE Java 2 Enterprise Edition
JAAS Java Authentication and Authorization Service
JCA Java Cryptography Architecture
JCE Java Cryptographic Extension
JMS Java Message Service
JNDI Java Naming and Directory Interface
MAC Mandatory Access Control
MDB Message–Driven Bean
vi

MTS Microsoft Transaction Server
OLE Object Linking and Embedding
OMG Object Management Group
PTP Point to Point
RBAC Role-Based Access Control
RPC Remote Procedure Call
SDK Software Development Kit
SoD Separation of Duty
SSD Static Separation of Duty
TLS Transport Layer Security
UML Unified Modeling Language
VMC Model View Controller
WORA Write Once Run Anywhere
XML eXtensible Markup Language

1

Mở đầu

gây ra các vấn đề trong phát triển ứng dụng khi kết hợp các thành phần với
nhau.
Cùng với CORBA (Common Object Request Broker Architecture) và
COM/DCOM (Component Object Model/Distributed Component Object
Model), Enterprise JavaBeans (EJB) là một trong những mô hình thành phần
2

phổ biến nhất. Như nhiều mô hình thành phần khác, EJB sử dụng điều khiển
truy cập như một phương tiện để bảo vệ tài nguyên ứng dụng. Trong mô hình
thành phần EJB cũng như trong các mô hình thành phần khác, điều khiển truy
cập được thiết lập cho từng thành phần riêng lẻ (tức là dựa trên dữ liệu hoặc các
phương thức của các thành phần). Điều này có thể gây ra các vấn đề phát triển
ứng dụng khi kết hợp các thành phần lại với nhau để xây dựng ứng dụng.
Công nghệ thành phần phần mềm đã được đề cập đến trong một thời gian
dài và đã có rất nhiều định nghĩa khác nhau về công nghệ này (tức là một thành
phần là gì?). Bên cạnh đó, tồn tại nhiều mô hình thành phần khác nhau. Đối với
việc nghiên cứu về vấn đề an ninh trong công nghệ thành phần, cần lựa chọn
một trong các mô hình này. Luận văn này thực hiện theo mô hình thành phần
Enterprise JavaBeans (EJB) và tôi chỉ xem xét các cơ chế cấp phép
(authorization) của công nghệ này.
Việc cấp phép của công nghệ EJB dựa vào cơ chế điều khiển truy cập dựa
vai trò (Role-Based Access Control - RBAC). Trong RBAC, mỗi người dùng
được gán cho một hoặc nhiều vai trò. Mỗi vai trò có một tập các quyền truy cập
(tức là được phép thực hiện một phương thức nhất định). Quyền truy cập của
mỗi người dùng là hợp các tập quyền truy cập của tất cả các vai trò mà người sử
dụng hiện đang thuộc về.
Trong các ứng dụng EJB, có hai phương pháp để thiết lập điều khiển truy
cập dựa vai trò: điều khiển truy cập chương trình (programmatic access control)
và điều khiển truy cập khai báo (declarative access control). Trong phương pháp
thứ nhất, các chính sách kiểm soát được nhúng vào bên trong mã thành phần


4

Chương 1. Công nghệ thành phần phần mềm
1.1. Công nghệ thành phần phần mềm
Trong thập kỷ qua, kỹ nghệ phần mềm dựa thành phần (CBSE) đã trở thành
một chủ đề quan trọng trong kỹ nghệ phần mềm. Điều cần quan tâm là xây dựng
các ứng dụng phần mềm từ các thành phần phần mềm đã được xây dựng trước.
Mô hình này cung cấp nhiều lợi ích khi được so sánh với việc xây dựng ứng
dụng phần mềm từ đầu. Sử dụng các thành phần làm tăng khả năng dùng lại vì
các thành phần phần mềm có thể được sử dụng trong các ứng dụng khác nhau.
Điều này dẫn đến việc giảm chi phí sản xuất và giảm thời gian đưa ra thị trường
của phần mềm. Xây dựng các ứng dụng từ các thành phần cũng đơn giản hoá
việc bảo trì các ứng dụng. Ví dụ, khi ta muốn thay đổi một số chức năng của ứng
dụng, ta chỉ cần thay đổi các thành phần tương ứng với chức năng, các bộ phận
khác của ứng dụng được giữ lại nguyên vẹn. Ngoài ra, mỗi thành phần thường
tập trung vào một khía cạnh cụ thể và được phát triển bởi chuyên gia trong lĩnh
vực đó. Với việc mua các thành phần này từ thị trường, nhà phát triển ứng dụng
vẫn có thể có thành phần chất lượng cao mà không cần sử dụng các chuyên gia.
1.1.1. Một số định nghĩa
Mặc dù mọi người đều nhất trí về lợi ích của công nghệ dựa thành phần,
tuy nhiên quan điểm về một thành phần phần mềm lại rất khác nhau. Một số nhà
nghiên cứu cho rằng một thành phần giống như một thư viện. Một số người khác
lại cho rằng một thành phần phần mềm phải có khả năng triển khai một cách độc
lập. Luận văn này sử dụng định nghĩa về các thành phần phần mềm được đưa ra
bởi Szyperski [14].
Một thành phần phần mềm là một đơn vị của một tổ hợp với các giao diện
được xác định và chỉ phụ thuộc vào ngữ cảnh rõ ràng. Một thành phần phần
mềm có thể được triển khai một cách độc lập và là đối tượng để kết hợp bởi các
bên thứ ba.

Từ quan điểm của người phát triển ứng dụng, đảm bảo an ninh cho các ứng
dụng dựa thành phần là phức tạp vì các thành phần thường được mua từ thị
trường mà không có mã nguồn. Kết quả là, các đánh giá về an ninh của mỗi
thành phần riêng biệt cũng như toàn bộ ứng dụng đã tích hợp các thành phần này
là phức tạp. Ngoài ra, các thành phần có thể được mua từ nhiều nguồn (nghĩa là
từ các bên thứ ba khác nhau) và cơ chế an ninh của các thành phần này có thể
không tương thích.
Như đã đề cập ở trên, một trong những đặc trưng quan trọng nhất của công
nghệ thành phần là khả năng tái sử dụng của các thành phần. Một thành phần có
thể được sử dụng trong nhiều hệ thống khác nhau. Nhược điểm của đặc trưng
này là nếu thành phần chứa một lỗ hổng bảo mật, bất kỳ hệ thống nào đang sử
dụng nó cũng bị đe dọa.
6

1.2. Enterprise JavaBeans
1.2.1. Tổng quan
Sun Microsystems công bố đặc tả Enterprise JavaBean (EJB) vào năm
1998. Kiến trúc EJB là kiến trúc thành phần dành cho việc phát triển và triển
khai các ứng dụng phân tán hướng thành phần. Một thành phần EJB là thành
phần có khả năng sử dụng lại, viết một lần chạy mọi nơi (Write Once Run
Anywhere - WORA), có tính khả chuyển, tính linh hoạt và thành phần đã được
biên dịch có thể được triển khai trên bất kỳ máy chủ EJB nào như Java 2
Enterprise Edition (J2EE), JBoss hay môi trường WebLogic Enterprise. Công
nghệ EJB là một phần của J2EE, nó cung cấp một tập API và các dịch vụ khác.
Việc cài đặt EJB tập trung vào lô gic nghiệp vụ. J2EE được thiết kế để hỗ trợ
các ứng dụng doanh nghiệp cung cấp các dịch vụ thương mại.
Cùng với CORBA [9] và DCOM [11], Enterprise JavaBeans (EJB) [13] là
một trong những công nghệ hàng đầu cho việc phát triển các ứng dụng dựa
thành phần. Công nghệ EJB hỗ trợ xây dựng các thành phần trên máy chủ của
các ứng dụng J2EE đa tầng. Hình 1.1 dưới đây cho thấy vị trí của các thành

- Quản lý lưu trữ bền vững: đảm bảo trạng thái bền vững của một entity
bean được sao lưu bởi cơ sở dữ liệu.
- Quản lý vòng đời: đảm bảo sự dịch chuyển trạng thái của thành phần
EJB trong vòng đời của nó.
Trình chứa EJB cung cấp một giao diện cho thành phần EJB để giao tiếp
với thế giới bên ngoài. Tất cả các yêu cầu tới thành phần EJB hay các đáp ứng
từ thành phần EJB đều phải thông qua trình chứa EJB. Trình chứa EJB cô lập
thành phần EJB để nó không bị truy nhập trực tiếp từ các client. Trình chứa sẽ
chặn lời gọi từ client để đảm bảo tính bền vững, các đặc tính giao tác, và an ninh
các hoạt động của client trên EJB. Hình 1.2 chỉ ra rằng trình chứa EJB hỗ trợ
thành phần EJB và một thành phần EJB cần trình chứa để đi ra bên ngoài và để
nhận các thông tin cần thiết từ giao diện ngữ cảnh của nó. Trình chứa EJB có
trách nhiệm tạo ra các đối tượng EJB Home, giúp cho việc xác định, tạo và xóa
bỏ các đối tượng thành phần EJB. Giao diện ngữ cảnh EJB cung cấp bởi trình
chứa EJB đóng gói các thông tin liên quan về môi trường của trình chứa như là
định danh của một thành phần EJB, các trạng thái của giao tác và tham chiếu từ
xa tới EJB.
8 Hình 1.2: Trình chứa EJB
Thành phần EJB
Một enterprise bean là một thành phần phân tán trong một trình chứa EJB
và được truy cập bởi client từ trên mạng thông qua giao diện từ xa của nó hoặc
được truy nhập thông qua enterprise bean khác trên cùng server thông qua giao
diện địa phương (local) của nó. Thành phần EJB là một thành phần có khả năng
thực thi từ xa được triển khai trên server của nó và có khả năng tự mô tả được
chỉ ra bởi DD (Deployment Descriptor) với định dạng XML (eXtensible Markup
Language).
Mỗi thành phần EJB có một giao diện lô gic nghiệp vụ được tạo ra bởi

tạp, thay vì đó nó sẽ được thực hiện trên server. Giống như tên của nó, bean
phiên giống như một phiên tương tác (interactive session). Một bean phiên
không thể chia sẻ, nó chỉ có thể có một client. Giống như một phiên tương tác,
dữ liệu của bean phiên không được lưu vào cơ sở dữ liệu. Khi client ngắt, bean
phiên của nó cũng bị ngắt, nó không kết nối lâu dài với client. Có 2 kiểu bean
phiên đó là trạng thái (stateful) và phi trạng thái (stateless):
- Bean phiên trạng thái (stateful session bean): Trạng thái của một đối
tượng bao gồm giá trị của các biến. Trong một bean phiên trạng thái,
các giá trị biểu diễn trạng thái của một bean phiên cho duy nhất một
client. Vì client tương tác với bean của nó, trạng thái này thường được
gọi là trạng thái đàm thoại. Trạng thái này được duy trì trong suốt phiên
làm việc giữa client và bean. Nếu client loại bỏ bean hoặc ngắt, phiên
kết thúc và các trạng thái sẽ mất.
- Bean phiên phi trạng thái (stateless session bean): Không duy trì trạng
thái đàm thoại với client. Khi một client gọi các phương thức của một
bean phiên phi trạng thái, các biến của bean có thể chứa một trạng thái
cụ thể cho một client, nhưng chỉ trong thời gian của lời gọi. Khi
phương thức hoàn thành, trạng thái này sẽ bị mất. Tuy nhiên, các client
có thể thay đổi trạng thái của các biến trong bean phiên được lưu lại
10

(pooled stateless bean), trạng thái này sẽ được giữ đến lời gọi tiếp theo
của bean phiên. Vì bean phiên phi trạng thái có thể hỗ trợ nhiều client,
chúng có tính khả chuyển đối với các ứng dụng đòi hỏi số client lớn.
Đặc biệt, một ứng dụng yêu cầu ít bean phiên phi trạng thái hơn bean
phiên trạng thái để hỗ trợ cùng số client.
Bean thực thể (Entity Bean)
Một bean thực thể biểu diễn một dữ liệu bền vững được sao lưu bởi một cơ
sở dữ liệu. Các nhân viên, các phòng ban, và các giao dịch là những ví dụ của
bean thực thể. Mỗi bean thực thể có một bảng trong cơ sở dữ liệu và mỗi thể

bộ và loại thông điệp có thể là tin nhắn văn bản, tin nhắn đối tượng, tin nhắn
dòng, hoặc tin nhắn byte. Các gói tin được đẩy và xử lý trong một phương thức
Message Listener được gọi là onMessage().
1.2.2. Vấn đề an ninh trong công nghệ EJB
An ninh của các ứng dụng EJB bao gồm ba phần: mã hóa, chứng thực và
cấp phép [10]. Luận văn tập trung nghiên cứu sự cấp phép. Vì vậy, phần này chỉ
giới thiệu ngắn gọn về mã hóa và chứng thực. Cơ chế ủy quyền của EJB, có thể
được coi như một phần của sự cấp phép cũng sẽ được trình bày.
Mã hóa (Cryptography)
Sự mã hóa đạt được thông qua sự hỗ trợ của kiến trúc mã hóa Java (Java
Cryptography Architecture - JCA) và phần mở rộng mã hóa Java (Java
Cryptographic Extension - JCE). JCA cung cấp sự hỗ trợ quy tắc thông điệp và
chữ ký số. Trong khi đó, JCE cung cấp sự mã hóa.
Chứng thực (Authentication)
Sự chứng thực trong các ứng dụng EJB dựa trên JAAS (Java
Authentication and Authorization Service). JAAS là một giao diện linh hoạt
được cung cấp bởi Java 2 SDK (Software Development Kit). Nó cho phép người
phát triển ứng dụng viết các mô đun chứng thực tùy biến và cung cấp thủ tục
chứng thực mà không cần đến hệ thống an ninh cơ sở đang được sử dụng.
Cấp phép (Authorization)
Sự cấp phép của EJB dựa trên công nghệ điều khiển truy cập dựa vai trò.
Có hai cách thiết lập điều khiển truy cập bao gồm cả điều khiển truy cập chương
trình và điều khiển truy cập khai báo. Trong điều khiển truy cập chương trình,
các nhà phát triển bean sử dụng các API để kiểm tra sự cho phép của các vai trò
thực hiện các phương thức bean. Việc kiểm tra được nhúng bên trong mã của
các thành phần EJB. Ví dụ, để kiểm tra việc người dùng gọi một phương thức
trong vai trò VIPCustomer, người phát triển bean có thể sử dụng API EJB-
Context.isCallerInRole("VIPCustomer"). Hoặc, đối với việc lấy thông tin của
người dùng, có thể sử dụng API EJBContext.getCallerPrinciple(). Các dòng mã
trong danh mục 1.1 cho ví dụ về sử dụng điều khiển truy cập chương trình [15].

2 <role-name> VIPCustomer </role-name>
3 <method>
4 <ejb-name> TxBean </ejb-name>
5 <method-name> transfer </method-name>
6 </method>
7 </method-permission>
Khi các chính sách được nhúng bên trong mã EJB, cách thức chương trình
là tốt hơn so với cách thức khai báo trong việc xác định các chính sách điều
khiển truy cập mịn (fine-grained). Ví dụ, trong một số ứng dụng, các nhà phát
triển ứng dụng muốn kiểm soát luồng gọi nếu vai trò thực hiện là admin sau đó
m
1
() được thi hành, nếu không m
2
() được thi hành (danh mục 1.3). Trong trường
hợp này không thể sử dụng điều khiển truy cập khai báo.
Danh mục 1.3: Ví dụ trong đó bắt buộc dùng điều khiển truy cập chương
trình

1 if(ctx.isCallerInRole("admin") {
2 m
1
();
3 } else {
4 m
2
();
5 }
13


1 @Runas ("admin")
2 public class TxBean {
3
4 }

14

Chương 2. Điều khiển truy cập dựa vai trò (RBAC)
2.1. Giới thiệu
Điều khiển truy cập là một phương tiện có khả năng cho phép hoặc hạn chế
người dùng tương tác với tài nguyên. Các tài nguyên có thể là một tòa nhà, một
cơ quan, hoặc một hệ thống máy tính. Điều khiển truy cập, trong thực tế, là hiện
tượng hàng ngày. Khóa trên cửa xe là một hình thức điều khiển truy cập. Số PIN
trên một hệ thống ATM tại một ngân hàng là một phương tiện điều khiển truy
cập khác. Việc sở hữu điều khiển truy cập là việc quan trọng hàng đầu khi con
người tìm kiếm sự an toàn và bảo mật cho các thông tin nhạy cảm hay các thiết
bị.
Điều khiển truy cập dựa trên máy tính có thể quy định không chỉ con người
hay quá trình có thể truy cập vào một tài nguyên hệ thống cụ thể, mà còn quy
định loại truy cập nào là được phép.
Công nghệ điều khiển truy cập được phát triển từ nghiên cứu được hỗ trợ
bởi bộ quốc phòng Mỹ (DoD). Kết quả của nghiên cứu này là hai loại điều khiển
truy cập cơ bản: điều khiển truy cập tùy quyền (Discretionary Access Control -
DAC) và điều khiển truy cập bắt buộc (Mandatory Access Control - MAC).
Nghiên cứu ban đầu tập trung giải quyết việc ngăn chặn truy cập trái phép các
thông tin mật. Tuy nhiên, các ứng dụng ngày nay đã áp dụng các chính sách điều
khiển truy cập vào môi trường thương mại.
Điều khiển truy cập tùy quyền (DAC) cho phép việc cấp và thu hồi quyền
điều khiển truy cập theo quyết định của người dùng cá nhân [3]. Một cơ chế
DAC cho phép người dùng cấp hoặc thu hồi quyền truy cập tới bất kỳ đối tượng

xuất/nhập thông tin là phải đảm bảo các nhãn nhạy cảm được giữ gìn một cách
đúng đắn và nhiệm vụ này phải được thực hiện sao cho các thông tin nhạy cảm
phải được bảo vệ trong bất kỳ tình huống nào.
Những chính sách điều khiển truy cập này không đặc biệt thích hợp với yêu
cầu của các tổ chức xử lý các thông tin nhạy cảm nhưng không được phân loại.
Điều khiển truy cập dựa vai trò (Role-Based Access Control - RBAC) khác
với hình thức MAC và DAC truyền thống. MAC và DAC trước đây là hai mô
hình duy nhất được phổ biến trong điều khiển truy cập. Nếu một hệ thống không
dùng MAC thì người ta chỉ có thể cho rằng hệ thống đó dùng DAC, hoặc ngược
lại. Song các nghiên cứu trong những năm 1990 đã chứng minh rằng RBAC
không phải là MAC hoặc DAC. Hình 2.1 so sánh sự khác nhau giữa phương
pháp điều khiển truy cập truyền thống và phương pháp điều khiển truy cập dựa
vai trò.
Với điều khiển truy cập dựa vai trò, các quyết định truy cập dựa trên vai trò
mà người dùng cá nhân có như là một phần của một tổ chức.Vai trò liên quan
chặt chẽ đến khái niệm của nhóm người dùng trong điều khiển truy cập. Tuy
nhiên giữa hai khái niệm “vai trò” và “nhóm người dùng” vẫn có sự khác biệt.
Các nhóm người dùng như một đơn vị điều khiển truy cập thường được nhiều hệ
thống điều khiển truy cập cung cấp. Nhóm người dùng thường được xem như
như một tập hợp người dùng chứ không phải là một tập hợp các quyền hạn
(permission). Một vai trò một mặt vừa là một tập hợp người dùng mặt khác lại là
16

một tập hợp các quyền hạn. Vai trò đóng vai trò trung gian để kết nối hai tập
hợp này lại với nhau.

Hình 2.1: Điều khiển truy cập truyền thống và Điều khiển truy cập dựa vai trò
Ý tưởng cơ bản của RBAC là người dùng (user) được gắn với các vai
trò (role) và các vai trò lần lượt được giao quyền (permission). Kết quả là sự đơn
giản của các quyền quản lý. Trong nội bộ một tổ chức, các vai trò (roles) được

Nó định nghĩa một tập các phần tử RBAC cơ bản: users (người dùng), roles (vai
trò), permissions (quyền hạn), operations (hoạt động), objects (các đối tượng),
các quan hệ và các chức năng.
Mô hình tham chiếu NIST RBAC được định nghĩa trong bốn thành phần
mô hình [4] [5] [12]: RBAC cơ sở (Core RBAC), RBAC phân cấp (Hierarchical
RBAC), RBAC ràng buộc tĩnh (Static Separation of Duty Relations) và RBAC
ràng buộc động (Dynamic Separation of Duty Relations). Ngoài ra, mô hình
RBAC hợp nhất (RBAC
3
) là tổng hợp các mô hình trên.
2.2.1. Mô hình RBAC cơ sở
Mô hình RBAC cơ sở (còn gọi là RBAC
0
) bao gồm các tập phần tử và mối
quan hệ được định nghĩa trong hình 2.2. RBAC cơ sở gồm tập năm phần tử dữ
liệu cơ bản được gọi là người dùng (USERS), vai trò (ROLES), các đối tượng
(OBS), các hoạt động (OPS), và các quyền hạn (PRMS). Mô hình RBAC cơ sở
có tất cả những thành phần cơ bản được quy định như người dùng cá nhân được
phân công vào các vai trò và các quyền hạn được giao cho các vai trò. Như vậy,
vai trò là một phương tiện cho việc đặt tên cho các mối quan hệ nhiều-nhiều
giữa người dùng cá nhân và quyền hạn. Ngoài ra, mô hình RBAC cơ sở bao gồm
một tập các phiên làm việc (SESSIONS), mỗi phiên làm việc là một ánh xạ giữa
một người dùng và một tập con các vai trò được phân công cho người dùng.

Hình 2.2: Mô hình RBAC
0

18

Người dùng (user) trong mô hình là người dùng hệ thống. Khái niệm người

mối quan hệ này, có thể người dùng được cấp nhiều quyền truy cập hơn cần
thiết vì việc điều khiển bị giới hạn bởi các kiểu truy cập mà có thể được liên kết
với người dùng và các nguồn lực. Người dùng có thể cần danh sách các thư mục
và sửa đổi các tập tin hiện có, ví dụ, không cần tạo các tập tin mới, hoặc họ có
thể cần phải thêm bản ghi vào một tập tin mà không sửa đổi bản ghi hiện có.
19

Việc tăng tính linh hoạt cho việc điều khiển truy cập tài nguyên cũng làm tăng
tính ứng dụng của nguyên tắc quyền tối thiểu.
Mỗi phiên là một ánh xạ của một người dùng tới các vai trò có thể, một
người dùng thiết lập một phiên trong đó người dùng kích hoạt một số tập con
của vai trò mà họ được phân công. Mỗi phiên được liên kết với một người dùng
duy nhất và mỗi người dùng kết hợp với một hoặc nhiều phiên.
Định nghĩa của RBAC cơ sở như sau:
- USERS, ROLES, OPS, và OBS (users, roles, operations, và objects,
tương ứng).
- UA
⊆
USERS × ROLES, là quan hệ nhiều-nhiều của tập người dùng đối
với tập vai trò, một người dùng có thể có nhiều vai trò, một vai trò có
thể có nhiều người dùng.
- assigned_users(r:ROLES) → 2
USERS
, ánh xạ của vai trò r trên một tập
người dùng: assigned_users(r) = {u
∈
USERS | (u, r )
∈
UA}.
- PRMS = 2

ROLES
, ánh xạ của phiên s trên một tập
các vai trò: session_roles(s
i
)
⊆
{r
∈
ROLES | (session_users(s
i
), r)
∈

UA}.
- avail_session_perms(s: SESSIONS) → 2
PRMS
, các quyền hạn có thể đối
với một người dùng trong một phiên.
2.2.2. RBAC phân cấp
RBAC phân cấp (còn gọi là RBAC
1
) thêm khái niệm về phân cấp vai trò
vào RBAC
0
. Đó là những vai trò có quyền thừa kế từ các vai trò khác. Ví dụ,
20

nếu vai trò r
2
được thừa kế từ r

. Chú ý rằng, một người dùng của r
1
có
tất cả các quyền của r
2
, trong khi sự kế thừa quyền cho r
1
và r
2
không nói đến bất
cứ điều gì về phân công người dùng (User Assignment).
Có hai kiểu RH đó là: General Role Hierarchies (RH tổng quát) và Limited
Role Hierarchies (RH giới hạn).
RH tổng quát hỗ trợ định nghĩa đa kế thừa (multiple inheritance). Điều này
có nghĩa là nó cung cấp khả năng kế thừa quyền cũng như việc kế thừa người
dùng từ hai hay nhiều vai trò nguồn.
- RH
Í
ROLES × ROLES được gọi là quan hệ kế thừa, viết tắt là ,
r
1
r
2
chỉ khi tất cả các quyền của r
2
cũng là các quyền của r
1
và tất cả
người sử dụng của r
1