Truy cập là khái niệm để nói đến khả năng thực hiện một tác vụ nào đó sử dụng, đọc, thay đổi… của một chủ thể subject/user với một tài nguyên máy tính resource.Điều khiển truy cập access
Trang 1ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
Trang 2ĐẠI HỌC QUỐC GIA HÀ NỘI
TRƯỜNG ĐẠI HỌC CÔNG NGHỆ
LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN
NGƯỜI HƯỚNG DẪN KHOA HỌC: PGS.TS NGUYỄN VIỆT HÀ
Hà Nội, 2013
Trang 31
MỤC LỤC
MỤC LỤC 1
Danh mục hình vẽ 3
Danh mục bảng 4
Danh mục ký hiệu, từ viết tắt 5
MỞ ĐẦU 6
Chương 1 ĐIỀU KHIỂN TRUY CẬP THEO VAI TRÒ 8
1.1 Điều khiển truy cập 8
1.1.1 Điều khiển truy cập bắt buộc 8
1.1.2 Điều khiển truy cập tuỳ quyền 9
1.1.3 Điều khiển truy cập theo vai trò 9
1.1.4 Điều khiển truy cập theo luật 9
1.2 Các mô hình tham chiếu RBAC 10
1.2.1 Mô hình RBAC cơ sở 10
1.2.2 RBAC phân cấp 12
1.2.3 RBAC ràng buộc 14
1.2.4 Ưu nhược điểm của RBAC 16
1.3 Định danh dựa trên tuyên bố (Claims-based identity) 17
1.3.1 Tuyên bố (Claim) 17
1.3.2 Định danh (Identiy) 17
1.3.3 Principal 17
1.4 RBAC TRONG NET FRAMEWORK 17
1.4.1 Kiểm tra vai trò dựa trên khai báo 18
1.4.2 Kiểm tra vai trò trong mã nguồn 18
1.4.3 RBAC với ứng dụng ASP.NET 18
1.4.4 RBAC với ứng dụng ASP.NET MVC 19
1.4.5 Các hạn chế của RBAC trong Net Framework 20
Chương 2 MỞ RỘNG ĐIỀU KHIỂN TRUY CẬP RBAC VỚI LUẬT 21
Trang 42
2.1 Đặc tả điều khiển truy cập RBAC 21
2.2 Điều khiển truy cập theo luật 22
2.3 Mở rộng điều khiển truy cập RBAC với luật 25
2.4 Khiển khai RBAC mở rộng với luật 27
2.4.1 Kiến trúc tổng quát 27
2.4.2 Biểu đồ thành phần 29
2.4.3 Biểu đồ lớp 30
2.4.4 Biểu diễn và lượng giá luật với cây biểu thức 36
2.4.5 Authorization API 38
Chương 3 ỨNG DỤNG 41
3.1 Bài toán chia sẻ tệp 41
3.2 Phân tích, thiết kế hệ thống 42
3.2.1 Hiện trạng hệ thống 42
3.2.2 Phân tích hoạt động hệ thống 42
3.2.3 Lựa chọn nền tảng, công nghệ 43
3.2.4 Kiến trúc ứng dụng 43
3.2.5 Biểu đồ lớp 45
3.2.6 Biểu đồ trình tự 46
3.2.7 Điều khiển truy cập trong trong ứng dụng chia sẻ tệp 51
KẾT LUẬN 57
TÀI LIỆU THAM KHẢO 59
Trang 53
Danh mục hình vẽ
Hình 1.1: Mô hình RBAC [4] 11
Hình 1.2: Mô hình RBAC [4] 13
Hình 1.3: Mô hình SSD với RBAC phân cấp [4] 15
Hình 1.4 : Mô hình DSD [4] 15
Hình 2.1: Kiến trúc tổng quát 28
Hình 2.2: Biểu đồ thành phần 29
Hình 2.3: Biểu đồ lớp ClaimMembershipProvider 31
Hình 2.4: Biểu đồ lớp Authentication 32
Hình 2.5: Biểu đồ lớp Authorization 35
Hình 2.6: Logic điều khiển truy cập 39
Hình 3.1: Biểu đồ use case 43
Hình 3.2: Kiến trúc ứng dụng chia sẻ tệp 44
Hình 3.3: Biểu đồ lớp 45
Hình 3.4: Biểu đồ trình tự Hiển thị nội dung thư mục 46
Hình 3.5: Biểu đồ trình tự Tạo thư mục 47
Hình 3.6: Biểu đồ trình tự Upload file 47
Hình 3.7: Biểu đồ trình tự Download file 48
Hình 3.8: Biểu đồ trình tự Xóa thư mục, tệp 48
Hình 3.9: Biểu đồ trình tự Hiển thị danh sách người dùng 48
Hình 3.10: Biểu đồ trình tự Tạo người dùng 49
Hình 3.11: Biểu đồ trình tự Cập nhật thông tin người dùng 50
Hình 3.12: Biểu đồ trình tự Xóa người dùng 50
Trang 64
Danh mục bảng
Bảng 2.1: Ý nghĩa các thẻ trong đặc tả truy cập RBAC 22 Bảng 2.2: Ý nghĩa các thẻ trong đặc tả truy cập theo luật 25 Bảng 2.3: Ý nghĩa các giao diện, module 30 Bảng 2.4: Ý nghĩa các giao diện, lớp trong trong module ClaimMembership 31 Bảng 2.5: Ý nghĩa các giao diện, lớp trong module Authentication 32 Bảng 2.6: Ý nghĩa các giao diện, lớp trong module Authorization 35 Bảng 3.1: Ý nghĩa các lớp trong ứng dụng chia sẻ tệp 46
Trang 75
Danh mục ký hiệu, từ viết tắt
Trang 86
MỞ ĐẦU
Các hệ thống phần mềm thường có nhiều người sử dụng, mỗi người sử dụng lại có các vai trò khác nhau, hay nói cách khác họ có tập các đặc quyền khác nhau Vì thế cần đảm bảo rằng mỗi người sử dụng chỉ có thể thực hiện được các tác vụ mà họ có đặc quyền.Do đó, vấn đề đảm bảo an ninh trong các ứng dụng là một trong các yêu cầu quan trọng, cần quan tâm xem xét
Truy cập là khái niệm để nói đến khả năng thực hiện một tác vụ nào đó (sử dụng, đọc, thay đổi…) của một chủ thể (subject/user) với một tài nguyên máy tính (resource).Điều khiển truy cập (access control) là khái niệm để chỉ sự cho phép hay hạn chế sự truy cập của chủ thể với tài nguyên máy tính dưới một cách thức nào đó[6]
Kiểm soát truy cập là thuật ngữ dễ gây hiểu nhầm, trong một số trường hợp
nó được hiểu như sự kiểm soát quyền truy cập vào hệ thống từ bên ngoài (ví
dụ như kiểm soát quá trình đăng nhập, qua đó người dùng được truy cập vào vào máy chủ hay máy cá nhân).Trong thực tế, kiểm soát truy cập như vậy được gọi là xác thực (authenticate) người dùng.Trong khi, kiểm soát truy cập
đề cập đến việc kiểm soát quyền truy cập vào tài nguyên hệ thống sau khi thông tin tài khoản của người dùng đã được xác thực Ví dụ, một người dùng
cụ thể, hoặc một nhóm người sử dụng, chỉ có thể được phép truy cập vào các tập tin nhất định sau khi đã đăng nhập hệ thống, trong khi đồng thời bị từ chối quyền truy cập vào tất cả các tài nguyên khác
Với điều khiển truy cập theovai trò (Role Based Access Control – RBAC)[4], mỗi người sử dụng sẽ được gán một hoặc nhiều vai trò, mỗi vai trò có một tập các quyền truy xuất Quyền truy cập của mỗi người dùng là hợp các tập quyền truy xuất của tất cả các vai trò mà người sử dụng hiện đang thuộc về
RBAC là một phương pháp đơn giản, trực quan và hiệu quả, song nó vẫn còn những hạn chế, chẳng hạn như khi có hai người sử dụng có cùng một vai trò, nhưng quyền truy xuất khác nhau, do có các thông tin ngữ cảnh khác nhau Vì thế ta cần bổ sung thêm thông tin ngữ cảnh khi ra quyết định cho phép hay từ chối truy cập.Trên các Framework như EJB hay Net Framework đều hỗ trợ RBAC, tuy nhiên khi cần điều khiển truy cập theo vai trò kết hợp với các thông tin ngữ cảnh khác của người dùng thì mỗi ứng dụng phải tự xây dựng module điều khiển truy cập, việc này nghĩa là ngoài việc cài đặt nghiệp vụ của
Trang 97
ứng dụng, họ còn phải lo phần bảo mật của ứng dụng Việc tự cài đặt module điều khiển truy cập có thể bị sai sót, dẫn đến các kết quả đáng tiếc.Do vậy, tác giả đã đề xuất phương pháp mở rộng RBAC theo ngữ cảnh bằng phương sử dụng luật và triển khai đề xuất trên Net Framework Theo đó, các ứng dụng
sẽ không cần phải xây dựng module điều khiển truy cập riêng, mà chỉ cần mô
tả tài nguyên cần bảo vệ trong chương trình và định nghĩa các vai trò, các luật trong file điều khiển truy cập
Bố cục của luận văn như sau:
Chương 1, luận văn nghiên cứu phương pháp điều khiển truy cập theovai trò, các mô hình điều khiển truy cập RBAC Phân tích ưu, nhược điểm của RBAC
Chương 2, luận văn giới thiệu về điều khiển truy cập trong Net Framework, các hạn chế của điều khiển truy cập trong Net Framework
Chương 3, luận văn đề xuất một đặc tả truy cập dựa trên tệpmô tả, đặc tả truy cập dựa trên luật, đề xuất đặc tả cho phép mở rộng RBAC theo ngữ cảnh bằng cách kết hợp giữa đặc tả truy cập RBAC với luật.Cũng trong chương này luận văn đề xuất giải pháp triển khai đặc tả RBAC mở rộng với luật
Chương 4, luận văn đề xuất một ứng dụng thực tế sử dụng RBAC mở rộng như một demo cho phần triển khai RBAC mở rộng
Trang 108
Chương 1 ĐIỀU KHIỂN TRUY CẬP THEO VAI TRÒ
1.1 Điều khiển truy cập
Điều khiển truy cập là một phương thức dùng để hạn chế hoặc cho phép người dùng thực hiện thao tác nào đó trên tài nguyên[4] Các tài nguyên ở đây được hiểu theo nghĩa rộng, nó có thể là các mục dữ liệu trong CSDL, tệp, máy
in v.v Các thao tác có thể là đọc, ghi, cập nhật v.v
Điều khiển quyền truy cập bao gồm các bước cơ bản:
Định danh người dùng (Identification): bước này xác định người dùng
hệ thống là ai thông qua việc đưa ra thông tin định danh như username,
số chứng minh thư nhân dân…
Xác thực người dùng (Authentication): bước này xác định xem người dùng có thực sự có định danh như bước trước hay không thông qua việc đưa ra thông tin xác thực như mật khẩu, vân tay mà chỉ người dùng đó biết hoặc sở hữu
Kiểm soát quyền truy cập (Authorization): bước này xác định xem người dùng được làm gì trong hệ thống
Có nhiều phương pháp điều khiển truy cập khác nhau, song chúng được chia thành hai loại cơ bản: điều khiển truy cập bắt buộc (Mandatory Access Control - MAC) vàđiều khiển truy cập tuỳ quyền (Discretionary Access Control - DAC)[4]
1.1.1 Điều khiển truy cập bắt buộc
Điều khiển truy cập bắt buộc là khắt khe nhất trong tất cả các cấp kiểm soát[6] Ban đầu MAC được thiết kế để sử dụng bởi chính phủ MAC có một cách tiếp cận phân cấp để kiểm soát truy cập vào các nguồn tài nguyên Với MAC, việc điều khiển truy cập tới tất cả các tài nguyên hệ thống được thiết lập bởi người quản trị hệ thống, hay nói cách khác người dùng không có khả năng thay đổi quyền truy cập trên các tài nguyên hệ thống
Trong MAC, mỗi đối tượng trong hệ thống được gán một mức nhạy cảm Mức nhạy cảm của một chủ thể xác định khả năng truy cập của chủ thể.Để truy cập một đối tượng nào đấy, chủ thể phải có một mức độ nhạy cảm tương đồng hoặc cao hơn mức độ của đối tượng yêu cầu
Trang 119
1.1.2 Điều khiển truy cập tuỳ quyền
Với MAC, điều khiển truy cập được thiết lập bởi quản trị viên hệ thống (system administrator), thì vớiDAC, điều khiển truy cập trên một tài nguyên được thiết lập bởi người chủ của tài nguyênđó DAC là cơ chế kiểm soát truy cập mặc định cho hầu hết các hệ điều hành máy tính cá nhân[6]
Trong DAC, mỗi tài nguyên hệ thống có một danh sách truy cập (Access Control List-ACL) ACL chứa danh sách người dùng, nhóm và quyền truy
xuất cho mỗi người dùng, nhóm đó Ví dụ, người dùngA có quyền read-only, người dùng có quyền read và write, nhóm quản trị có toàn quyền
Cơ chế của DAC linh hoạt hơn nhiều so với MAC, nhưng cũng làm tăng nguy
cơ mất an toàn do không được quản lý tập trung bởi quản trị viên hệ thống
1.1.3 Điều khiển truy cập theo vai trò
Với điều khiển truy cậptheo vai trò, các quyết định truy cập dựa trên vai trò (role) mà người dùng thuộc về.Ví dụ, một kế toán trong một công ty sẽ được giao cho vai trò kế toán, được phép thực hiện các công việc liên quan đến kế toán.Tương tự như vậy, một kỹ sư phần mềm có thể được giao cho các vai trò nhà phát triển[6]
Khái niệm vai trò ở đây có điểm tương đồng với khái niệm nhóm.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, trong khi 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à một tập hợp các quyền hạn
Trong RBAC mỗi người dùng được gắn với các vai trò, các vai trò được gán một tập quyền Dongười dùng không được cấp phép quyền một cách trực tiếp, chỉ nhận được những quyền hạn thông qua vai trò (hoặc các vai trò) của họ, việc quản lý quyền hạn của người dùng trở thành một việc đơn giản, và người
ta chỉ cần chỉ định những vai trò thích hợp cho người dùng mà thôi
1.1.4 Điều khiển truy cập theo luật
Điều khiển truy cập theo luật (Rule Based Access Control), quyết định cho phép hay từ chối truy cập được xác định bởi một tập các luật (rules) được định nghĩa bởi quản trị hệ thống Tương tự như DAC, mỗi tài nguyên hệ thống sẽ có một danh sách các luật, khi người dùng truy cập đến tài nguyên,
Trang 1210
hệ thống sẽ kiểm tra tất cả các luật trên tài nguyên đó để quyết định cho phép hay từ chối truy cập Tương tự như MAC, người dùng không thể thay đổi được luật (quyền truy cập), chỉ có quản trị hệ thống mới có thể thay đổi được tập luật trên mỗi tài nguyên[6]
1.2 Các mô hình tham chiếu RBAC
Các mô hình tham chiếu RBAC bao gồm các phần tử cơ bản:
- User (người dùng)
- Role (vai trò)
- Objects (các đối tượng): Là những đối tượng mà người dùng muốn truy xuất, ta còn gọi Object là những tài nguyên hệ thống (system resource)
Ví dụ, như tệp, máy in, bản ghi trong cơ sở dữ liệu…
- Operations (thao tác): Là các thao tác mà người dùng thực hiện trên Object Ví dụ như read, write, print…
- Permissions (quyền hạn): Quyền thực thi Operation của chủ thể trên Object
Có bốn mô hình tham chiếu RBAC:
- RBAC cơ sở (Core RBAC),
- RBAC phân cấp (Hierarchical RBAC),
- RBAC ràng buộc tĩnh (Static Separation of Duty Relations)
- RBAC ràng buộc động (Dynamic Separation of Duty Relations)
1.2.1 Mô hình RBAC cơ sở
Mô hình này (Hình 1.1) bao gồm các phần tử cơ bản: người dùng (USERS), vai trò (ROLES), các đối tượng (OBS), các thao tác (OPS), các quyền hạn (PRMS) và mỗi quan hệ giữa chúng.Ngoài ra, mô hình RBAC cơ sở còn 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[4]
Trang 1311
(PA) Permission Assignment
IONS
PRMS
(UA) User Assignment
Một user được hiểu là một người dùng Tuy nhiên khái niệm người dùng cần
được hiểu theo nghĩa rộng, vì nó có thể là máy tính, tác nhân (agent) hay một
hệ thống khác Để đơn giản ta gọi chung là người dùng
Một role là một chức năng công việc trong ngữ cảnh của một tổ chức với một
số ngữ nghĩa có liên quan về quyền hạn và trách nhiệm
Một permission là một quyền hạn được phê duyệt để thực hiện một hoạt động
trên một hoặc nhiều đối tượng được bảo vệ
Một operationlà hành động của người dùng trên tài nguyên.Các operation có
thể có phụ thuộc vào mỗi hệ thống cụ thể, mỗi loại tài nguyên cụ thể Ví dụ, trong một hệ thống tập tin, các hoạt động có thể là read, write và execute; trong một hệ quản trị cơ sở dữ liệu, các hoạt động có thể là insert, update, và delete
Mục đích của bất kỳ cơ chế điều khiển truy cập nào là để bảo vệ tài nguyên hệ thống Tuy nhiên, trong RBAC chúng ta sử dụng thuật ngữ đối tượng được bảo vệ để nói đến các đối tượng chứa thông tin cần được bảo vệ như tệp, thư mục, hệ điều hành, bản ghi trong cơ sở dữ liệu hoặc cũng có thể là máy in, ổ cứng, CPU
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
Đặc tả RBAC cơ sở[4]:
Trang 1412
- USERS, ROLES, OPS, vàOBS (users, roles, operations, và objects)
- UA ⊆ USERS × ROLES, là quan hệ nhiều-nhiều giữa tập người dùng
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 (OPS × OBS), tập các quyền hạn
- PA ⊆ PRMS × ROLES, là quan hệ nhiều-nhiều giữa tập quyền với
tập vai trò, một vai trò có thể được cấp nhiều quyền, một quyền có thể được cấp cho nhiều vai trò
- assigned_permissions(r: ROLES)→2 PRMS , ánh xạ của vai trò r lên một tập các quyền hạn: assigned_permissions(r) = {p∈ PRMS | (p,r)
- 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
Trang 1513
(PA) Permission Assignment
IONS
PRMS
(UA) User Assignment
- Role
(RH) Role Hierarchy
Hình 1.2: Mô hình RBAC[4]
Điểm mấu chốt của mô hình này là giữa các vai trò có thể có quan hệ kế thừa,
nó cho phép một role con kế thừa tất cả các quền hạn của role cha.Có hai kiểu
kế thừa đó là: Mô hình phân cấp vai trò tổng quát (General Role Hierarchies)
và Mô hình phân cấp vai trò hạn chế (Limited Role Hierarchies)[4]
Mô hình phân cấp vai trò tổng quáthỗ trợ đa kế thừa (multiple inheritance)
Điều này có nghĩa là một role có thể kế thừa từ nhiều role khác
Định nghĩa hình thức[4]:
1 RH ROLES × ROLES được gọi là quan hệ kế thừa, viết tắt là ,
r1 r2 chỉ khi tất cả các quyền của r2 cũng là các quyền của r1 và tất
cả người sử dụng của r1 cũng là những người sử dụng của r2 r1
Trang 16RBAC ràng buộc (Hình 1.3) thêm các quan hệ phân chia trách nhiệm (Separation of Duty - SoD) vào mô hình RBAC cơ sở SoD được sử dụng để tránh xung đột về quyền hạn khi một người thuộc về các vai trò khác nhau
Mô hình RBAC ràng buộc được chia thành hai loại: Ràng buộc tĩnh (Static Separation of Duty Relations - SSD) vàràng buộc động (Dynamic Separation
of Duty Relations - DSD)
Ràng buộc tĩnh:
SSD ⊆ (2ROLES × N) là một tập các cặp (rs, n) trong SoD tĩnh, vớirs là một tập vai trò, t là một tập con của rs, và n là một số tự nhiên ≥ 2, với đặc tính không có người dùng nào được gán tới n hoặc nhiều hơn vai trò từ tập hợp rs trong mỗi cặp (rs, n)∈ SSD Một cách hình thức:
∀(rs, n) ∈ SSD, ∀t ⊆rs : |t | ≥ n ⇒rt assigned_users(r) = Ø
Ràng buộc tĩnh với RBAC phân cấp:
Đối với ràng buộc tĩnh trong mô hình RBAC phân cấp thì ta cần ràng buộc trên authorized users thay vì assigned users Một cách hình thức thì:
∀(rs, n) ∈ SSD, ∀t ⊆rs : |t | ≥ n ⇒rt authorized_users(r) = Ø
Trang 1715
(PA) Permission Assignment
IONS
PRMS
(UA) User Assignment
Hình 1.3: Mô hình SSD với RBAC phân cấp[4]
Ràng buộc động:
SoD động (Hình 1.4) cũng giống SoD tĩnh ở chỗ cả hai đều được sử dụng để giới hạn các quyền có thể được cung cấp đến người dùng DSD khác SSD ở giới hạn role được thiết lập trên mỗi phiên làm việc, điều này cho phép một người có thể có nhiều role có vai trò xung đột nhau, nhưng trong mỗi phiên làm việc thì các role được kích hoạt (active) là không xung đột Hay nói cách khác DSD cho phép một người dùng được xác thực cho hai hoặc nhiều vai trò
mà chúng xung đột nhau
(PA) Permission Assignment
IONS
PRMS
(UA) User Assignment
U
ser - S
ession
Sessio
- Role
Trang 1816
∀s ∈ SESSIONS, ∀rs∈2 ROLES ,∀role_subset∈ 2 ROLES , ∀n ∈ N, (rs, n) ∈ DSD, role_subset⊆rs, role_subset⊆session_roles(s) ⇒ |role_subset| < n
1.2.4 Ưunhược điểm của RBAC
1.2.4.1 Ưu điểmcủa RBAC
- Phù hợp với hầu hết các ứng dụng trong thực tế
- Mô hình đơn giản, hiệu quả
- Đơn giản trong việc quản trị quyền truy cập, thay vì quản lý quyền truy cập trên từng user ta sẽ quản lý quyền truy cập trên mỗi nhóm Việc này giúp giảm công sức, thời gian cũng như giảm rủi ro do nhầm lẫn
khả năng sử dụng lại trong mô hình RBAC
1.2.4.2 Nhược điểm của RBAC
Hầu hết các ứng dụng trong thực tế đều có thể điều khiển truy cập theo vai trò, vì thế RBAC có tính phổ dụng cao Tuy nhiên, nó cũng có một vài hạn chế:
- Không phù hợp với các ứng dụng có tài nguyên cần bảo vệ là chưa biết trước
- Không phù hợp khi quy tắc điều khiển truy cập phức tạp, việc điều khiển truy cập không chỉ dựa vào thông tin về vai trò, mà còn phụ thuộc vào các thông tin ngữ cảnh khác
- Không phù hợp với các ứng dụng mà một người dùng có thể mang nhiều vai trò mâu thuẫn nhau Điều này phần nào được giải quyết với
mô hình RBAC ràng buộc tĩnh hay động Tuy nhiên, khi các quy tắc đảm bảo tính loại trừ là phức tạp và chưa biết trước thì RBAC ràng buộc không đáp ứng được hoặc khó cài đặt
Trang 1917
1.3 Định danh dựa trên tuyên bố (Claims-based identity)
Claims-based identity là một cách phổ biến cho các ứng dụng khi cần thông tin nhận diện về người dùng trong tổ chức của họ hoặc trong tổ chức khác hoặc trên môi trường Internet.Nó cung cấp một cách tiếp cận thống nhất cho các ứng dụng [1]
1.3.1 Tuyên bố (Claim)
Một Claim là một phát biểu (Statement) về một thực thể (con người, tổ chức) được thực hiện bởi chính nó hoặc một người khác Chủ thể cung cấp claim được gọi là provider hay issuer
1.3.3 Principal
Principallà một đối tượng đặc biệt nó gắn với ngữ cảnh bảo mật (security context) của người dùng, trong khi Identity là thông tin định danh người dùng Mỗi thread có chứa một đối tượng Principal (Thread.CurrentPrincipal), thread này sẽ thực thi trong ngữ cảnh bảo mật của đối tượng Principal Có thể hình dung Principal nhưmột thẻ bài (token) của người dùng trong ứng dụng
1.4 RBACTRONG.NET FRAMEWORK
.Net Framework hỗ trợ RBAC thông qua hai hình thức: khai báo (Declarative)
và lập trình (Imperative) [5] Ngoài ra, với ứng dụng ASP.NET còn hỗ trợ
RBAC theo URL, hay với ASP.NET MVC đưa ra lớp AuthorizeAttribute để điều khiển truy cập trên các action của controller
Trang 2018
1.4.1 Kiểm tra vai trò dựa trên khai báo
.Net Framework cung cấp lớp PrincipalPermissionAttribute cho phép ta chỉ
định chỉ người dùng nào có vai trò nào đó mới có quyền thực thi phương thức bằng cách gắn khai báo ở đầu phương thức Ví dụ, để đảm bảo rằng chỉ có người sử dụng có vai trò là giao dịch viên mới có thể thực thi phương thức
Transfer ta làm như sau:
[ PrincipalPermission ( SecurityAction Demand, Role = "Teller" )]
void Transfer()
{
}
Việc khai báo cho phương thức Transfer thuộc tính
[PrincipalPermission(SecurityAction.Demand, Role = "Teller")] khiến Net Framework phải kiểm tra xem người dùng hiện tại (Thread.CurrentPrincipal)
có vai trò Teller hay không Nếu người dùng hiện tại không có vai trò Teller thì một SecurityException sẽ được ném ra, và như vậy phương thức Transfer
sẽ không được thực thi
1.4.2 Kiểm tra vai trò trong mã nguồn
Đôi khi ta không thể sử dụng cách thức khai báo như mục 1.4.1, bởi các lý do khác nhau như: ta chỉ muốn kiểm tra quyền truy cho một đoạn chương trình (block) mà thôi, thay vì toàn bộ phương thức, hoặc khi trong phương thức đó
có nhiều vai trò cần kiểm tra dựa vào các điều kiện khác nhau Với tình huống này ta cần đặt đoạn chương trình kiểm tra quyền truy cập vào bên trong code
của phương thức Mỗi Principal đều kế thừa từ IPrincipal, do đó để đảm bảo
chỉ những role xác định được quyền truy cập tới một tài nguyên nào đó ta sử
dụng phương thức IPrincipal.IsInRole Ví dụ, để đảm bảo rằng chỉ có người
sử dụng có vai trò là giao dịch viên mới có thể thực thi một tác vụ nào đó ta
sẽ kiểm tra như sau:
if ( Thread CurrentPrincipal.IsInRole( "Teller" ){
//Thực thi tác vụ nào đó mà chỉ có giao dị ch viên mới được phép
}
1.4.3 RBAC với ứng dụng ASP.NET
.Net Framework cho phép điều khiển truy cập theo URL thông qua việc thiết lập trong tệpweb.config của ứng dụng Ví dụ, chỉ có người sử dụng có role là
Trang 2119
Teller mới có quyền truy xuất đến trang Transfer.aspx và chỉ có người sử dụng có role là Admin mới có quyền truy xuất đến các trang trong thư mục Account ta làm như sau:
1.4.4 RBAC với ứng dụng ASP.NET MVC
ASP.NET MVC bổ sung lớp AuthorizeAttribute cho phép điều khiển truy cập cho các action của controller Ví dụ, để đảm bảo rằng chỉ có người sử dụng
có vai trò là giao dịch viên mới có thể thực thi action Transfer ta làm như sau:
[ Authorize (Roles = "Teller" )]
public ActionResult Transfer()
{
return View();
}
Chú ý rằng AuthorizeAttribute là một ActionFilter của ASP.NET
MVC[7]Error! Reference source not found., vì thế nó chỉ có thể được gắn
cho action của controller mà thôi, ta không thể dùng nó với các phương thức khác không phải là action.Hay nói cách khác nói chỉ được sử dụng cho ứng dụng ASP.NET MVC mà thôi
Trang 2220
1.4.5 Các hạn chế của RBAC trong Net Framework
.Net Framework chỉ cho phép điều khiển truy cập RBAC bằng cách chèn mã điều khiển truy cập vào trong chương trình, điều này dẫn đến các hạn chế:
- Logic điều khiển truy cập đan xen với logic nghiệp vụ
- Không linh hoạt khi cần thay đổi quyền truy cập, cụ thể là mỗi khi cần thay đổi điều khiển truy cập (thậm chí chỉ thay đổi tên của vai trò) cần sửa chương trình và biên dịch lại
- Việc điều khiển truy cập chưa hướng đến đối tượng được bảo vệ (tài nguyên hệ thống như tệp, printer…)
Vì thế ta cần tách biệt hoàn toàn logic điều khiển truy cập ra khỏi code (điều khiển truy cập nên được xác định trong tệp xml) Việc này cho phép code gọn hơn, linh hoạt hơn khi thay đổi quyền truy cập mà không cần sửa code và biên dịch lại chương trình.Hơn nữa việc điều khiển truy cập cần hướng tới đối tượng được bảo vệ hơn là phương thức
Trang 23<? xmlversion = 1.0 " encoding = utf-8 " ?>
< AccessControl >
< Resources >
< ResourceName = File "
< OperationName = View "
< RoleName = Admin " ></ Role >
< RoleName = Guest, HR " ></ Role >
nguyên có thuộc tính Name cho biết định danh của tài nguyên Định danh này là duy nhất
Operation Định nghĩa phép toán trên tài nguyên
Thuộc tính Name cho biết tên phép toán, tên phép toán là duy nhất trên mỗi tài nguyên
Trang 2422
hiện phép toán trên tài nguyên Thuộc tính Name cho biết tên vai trò
Bảng 2.1:Ý nghĩa các thẻtrong đặc tả truy cập RBAC
Đặc tả này là độc lập với code, vì thế ta có thể lưu đặc tả này trong file hoặc trong CSDL Trong luận văn này, chúng tôi lưu đặc tả truy cập trong một tệp xml.Đặc tả này cho phép ta định nghĩa các tài nguyên cần bảo vệ, các thao tác trên tài nguyên và vai trò nào được phép thực hiện thao trên tài nguyên
Ưu điểm của cách tiếp cận này là chương trình sẽ không có các chỉ thị để xác định xem vai trò nào được phép thực thi mà chỉ có chỉ thị để xác định đây là thao tác gì, trên tài nguyên nào, vì thế nó linh hoạt hơn khi ta muốn thay đổi quyền truy cập.Hơn nữa, nó hướng đến tài nguyên được bảo vệ hơn là phương thức
2.2 Điều khiển truy cập theoluật
Điều khiển truy cập theo luật cho phép ta ra quyết định chấp nhận hay từ chối truy cập bằng cách kết hợp các thông tin của người, mỗi luật là một phát biểu dưới dạng nếu - thì.Tuy nhiên Net Framework không hỗ trợ điều khiển truy cập theo luật Vì thế, chúng tôi đề xuất đặc tả điều khiển truy cập theo luật như sau:
<? xmlversion = 1.0 " encoding = utf-8 " ?>
Trang 26Rule Định nghĩa luật Mỗi luật có hai thuộc
tính là Id và Description Thuộc tín Id là duy nhất
Conditions Định nghĩa biểu thức điều khiện của
luật Thuộc tính Operator của Condition cho biết phép toán được thực hiện Coditions được biểu diễn dạng cây biểu thức
ClaimItem Định nghĩa claim được sử dụng trong
luật, thuộc tính ClaimType cho biết claim được sử dụng, thuộc tính DataType (tùy chọn) cho biết kiểu dữ liệu của claim Việc chỉ định kiểu dữ liệu cho claim sẽ giúp việc lượng giá luật chính xác hơn
luật Thuộc tính Value cho biết giá trị của hằng số, thuộc tính DataType cho biết kiểu dữ liệu
Condtions của luật là đúng Nó có thể nhận một trong hai giá trị là Allow và Deny
nguyên có thuộc tính Name cho biết định danh của tài nguyên Định danh này là duy nhất
Trang 2725
Operation Định nghĩa phép toán trên tài nguyên
Thuộc tính Name cho biết tên phép toán, tên phép toán là duy nhất trên mỗi tài nguyên
Rule (Thẻ con của Operation) Cho biết luật nào cần được kiểm tra khi
thực hiện Operation trên Resource
Bảng 2.2:Ý nghĩa các thẻ trong đặc tả truy cậptheo luật
Tương tự như đặc tả truy cập RBAC trong mục 2.1, đặc tả này là độc lập với code, vì thế ta có thể lưu đặc tả này trong file hoặc trong database.Đặc tả này cho phép ta định nghĩa các tài nguyên cần bảo vệ, các thao tác trên tài nguyên
và các luật
Điều khiển truy cập theo luật cho phép ta ra quyết định dựa vào việc kết hợp nhiều thông tin của người dùng với nhau, thay vì chỉ có thông tin về vai trò Hay nói cách khác, điều khiển truy cập theo luật là mềm dẻo và mạnh mẽ hơn điều khiển truy cập theo vai trò
2.3 Mở rộng điều khiển truy cập RBAC với luật
Như đã đề cập trong mục 1.2.4.1, ta cần mở rộng RBAC theo ngữ cảnh, hay nói cách khác quyết định chấp nhận hay từ chối không chỉ dựa vào vai trò của người dùng mà còn kết hợp với các thông tin khác của người dùng Vì thế, chúng tôi đề xuất kết hợp giữa RBAC với điều khiển truy cập theo luật
Chúng tôi đề xuất đặc tảmở rộng điều khiển truy cập RBAC với luật như sau:
<? xmlversion = 1.0 " encoding = utf-8 " ?>
Trang 28< RoleName = Admin " ></ Role >
< RoleName = Guest, HR " ></></ Role >
</ Operation >
< OperationName = Update "
< RoleName = Admin " RuleId = r1 " ></ Role >
< RoleName = HR " RuleId = r2, r3 " ></ Role >
Trang 2927
</ AccessControl >
Điểm khác biệt giữa đặc tả này với đặc tả trong mục 2.1và 2.2 là thẻ Role của Operation bao gồm hai thuộc tính Name và RuleId cho biết vai trò nào, luật nào cần được kiểm tra khi thực hiện phép toán trên tài nguyên
Đặc tả này cho phép ta định nghĩa các tài nguyên cần bảo vệ, các thao tác trên tài nguyên, các vai trò và các luậtgắn với mỗi vai trò Với cách tiếp cận này quyết định chấp nhận hay từ chối dựa vào cả vai trò lẫn các luật Hay nói cách khác ngoài thông tin về vai trò của người dùng, ta còn dựa vào thông tin ngữ cảnh khác của người dùng
2.4 Khiển khai RBAC mở rộng với luật
Trong mục này, tác giả đề xuất giải pháp triển khai RBAC mở rộng với luậttheo đặc tả được đề xuất trong 2.3 Triển khai này không nhằm hướng đến một kiểu ứng dụng cụ thể nào Vì thế, có thể sử dụng nó trong cả ứng dụng desktop (Windows form/Console) lẫn ứng dụng web (ASP.NET/ASP.NET MVC)
2.4.1 Kiếntrúc tổng quát
Triển khai ExtensibilityRBAC sử dụng WIF (Windows Identity Foundation) trên nền.Net Framework Kiến trúc tổng quát của ExtensibilityRBAC được đề xuất như sau:
Trang 3028
ExtensibilityRBAC Infrastructure
Authentication Authorization
ClaimMembership
.NET Framework Windows Identity Foundation NET Framework Desktop/Web Application
Hình 2.1: Kiến trúc tổng quát
ExtensibilityRBACInfrastructure bao gồm 3 thành phần:
Authentication: Thành phần này cung cấp dịch vụ xác thực người dùng,
nó được sử dụng cho các ứng dụng web Tuy nhiên, ứng dụng web có thể sử dụng một module xác thựckhác
ClaimMembership: Thành phần này cung cấp dịch vụ quản lý thông tin người dùng, nó được sử dụng bởi module Authentication Tuy nhiên, ứng dụng có thể sử dụng trình quản lý thông tin người dùng khác
Authorization: Điều khiển truy cập RBAC mở rộng với luật Đây là thành phần chính của ExtensibilityRBAC Nó được sử dụng trong bất
cứ ứng dụng nào (kể cả web lẫn desktop) muốn điều khiển truy cập RBAC mở rộng
ExtensibilityRBACchú trọng vào việc điều khiển truy cập.Tuy nhiên, để dễ dàng hơn cho việc sử dụng, chúng tôi đưa vào hai module Authentication và ClaimMembership như một giải pháp toàn diện Với các ứng dụng có sử dụng các dịch vụ xác thực khác như Google, Facebook vẫn có thể sử dụng module