3
MỤC LỤC
Danh mục các ký hiệu, các chữ viết tắt................................................................................... 4
Danh mục các hì nh vẽ .............................................................................................................. 5
GIỚI THIỆU ............................................................................................................................. 6
Chương 1: TỔNG QUAN VỀ HỆ THỐNG QUẢN LÝ ĐỊNH DANH................................ 8
1.1 Định danh số ................................................................................................................... 8
1.2 Hệ thống quản lý định danh .......................................................................................... 9
1.2.1 Các thành phần của hệ thống quản lý định danh .................................................... 10
1.2.2 Quy trình hoạt động chính của hệ thống định danh ................................................ 12
1.3 Các vấn đề trong việc xây dựng các hệ thống định danh ......................................... 12
1.3.1 Tính riêng tư ........................................................................................................... 13
1.3.2 Tính tiện dụng ......................................................................................................... 13
1.4 Phân loại hệ thống quản lý định danh ........................................................................ 14
1.4.1 Hệ thống quản lý định danh tập trung ..................................................................... 15
1.4.2 Hệ thống quản lý định danh dựa trên phân tích dữ liệu người dùng ...................... 15
1.4.3 Hệ thống quản lý định danh phân tán ..................................................................... 16
Chương 2: TỔNG QUAN VỀ CARDSPACE, OPENID VÀ OAUTH .............................. 18
2.1 CardSpace ..................................................................................................................... 18
2.2 OpenID .......................................................................................................................... 21
2.2.1 Giao thức OpenID ................................................................................................... 22
2.2.2 Tích hợp OpenID với CardSpace ............................................................................ 27
2.3 OAuth ............................................................................................................................ 30
2.3.1 Giao thức OAuth ..................................................................................................... 31
2.3.2 Tich hợp OAuth với CardSpace .............................................................................. 35
Chương 3: TÍCH HỢP OPENID VÀ OAUTH MỞ RỘNG VỚI THẺ THÔNG TIN
CARDSPACE.......................................................................................................................... 39
3.1 OpenID và OAuth mở rộng......................................................................................... 39
3.2 Giao thức trong OpenID và OAuth mở rộng ............................................................ 40
3.2.1 RP lấy thẻ yêu cầu từ IdP........................................................................................ 41
3.2.2 RP trao đổi mã truy cập với IdP .............................................................................. 41
3.3 Tích hợp OpenID và OAuth với CardSpace .............................................................. 42
Chương 4: THỰC NGHIỆM HỆ THỐNG .......................................................................... 46
4.1 Thử nghiệm hệ thống ................................................................................................... 46
4.2 Thực nghiệm chương trì nh.......................................................................................... 46
4.3 Phân tích sự bảo mật và tính dễ sử dụng ................................................................... 52
4.4 Kết quả thực nghiệm.................................................................................................... 53
KẾT LUẬN ............................................................................................................................. 54
TÀI LIỆU THAM KHẢO...................................................................................................... 56
4
Danh mục các ký hiệu, các chữ viết tắt
Viết tắt
ATM
CC
CP
HTML
HTTP
HTTPS
InfoCard
IdP
IP
IS
MAC
OAuth
Open Authentication
OP
PPID
RP
RST
RSTR
SAML
SIIP
SP
SSL
STS
TLS
UA
URI
URL
XHTML
XML
XRDS
XRI
Tên đầy đủ
Asynchronous Transfer Mode
Combined Consumer
Combined Provider
HyperText Markup Language
Hypertext Transfer Protocol
Hypertext Transfer Protocol Secure
Information Card
Identiti Provider
Internet Protocol
Identity Selector
Medium Access Control
Open Authentication
Open Authentication
OpenID Provider
Private Personal Identifier
Relying Party
Request Security Token
Request Security Token Response
Security Assertion Markup Language
Self Issued Identity Provider
Service Provider
Secure Sockets Layer
Security Token Service
Transport Layer Security
User Agent
Uniform Resource Identifier
Uniform Resource Locator
Extensible HyperText Markup Language
Extensible Markup Language
Extensible Resource Descriptor Sequence
Extensible Resource Identifier
5
Danh mục các hì nh vẽ
Hình 1.1: Các thành phần chính của hệ thống định danh ..............................................10
Hình 1.2: Một số ví dụ về thành phần Relying Party ...................................................11
Hình 1.3: Thành phần bộ chọn lọc (Identity Selector) của CardSpace .........................11
Hình 1.4: Các bước trong quy trình hoạt động của hệ thống quản lý định danh ..........12
Hình 2.1: Giao diện Windows CardSpace. ....................................................................18
Hình 2.2: Giao thức tương tác giữa RP và thẻ thông tin CardSpace .............................20
Hình 2.3: Cách thức tạo PPID và cặp khóa public/private ............................................21
Hình 2.4: Giao thức OpenID .........................................................................................23
Hình 2.5: Các bước trong quy trình xác định thành phần Identity Provider .................24
Hình 2.6 Sử dụng Yadis để xác định địa chỉ của Identity Provider ..............................25
Hình 2.7: Các bước trong quy trình gửi thuộc tính định danh ......................................26
Hình 2.8: Các bước trong quy trình kiểm tra thuộc tính định danh ..............................27
Hình 2.9: Giao thức tích hợp giữa OpenID và CardSpace ............................................28
Hình 2.10: Giao thức OAuth .........................................................................................32
Hình 2.11: Giao thức tích hợp giữa OAuth và CardSpace ............................................36
Hình 3.1: Giao thức tích hợp giữa OpenID và OAuth mở rộng với CardSpace ...........43
Hình 4.1: Ngữ cảnh thực thi chương trì nh ....................................................................47
Hình 4.2: Đoạn mã hiển thị Identity Selector ................................................................48
Hình 4.3: Chức năng người dùng lựa chọn CardSpace để đăng nhập...........................48
Hình 4.4: Đoạn mã javascript thực hiện việc gọi CardSpace của Microsoft ................49
Hình 4.5: Người dùng lựa chọn CardSpace trên giao diện IS .......................................50
Hình 4.6: Yêu cầu xác thực OpenID được gửi tới Google. ...........................................50
Hình 4.7: Google xác thực người dùng .........................................................................51
Hình 4.8: Thông tin của thẻ CardSpace nằm trong mã SAML .....................................52
Hình 4.9: Kết quả sử dụng CardSpace đăng nhập vào Sannhac.com ...........................52
6
GIỚI THIỆU
Thông thường, người dùng khi truy cập vào một hệ thống phải thực hiện quá
trình định danh để xác định tính hợp lệ của người dùng. Hiện nay, một số cơ chế định
danh được sử dụng phổ biến như: tên đăng nhập và mật khẩu, nhận dạng khuôn mặt,
vân tay. Tuy nhiên, do người dùng sử dụng nhiều hệ thống mà mỗi hệ thống lại có cơ
chế thực hiện định danh khác nhau nên người dùng sẽ cảm thấy khó khăn trong việc
nhớ và quản lý những thuộc tính định danh của mình, từ đó người dùng rất dễ bị lộ
định danh giữa các hệ thống khác nhau. Chẳng hạn như người dùng sử dụng nhầm lẫn
thuộc tính định danh hoặc đăng nhập vào các trang giả mạo dẫn đến để lộ các thông tin
về tên đăng nhập và mật khẩu. Vì vậy, các hệ thống quản lý định danh đã ra đời để
giúp quản lý các thuộc tính định danh của người dùng, từ đó đảm bảo tính an toàn và
tiện dụng khi người dùng thực hiện quá trình định danh. Nhằm nỗ lực cho việc quản lý
định danh được tốt thì một số hệ thống quản lý định danh nổi tiếng đã được đề xuất
như: CardSpace, OpenID, OAuth, v.v. Trong đó, CardSpace là hệ thống khá hoàn
chỉnh được Microsoft xây dựng và có thể hoạt động trên các máy có hệ điều hành
Windows. Mặc dù, mỗi hệ thống quản lý định danh có thể có danh sách các thành
phần, cách hoạt động, cách giao tiếp khác nhau, nhưng trong hệ thống quản lý định
danh thông thường có các thành phần:
Bên tin cậy (Relying Party - RP): Là dịch vụ sử dụng cơ chế định danh để
chứng thực.
Nhà cung cấp định danh (Identity Provider - IdP): Là nơi lưu trữ và quản lý
thuộc tính định danh.
Bộ chọn định danh (Identity Selector – IS): Là thành phần trung gian của hệ
thống, là cầu nối giữa người dùng, Relying Party và Identity Provider.
Trong thực tế, một RP chỉ hỗ trợ đăng nhập bằng thẻ thông tin CardSpace và một
nhà cung cấp dịch vụ IdP chỉ hỗ trợ OpenID, OAuth và những hệ thống này đang hoạt
động độc lập với nhau.
Từ thực trạng trên, việc xây dựng những hệ thống có tính sẵn sàng cao đối với
nhóm người dùng rộng lớn và khả năng tương tác giữa những hệ thống quản lý định
danh độc lập này là một việc cần thiết. Do đó, trong luận văn này chúng tôi đã tập
trung vào một số nội dung sau:
Tìm hiểu mối quan hệ giữa một RP chỉ hỗ trợ thẻ tin CardSpace với một nhà
cung cấp định danh chỉ hỗ trợ OpenID, OAuth và một User Agent (UA –
thường là trình duyệt web) hỗ trợ việc gọi thẻ thông tin CardSpace.
Đề xuất mô hình và phương pháp tích hợp giữa OpenID và OAuth mở rộng
được hỗ trợ bởi RP và IdP với hệ thống thẻ thông tin CardSpace.
Xây dựng chương trình mình họa cho mô hình và phương pháp tích hợp
OpenID và OAuth mở rộng với thẻ thông tin CardSpace.
Nội dung của luận văn được trình bày gồm:
7
Chương 1: Tổng quan về hệ thống quản lý định danh trình bày chi tiết về
hệ thống quản lý định danh, bao gồm các nguyên tắc, mô hình hoạt động
chung, một số hệ thống quản lý định danh hiện nay, cùng một số vấn đề khi
xây dựng hệ thống quản lý định danh.
Chương 2: Tổng quan về CardSpace, OpenID và OAuth trình bày chi tiết
về hệ thống quản lý định danh CardSpace, OpenID và OAuth, bao gồm nội
dung, giao thức, mô hình, phương pháp và giao thức tích hợp OpenID với
CardSpace, OAuth với CardSpace. Từ đó làm tiền đề cho việc tìm hiểu, phân
tích, đưa ra phương pháp tích hợp OpenID và OAuth mở rộng với CardSpace
ở Chương 3.
Chương 3: Tích hợp OpenID và OAuth mở rộng với thẻ thông tin
CardSpace trình bày chi tiết nội dung, giao thức OpenID và OAuth mở rộng,
phân tích những ưu điểm của OpenID và OAuth mở rộng so với OpenID,
OAuth. Từ đó đưa ra mô hình và phương pháp tích hợp OpenID và OAuth mở
rộng với thẻ thông tin CardSpace.
Chương 4: Thực nghiệm hệ thống trình bày về phần thực nghiệm cho mô
hình, phương pháp mà luận văn đã đề xuất ở trong Chương 3.
Kết luận trình bày những kết quả mà luận văn đã đạt được và hướng phát
triển của luận văn trong tương lai.
8
Chương 1
TỔNG QUAN VỀ HỆ THỐNG QUẢN LÝ ĐỊNH DANH
Chương này trình bày chi tiết về hệ thống quản lý định danh, bao gồm các
nguyên tắc, mô hình hoạt động chung, một số hệ thống quản lý định danh hiện nay,
cùng một số vấn đề khi xây dựng hệ thống quản lý định danh.
1.1 Định danh số
Hiện nay, mỗi học viên khi tham gia khóa học thạc sĩ tại trường đại học thì sẽ
được cấp một thẻ học viên và trên mỗi thẻ học viên có chứa một tập các thuộc tính
như: mã số học viên, họ tên, khoa, trường. Từ đó, nhà trường có thể sử dụng thẻ học
viên như một vật thể định danh để xác định học viên. Vì vậy, Định danh (identity) là
tập các thuộc tính để mô tả một người, một vật hoặc một nhóm [1]. Thông thường, các
thuộc tính định danh được chứa trong một vật thể định danh và một vật thể định danh
sử dụng cho một mục đích nhất định. Chẳng hạn, thẻ học viên của một học viên chỉ sử
dụng trong phạm vi một trường đại học nào đó. Tuy nhiên, có những vật thể định danh
có thể sử dụng cho nhiều ngữ cảnh khác nhau. Ví dụ: thẻ chứng minh nhân dân có thể
sử dụng cho học viên Trường Đại học Công Nghệ thi cuối môn, hoặc để xác định
quyền công dân của chính học viên đó.
Từ định nghĩa định danh, chúng ta có khái niệm định danh số: Định danh số
(digital identity) là định danh đã được số hóa để lưu trữ được trên các thiết bị điện tử .
Trong thực tế, có nhiều thuộc tính mô tả định danh cụ thể và các thuộc tính này có thể
sẽ được tổ chức một cách liên hợp, phân tán trên nhiều kho lưu trữ dữ liệu khác nhau
[2]. Có nghĩa là, những thuộc tính để định danh một chủ thể có thể được chia thành
nhiều phần, mỗi phần được lưu trữ ở nhiều nơi khác nhau.
Trước đây, khi rút tiền ở ngân hàng, người dùng sẽ phải mang chứng minh nhân
dân, đồng thời phải ký vào giấy xác nhận rút tiền. Nhân viên ngân hàng sẽ kiểm tra thủ
công những thuộc tính trên chứng minh nhân dân và chữ ký xem có khớp với thông tin
đã đăng ký trước đây. Nếu tất cả các thuộc tính đều khớp, nhân viên ngân hàng mới
tiến hành cho người dùng rút tiền. Ngày nay, người dùng chỉ cần thẻ ATM và mật
khẩu của thẻ cũng có thể rút được tiền từ ngân hàng. Khi người dùng sử dụng thẻ
ATM thì nhân viên ngân hàng sẽ không phải kiểm tra các thông tin một cách thủ công
như trước đây nữa.
Từ ví dụ minh họa trên, chúng ta thấy việc áp dụng định danh số vào quá trình
định danh làm nâng cao tính tiện dụng cho người dùng. Ngoài ra, quá trình định danh
trong ví dụ được thực hiện dưới sự kết hợp của hai tập thuộc tính định danh: tập thông
tin trên chứng minh nhân dân và thông tin về chữ ký như trước đây, hay tập thông tin
trên thẻ ATM và thông tin về mật khẩu hiện nay. Hơn nữa, các tập thuộc tính định
9
danh có thể được đặt ở nhiều nơi khác nhau. Sự kết hợp này làm cho quá trình định
danh được an toàn hơn.
Tương tự như định danh thế giới thực, định danh số trong thế giới world wide
web cũng có thể sử dụng chung thuộc tính định danh cho các hệ thống khác nhau.
Chẳng hạn, người dùng có thể sử dụng chung tên đăng nhập và mật khẩu cho hai hệ
thống khác nhau là Google Talk và GMail thông qua cơ chế đăng nhập một lần (Single
Sign On – SSO) [3].
Trong lĩnh vực khoa học máy tính, tất cả dữ liệu được lưu trữ dưới dạng các bit.
Vì vậy, thuật ngữ định danh và định danh số có thể xem là một. Trong phạm vi luận
văn này, thuật ngữ định danh sẽ được sử dụng thay cho thuật ngữ định danh số. Hiện
tại có rất nhiều thuộc tính được sử dụng để thực hiện quá trình định danh. Để tiện quản
lý trong quá trình định danh, người ta tiến hành phân loại các thuộc tính định danh.
Các thuộc tính định danh được phân làm hai loại là: Thuộc tính nhận dạng và
thuộc tính thông tin [1]. Trong đó:
Thuộc tính nhận dạng: là thuộc tính mô tả thông tin duy nhất mà chỉ có chủ thể
định danh đó sở hữu. Nói cách khác, thuộc tính nhận dạng có thể dùng để phân
biệt các thành phần định danh khác nhau. Ví dụ, ta có thể dùng thuộc tính là dấu
vân tay, khuôn mặt để phân biệt các đối tượng định danh.
Thuộc tính thông tin: là các thuộc tính mô tả chung về một đối tượng. Thuộc tính
chung này mô tả thông tin về một đối tượng. Thuộc tính thông tin có thể ổn định,
không thay đổi như giới tính, họ và tên, quê quán, ngày sinh. Những thuộc tính
hay biến động, có thể thay đổi như vị trí công việc, nơi ở.
1.2 Hệ thống quản lý định danh
Ngày nay, người dùng tham gia hoạt động trên nhiều trang web, ứng dụng khác
nhau như: Facebook, Twitter, Yahoo, Google. Đại đa số các trang web cần phải xác
minh danh tính người dùng thông qua hình thức xác thực tên đăng nhập và mật khẩu.
Sự kết hợp của tên đăng nhập và mật khẩu dẫn đến sự phân mảnh thông tin do người
dùng có rất nhiều tên đăng nhập và mật khẩu trên rất nhiều trang web khác nhau. Để
giảm số lượng các mật khẩu phải nhớ, người dùng có xu hướng sử dụng chung tên
đăng nhập và mật khẩu cho nhiều tài khoản khác nhau. Điều này dẫn đến vấn đề rất dễ
bị lộ mật khẩu giữa các hệ thống. Ví dụ, kẻ tấn công tạo ra một trang web giả và dụ
người dùng đăng nhập. Nếu người dùng sử dụng chung tên đăng nhập và mật khẩu thì
thông tin người dùng đã bị lộ. Để giải quyết vấn đề này, cần phải có một hệ thống
quản lý các thuộc tính định danh của người dùng, đó là hệ thống quản lý định danh.
Hệ thống quản lý định danh (Digital Identity Management System) là hệ thống
dùng để quản lý những thuộc tính định danh của người dùng [1]. Ngày nay, có rất
nhiều hệ thống quản lý định danh; mỗi hệ thống lại có giao thức, định dạng trao đổi
thông tin và cách sử dụng khác nhau [4]. Vì vậy, nhu cầu cần có một hệ thống quản lý
tất cả các hệ thống quản lý định danh của người dùng, đó là hệ thống quản lý định
danh liên hợp (Federated Identity Management System). Hệ thống quản lý định danh
10
liên hợp là hệ thống mô tả các công nghệ, tiêu chuẩn và các trường hợp sử dụng được
dùng để giúp định danh có thể được sử dụng xuyên suốt trên nhiều hệ thống khác nhau
[2]. Các hệ thống tiêu chuẩn của hệ thống quản lý định danh liên hợp không những
giúp cho các hệ thống định danh có thể dễ dàng giao tiếp được với nhau, mà còn hỗ trợ
cho các hệ thống định danh sau này có thể dễ dàng tích hợp vào hệ thống liên hợp.
1.2.1 Các thành phần của hệ thống quản lý định danh
Các hệ thống quản lý định danh rất đa dạng và phong phú. Mỗi hệ thống có thể
có cách hoạt động, cách giao tiếp, danh sách các thành phần khác nhau. Tuy nhiên,
trong hệ thống quản lý định danh thông thường có các thành phần:
Bên tin cậy (Relying Party - RP): là dịch vụ sử dụng cơ chế định danh để
chứng thực.
Nhà cung cấp dịch vụ (Identity Provider - IdP): là nơi lưu trữ và quản lý thuộc
tính định danh.
Bộ chọn lọc (Identity Selector – IS): là thành phần trung gian của hệ thống, là
cầu nối giữa người dùng, Relying Party, Identity Provider.
Hình 1.1 minh họa quá trình giao tiếp giữa các thành phần này với nhau.
Bên tin cậy (RP)
Nhà cung cấp dịch vụ
(IdP)
Bộ chọn lọc (IS)
Hình 1.1: Các thành phần chính của hệ thống định danh
Bên tin cậy (Relying Party - RP)
RP là dịch vụ sử dụng cơ chế định danh để chứng thực [5]. Ví dụ, một số trang
web sử dụng cơ chế đăng nhập người dùng để định danh như trang Zing, Yahoo. Hình
1.2 minh họa quá trình định danh sử dụng tên đăng nhập và mật khẩu với hình bên trái
là trang đăng nhập của Zing và hình bên phải là trang đăng nhập của Yahoo.
Hiện nay đã có rất nhiều thành phần RP trên mạng và nhiều RP cũng đã hỗ trợ
định danh bằng tài khoản của hệ thống khác như tài khoản email của Yahoo hay Gmail
(trong ví dụ Hình 1.2 là trang của Zing và Yahoo). Đây chính là nền tảng của hệ thống
OpenID và OAuth sẽ được chúng tôi sử dụng trong luận văn này.
Nhà cung cấp định danh (Identity Provider – IdP)
11
IdP là thành phần có nhiệm vụ quản lý các thuộc tính định danh của người dùng
hệ thống. IdP có chức năng truyền những thông tin cần thiết để thực hiện chứng thực
đến RP sau khi xác định đúng là người dùng đang sử dụng dịch vụ [5].
Hiện nay đã có rất nhiều hệ thống nổi tiếng đã xây dựng thành phần IdP cho
riêng mình dựa trên cơ chế của hệ thống OpenID, OAuth như Google, Yahoo.
http://login.me.zing.vn/
https://login.yahoo.com/
Hình 1.2: Một số ví dụ về thành phần Relying Party
Bộ chọn lọc (Identity Selector – IS)
IS là thành phần trung gian của hệ thống, là cầu nối giữa người dùng, RP và IdP.
Mọi hoạt động của IS được điều khiển trực tiếp bởi người dùng [5]. Thành phần IS nổi
tiếng là CardSpace được tích hợp sẵn trong hệ điều hành từ Window Vista trở lên với
tính tiện dụng cao.
Hình 1.3: Thành phần bộ chọn lọc (Identity Selector) của CardSpace
12
1.2.2 Quy trình hoạt động chính của hệ thống định danh
Hình 1.4: Các bước trong quy trình hoạt động của hệ thống quản lý định danh
Quy trình của một hệ thống quản lý định danh được minh họa trong Hình 1.4 bao
gồm các bước chính sau để thực hiện quá trình chứng thực:
Bước 1: Người dùng sẽ cung cấp thông tin về IdP cho thành phần IS.
Bước 2: Thành phần IS sẽ tự động giao tiếp với thành phần RP. Sau đó, IS sẽ
truyền các thông tin về IdP do người dùng cung cấp ở bước 1 đến thành phần
RP.
Bước 3: Thành phần RP sẽ sử dụng thông tin người dùng cung cấp để kết nối
với thành phần IdP (thông qua một kênh truyền an toàn). Sau đó, RP sẽ gửi
danh sách tên các thuộc tính cần thiết để thực hiện định danh đến thành phần
IdP thông qua kênh truyền an toàn đã được thiết lập.
Bước 4: Thành phần IdP sẽ tạo các thuộc tính cần định danh mà thành phần
RP yêu cầu ở bước 3. Sau đó, IdP sẽ ký xác nhận các thông tin mình tạo ra
bằng chữ ký của mình. Cuối cùng, IdP sẽ truyền thông điệp đã ký về IS.
Bước 5: IS sẽ hiện lên các thông tin định danh tương ứng. Sau đó, người dùng
sẽ kiểm tra các thông tin này và xác nhận có truyền những thuộc tính định
danh đến RP hay không.
Bước 6: Các thuộc tính định danh sẽ được truyền đến RP nếu người dùng đã
xác nhận ở bước 5.
Bước 7: RP sẽ kiểm tra những thuộc tính định danh và trả về kết quả cho
người dùng.
1.3 Các vấn đề trong việc xây dựng các hệ thống định danh
Trong việc xây dựng các hệ thống quản lý định danh, cần có những tính chất làm
tiêu chí để đánh giá chất lượng của hệ thống. Các tính chất đó bao gồm:
Tính riêng tư: Đảm bảo an toàn cho các thuộc tính định danh.
13
Tính tiện dụng: Đảm bảo sự thoải mái trong quá trì nh người dùng sử dụng hệ
thống.
Hai tính chất này sẽ được trình bày chi tiết trong mục 1.3.1 và 1.3.2.
1.3.1 Tính riêng tư
Theo Pfitzmann và Hansen [6] thì tính riêng tư có một số đặc điểm chính sau:
Tính nặc danh
Tính nặc danh (anonymity) đảm bảo người dùng có thể sử dụng tài nguyên hay
dịch vụ mà không bị lộ định danh. Điều này có nghĩa là : ngoài các thành phần trong
hệ thống (Identity Provider và Relying Party), không một thành phần nào khác biết
được người dùng đang sử dụng dịch vụ trên mạng.
Tính không thể liên kết
Người dùng có thể sử dụng nhiều nguồn tài nguyên hay dịch vụ khác nhau trên
mạng, tuy nhiên phải đảm bảo những người khác không liên kết những thông tin này
để suy ra một số đặc điểm liên quan đến người dùng. Ví dụ, người dùng sử dụng cùng
lúc dịch vụ email của Google và Yahoo, hệ thống phải có cơ chế đảm bảo những kẻ
tấn công không thể phát hiện ra hai địa chỉ email là của cùng một người dùng. Ví dụ
khắc phục, người dùng có thể sử dụng những tên đăng nhập khác nhau cho các hệ
thống email khác nhau.
Tính an toàn thông tin
Tính an toàn thông tin liên quan đến khả năng bị lộ thông tin cá nhân cho các tổ
chức bên ngoài. Tổ chức này có thể là cộng đồng trên mạng, các nhà cung cấp dịch vụ
hoặc các kẻ tấn công. Tính chất này đặc biệt quan trọng khi chúng tôi tích hợp giao
thức OpenID và OAuth với thẻ thông tin CardSpace.
Tính bí danh
Hệ thống không những phải đảm bảo không để lộ các thuộc tính định danh, mà
còn phải chịu trách nhiệm đến các hoạt động định danh của người dùng. Tính bí danh
gần giống tính nặc danh. Trong khi tính nặc danh đảm bảo không biết có người sử
dụng hệ thống, ngược lại trong tính bí danh, kẻ tấn công vẫn có thể biết có người sử
dụng hệ thống nhưng không rõ là người nào.
1.3.2 Tính tiện dụng
Các tiêu chí đánh giá về tính tiện dụng của một hệ thống quản lý định danh gồm
các tính chất sau:
Tính dễ hiểu
Tính dễ hiểu nhằm đảm bảo người dùng hiểu đúng và đủ về hệ thống. Nếu không
hiểu được các khái niệm trong hệ thống, người dùng sẽ không thể sử dụng hệ thống
đúng cách.
Khả năng phòng tránh lỗi
14
Các hệ thống quản lý định danh không chỉ có khả năng chịu lỗi mà còn phải đảm
bảo cung cấp các hỗ trợ, cảnh báo, phản hồi đến người dùng trước khi các lỗi bảo mật
nghiêm trọng xảy ra.
Ví dụ, khi có kẻ tấn công xâm nhập hệ thống, hệ thống quản lý định danh phải
tiến hành ngăn chặn, đồng thời cung cấp các thông tin cần thiết cho người dùng về kẻ
tấn công như: địa chỉ IP, thời gian, phương thức tấn công, v.v. Một ví dụ khác là trong
trường hợp người dùng có nhiều thành phần IdP để thực hiện quá trình đăng nhập. Hệ
thống quản lý định danh phải đảm bảo hiển thị các thông tin đầy đủ và rõ ràng về các
thành phần IdP. Điều này hỗ trợ người dùng không nhầm lẫn trong quá trình chọn
thành phần IdP để thực hiện quá trình định danh.
Khả năng tương thích với các chức năng của hệ thống
Thông thường, hệ thống quản lý định danh là một bước phụ trong quá trình thực
hiện nghiệp vụ cụ thể của người dùng. Ví dụ, khi người dùng mua hàng trên mạng,
trước khi thanh toán sẽ thực hiện quá trình định danh. Tính chất này nhằm đảm bảo
rằng hệ thống quản lý định danh phải tích hợp với hệ thống nghiệp vụ chính sao cho
mang lại tính tiện dụng cho người dùng. Hệ thống định danh không gây xung đột với
hệ thống có sẵn.
Khả năng kiểm soát có nhận thức
Hệ thống phải lấy người dùng làm trung tâm. Điều đó có nghĩa là người dùng có
thể kiểm soát mọi hoạt động của hệ thống. Ngoài ra, người dùng còn phải có cảm giác
làm chủ được hệ thống. Quy trình hệ thống phải tránh những thao tác thừa hoặc không
đầy đủ tạo cảm giác không an toàn cho người dùng.
Tính thân thiện
Các chức năng của hệ thống phải thân thiện, hướng người dùng. Hệ thống phải
làm cho người dùng cảm thấy thích, thú vị, hài lòng khi sử dụng. Mục tiêu chính của
hệ thống quản lý định danh là bảo mật thông tin người dùng. Tuy nhiên, nếu hệ thống
quá phức tạp thì người dùng thông thường không thể sử dụng được. Vì vậy, hệ thống
phải linh động trong quá trình bảo vệ thông tin và tính thân thiện đối với người dùng.
Các tính chất về tính riêng tư và tính tiện dụng đã được trình bày dưới nhiều
dạng khác nhau ở nhiều nơi trên thế giới. Điều này một lần nữa cho thấy rằng: các tính
chất trên đặc biệt quan trọng, nên đây là những tiêu chí chính để xây dựng và đánh giá
hệ thống đề xuất của chúng tôi trong luận văn này.
1.4 Phân loại hệ thống quản lý định danh
Hệ thống quản lý định danh được phân làm ba loại chính là: hệ thống quản lý
định danh tập trung, hệ thống quản lý định danh dựa trên phân tích dữ liệu người dùng
và hệ thống quản lý định danh không tập trung [7]. Mỗi loại có những ưu điểm và
nhược điểm khác nhau. Sau đây, chúng tôi sẽ trình bày về ba loại hệ thống quản lý
định danh này.
15
1.4.1 Hệ thống quản lý định danh tập trung
Theo Gail-Joon Ahn [7]: hệ thống quản lý định danh tập trung là hệ thống mà tất
cả các định danh của người dùng sẽ được chứng thực, lưu trữ ở một nơi cung cấp định
danh tập trung duy nhất (Identity Provider) thuộc về cùng một hệ thống quản lý định
danh.
Trong hệ thống quản lý định danh tập trung, người dùng không có quyền tự quản
lý thông tin của mình. Tất cả thuộc tính định danh cũng như các giai đoạn chứng thực,
phân quyền đều được quản lý tập trung trên một IdP duy nhất.
Ưu điểm
Khả năng quản lý các thuộc tính định danh tốt.
Dễ dàng quản lý (thêm xóa sửa) và truy xuất các thuộc tính định danh.
Không bị trùng lắp thuộc tính định danh.
Vì các định danh của người dùng được lưu trữ ở một IdP duy nhất, nên người
dùng không cần phải nhớ định danh của mình được lưu trữ ở đâu,.
Dữ liệu được bảo vệ tập trung chỉ ở IdP.
Khuyết điểm
Vì vi phạm tính riêng tư nên không thích hợp lưu trữ các định danh cá nhân.
Vì thông thường các hệ thống quản lý định danh tập trung có cơ chế lưu trữ và
định danh khác nhau nên gặp khó khăn trong q uá trình hợp nhất giữa hai hệ
thống quản lý tập trung.
Dữ liệu được quản lý tập trung tại IdP. Vì vậy, khi hệ thống lưu trữ định danh
gặp vấn đề, toàn bộ hệ thống sẽ bị tê liệt.
Mọi thông tin cá nhân người dùng đều được tạo và cấp bởi hệ thống máy chủ.
Khi nắm thông tin về thời gian người dùng truy cập IdP, người tấn công có thể
biết khi nào người dùng sử dụng dịch vụ. Điều này làm vi phạm tính riêng tư
người dùng.
Người dùng muốn sử dụng dịch vụ thì phải cùng mạng với hệ thống quản lý
định danh (có thể trong một mạng nội bộ). Vì vậy các hệ thống ở các mạng
nội bộ khác không thể sử dụng các dịch vụ này được. Điều này vi phạm khả
năng di động của hệ thống.
Thông thường, hệ thống quản lý định danh tập trung được dùng trong phạm vi
trong một công ty hoặc một tổ chức nhất định.
1.4.2 Hệ thống quản lý định danh dựa trên phân tích dữ liệu người
dùng
Các hệ thống quản lý định danh dựa trên phân tích dữ liệu người dùng thường có
chức năng khai thác dữ liệu để phân loại các định danh. Ví dụ, hệ thống sẽ dựa vào độ
tuổi, nghề nghiệp của khách hàng để bố trí trang web cho phù hợp (các trang bán hàng
mỹ phẩm, thời trang, v.v.).
16
Ưu điểm của phương pháp quản lý định danh dựa trên sự phân tích dữ liệu người
dùng là giúp cho hệ thống linh hoạt hơn trong quá trình hiển thị các thông tin liên
quan, hoặc có thể đưa ra những thông tin quảng cáo phù hợp. Vì vậy, hệ thống quản lý
định danh này phù hợp cho các ứng dụng thương mại.
Tuy nhiên, nếu phương pháp quản lý định danh dự trên sự phân tích dữ liệu
người dùng không tốt sẽ dẫn đến thông tin hiển thị không chính xác. Điều này có thể
khiến cho người dùng thiếu hoặc thừa những thông tin cần thiết.
1.4.3 Hệ thống quản lý định danh phân tán
Hệ thống quản lý định danh phân tán là hệ thống mà thuộc tính định danh người
dùng sẽ được lưu trữ và chứng thực ở các Identity Provider khác nhau [7].
Dữ liệu của hệ thống quản lý định danh phân tán thường được quản lý trực tiếp
bởi người dùng. Tuy nhiên, trong một số trường hợp, cần phải có tổ chức thứ ba để
chứng nhận dữ liệu người dùng hợp lệ. Thuộc tính định danh có thể được lưu trữ trong
máy tính cá nhân, hoặc các IdP khác nhau trên mạng.
Ưu điểm
Do hệ thống có nhiều IdP vì vậy tránh được phương pháp tấn công tập trung
trên một IdP.
Định danh được lưu trữ phân tán ở nhiều IdP. Vì vậy trong trường hợp một
IdP gặp vấn đề, người dùng vẫn có thể lấy thông tin ở một IdP khác để thực
hiện việc chứng thực.
Hệ thống có thể có nhiều IdP để lưu trữ thuộc tính định danh. Vì vậy, hệ thống
tránh được trường hợp người dùng bị truy vết khi sử dụng dịch vụ trên mạng.
Đồng thời phạm vi sử dụng của người dùng cũng rộng hơn khi chỉ lưu trữ ở
một IdP như hệ thống quản lý định danh tập trung.
Nhược điểm
Tồn tại nhiều IdP gây bất tiện cho việc quản lý định danh của người dùng, khi
muốn truy xuất nhiều định danh họ phải tiến hành đăng nhập vào nhiều hệ
thống.
Người dùng phải nhớ được IdP nào sẽ lưu trữ thuộc tính định danh mà mình
cần truy xuất hoặc chỉnh sửa.
Mỗi một hệ thống IdP đều yêu cầu có cơ chế định danh để chứng thực. Vì vậy,
người dùng lại phải ghi nhớ các định danh này. Nếu người dùng phải nhớ quá
nhiều định danh thì người dùng sẽ có cảm giác khó chịu dễ gây nhầm lẫn.
Nội dung của chương 1 đã trình bày các khái niệm về định danh số, hệ thống
quản lý định, các thành phần chính của hệ thống quản lý định danh, các vấn đề trong
việc xây dựng các hệ thống quản lý đị nh danh và phân loại các hệ thống định danh .
Chi tiết về hệ quản lý định danh OpenID, OAuth, CardSpace và phương pháp tích hợp
OpenID với CardSpace, OAuth với CardSpace sẽ được trình bày trong chương 2.
17
18
Chương 2
TỔNG QUAN VỀ CARDSPACE, OPENID VÀ OAUTH
Chương này trình bày chi tiết về hệ thống quản lý định danh CardSpace,
OpenID, OAuth, bao gồm nội dung, giao thức, mô hình, phương pháp và giao thức
tích hợp OpenID với CardSpace, OAuth với CardSpace. Từ đó làm tiền đề cho việc
tìm hiểu, phân tích, đưa ra phương pháp tích hợp OpenID và OAuth mở rộng với thẻ
thông tin CardSpace ở Chương 3.
2.1 CardSpace
Cơ chế dựa trên mật khẩu vẫn có nhiều lỗ hổng đối với các kiểu tấn công khác
nhau. Chẳng hạn như bằng việc gửi các thông báo email đánh lừa, những kẻ tấn công
có thể đánh lừa người dùng đăng nhập vào các bản sao chép giả mạo của trang thực, từ
đó lấy mật khẩu và các thông tin cá nhân của chúng ta. Tuy nhiên nếu mật khẩu có cơ
chế thẩm định tốt trên web thì kiểu tấn công giả mạo này sẽ giảm mức độ nguy hiểm,
khi đó sẽ không có mật khẩu nào bị đánh cắp. Để thực hiện được điều này và cải thiện
tính bảo mật cho việc đăng nhập vào các trang web, CardSpace được Microsoft đưa ra
để cho phép bạn có thể thay thế đăng nhập web dựa trên mật khẩu với một cơ chế
mạnh hơn.
CardSpace là một phần của phần mềm khách mà cho phép người dùng cung cấp
nhận dạng số của họ tới các dịch vụ trực tuyến một cách đơn giản, an toàn, tin cậy và
được Microsoft tích hợp sẵn trong Windows Vista. Hình 2.1 minh họa cho giao diện
CardSpace.
Hình 2.1: Giao diện Windows CardSpace.
19
Windows CardSpace hỗ trợ hai loại thẻ:
Thẻ được quản lý (managed card): Thuộc tính của từng cá nhân được quản lý
bởi thành phần IdP. Thông tin của thẻ (Information Card - InfoCard) ở đây chỉ
cho biết có những loại thuộc tính nào cùng địa chỉ IdP tương ứng. Khi người
dùng cần những thuộc tính chi tiết, hệ thống sẽ sử dụng địa chỉ của IdP lưu
trong InfoCard để giao tiếp và lấy các thuộc tính định danh tương ứng.
Thẻ cá nhân (personal card): Thông tin được quản lý bởi người dùng, các
thuộc tính định danh sẽ được lưu trong thẻ. Trong trường hợp này, người dùng
có thể tự tạo những dữ liệu cần thiết để chứng thực mà không cần phải thông
qua IdP. Những thuộc tính của thẻ mà người dùng nhập thông tin được cung
cấp bởi nhà cung cấp tự phát hành (Self Issued Identity Provider - SIIP) và
cùng tồn tại với bộ chọn nhận dạng CardSpace (CardSpace Identity Selector)
trên máy người dùng.
Thẻ cá nhân
Identity Selector cho phép người dùng tạo ra khoảng 14 trường thông tin trên một
thẻ cá nhân. Tên của các trường thông tin đó là: First Name, Last Name, Email
Address, Stress, City, State, Postal Code, Country/Region, Home Phone, Other Phone,
Mobile Phone, Date Of Birth, Gender và Web Page. Dữ liệu chèn vào trong thẻ cá
nhân sẽ được mã hóa và lưu trữ trên máy của người dùng. Một ID và một khóa chính
của thẻ cũng được tạo và được lưu trữ bởi IS.
Để người dùng có thể sử dụng thẻ các nhân xác thực với một trang web RP thì
CardSpace đã đưa ra luồng giao thức tương tác giữa thẻ thông tin với trang web RP.
Chi tiết của luồng giao thức được minh họa trong Hì nh 2.2 và gồm các bước sau [8]:
1. UA → RP: Người dùng yêu cầu một trang đăng nhập từ RP
2. RP → UA: Một trang đăng nhập được RP trả lại. Trang đăng nhập này có
chứa những thẻ cho phép gọi CardSpace và những chính sách bảo mật của
RP cũng được nhúng vào trong trang đăng nhập.
3. Người dùng → UA: Trang đăng nhập của RP sẽ đưa ra gợi ý cho người dùng
lựa chọn CardSpace. Việc lựa chọn này sẽ kích hoạt Selector nếu như thõa
mãn được các chính sách của RP.
4. Selector → InfoCards: Sau khi kiểm tra, thẩm định các chính sách của RP thì
Selector sẽ hiển thị nổi bật những thẻ mà thỏa mãn với chính sách của RP.
5. Người dùng → Selector: Sau khi hiển thị những thẻ thõa mãn với chính sách
của RP thì người dùng sẽ lựa chọn thẻ cả nhân phù hợp nhất. Tuy nhiên,
người dùng có thể tạo và chọn một thẻ cá nhân mới. Người dùng có thể chỉnh
sửa những trường thông tin bên trong thẻ để sao cho thẻ thỏa mãn với chính
sách, yêu cầu của RP.
6. Selector ↔ SIIP: IS tạo và gửi một yêu cầu token bảo mật SAML (RST –
Request Security Token) tới SIIP. Khi SIIP nhận được yêu cầu thì sẽ trả lại
một RSTR (Request Security Token Response).
20
7. UA → RP: RSTR được gửi tới UA và sau đó UA sẽ chuyển RSTR tới RP.
8. RP → Người dùng : RP kiểm tra, thẩm định token. Nếu thỏa mãn các yêu cầu
của RP thì RP cho phép người dùng được quyền truy cập và ngược lại nếu
quá trình RP thẩm định và kiểm tra token bị lỗi thì người dùng không có
quyền truy cập.
User Agent
User chọn và
d
gửi một IDCard
RP (Repling Party)
HTTP yêu cầu trang login
ID Card
RP trả lại một trang đăng nhập
Highlight
Người dùng chọn CardSpace
IDcard
Yêu cầu SAML
Trả lại SAML
SIIP
Gửi SAML token (RSTR – request
security token response) tới RP
Phân tích
Xác minh
Từ chối hay cho phép người dùng
truy cập
Quyết đị nh
Selector
Hình 2.2: Giao thức tương tác giữa RP và thẻ thông tin CardSpace
Chi tiết luồng giao thức giữa RP và thẻ thông tin CardSpace được mình họa trong
Hình 2.1 và được giải thích qua các bước chính sau [8]:
Nhận dạng cá nhân riêng lẻ (Private Personal Identifiers - PPIDs)
PPIDs là một định danh liên kết một InfoCard cụ thể với một RP đặc biệt [9].
Với mỗi thẻ cá nhân được tạo ra trong CardSpace, một khóa chính (master key) và một
ID của thẻ được sinh ra và lưu trữ trong thẻ. Khóa chính là một dãy dữ liệu ngẫu nhiên
gồm 32 bytes, còn ID của thẻ là một dãy số ngẫu nhiên và dãy số này là khác nhau đối
với mỗi thẻ. Khi người dùng truy cập vào RP lần đầu tiên thì CardSpace sẽ sử dụng
những thuộc tính từ việc chứng thực RP (RP certificate) kết hợp với ID của thể để sinh
ra một PPID duy nhất. Nếu RP certificate không được sử dụng thì CardSpace sẽ sử
dụng tên miền trong URL của trang web RP kết hợp với ID của thẻ để sinh ra PPID.
CardSpace cũng sử dụng các thuộc tính của RP certificate cùng với khóa chính để sinh
21
ra một cặp khóa công khai và khóa riêng tư (public key/private key). Hình 2.3 mình
họa CardSpace tạo ra PPID và cặp khóa public/private.
Relying Party’s
Certificate
Card ID
Relying Party’s
Certificate
Khóa chính
PPID
Cặp khóa public/private
Hình 2.3: Cách thức tạo PPID và cặp khóa public/private
Vì PPID và cặp khóa public/private là duy nhất và được dùng để xác định
CardSpace, khi PPID và cặp khóa public/private này được sử dụng tại một RP cụ thể
thì RP có thể sử dụng chúng để xác định xem thẻ CardSpace được sử dụng.
Khi người dùng lần đầu tiên đăng ký với RP, RP sẽ nhận được PPID và khóa
công khai (public key) từ việc nhận mã thông báo bảo mật SAML (SAML security
token). Khi RP nhận được PPID và khóa công khai (public key) thì RP sẽ lưu trữ
những giá trị này lại để sau này thẻ cá nhân InfoCard được sử dụng lại tại trang RP,
lúc này mã bảo mật (security token) sẽ chứa PPID, public key và được ký bởi khóa
riêng tư (private key). RP sẽ phải so sánh những giá trị PPID và public key nhận được
với những giá trị đã được lưu trữ trước đó, đồng thời RP phải thẩm định, xác minh chữ
ký của mã bảo mật.
Mặc dù RP có thể sử dụng PPID để xác định người dùng, nhưng việc thêm một
kiểm tra vẫn phải được bổ sung để nâng cao tính bảo mật. Để nâng cao tính bảo mật
thì một mã thông báo SAML được sinh ra bởi CardSpace và được gửi tới RP, trong
SAML này có chứa public key, PPID. Giống như PPID, khóa công khai là duy nhất
trong quá trình tương tác giữa RP và InfoCard. Nhưng kẻ tấn công có thể lấy được
PPID và khóa công khai nhưng nó sẽ không có giá trị thật đối với những kẻ tấn công
này. Bời vì, token bảo mật đã được ký bởi khóa riêng tư nên những kẻ tấn công sẽ
không tạo ra được những token bảo mật như CardSpace tạo nếu như không có khóa
riêng tư này.
2.2 OpenID
Hiện nay, việc xác thực trong ứng dụng web là quá trình xác minh danh tính của
một ai đó và xác nhận người dùng truy cập vào ứng dụng thực sự là người dùng đã
thực hiện quá trình xác thực. Phương pháp phổ biến của xác thực là sử dụng tên đăng
nhập và mật khẩu. Trong đó, tên đăng nhập khai báo danh tính của người dùng đó và
mật khẩu được sử dụng để xác minh người dùng là chủ sở hữu của tên đăng nhập. Đại
đa số các trang web cần phải xác minh danh tính người dùng thông qua hình thức xác
thực tên đăng nhập và mật khẩu. Sự kết hợp của tên đăng nhập và mật khẩu dẫn đến sự
22
phân mảnh thông tin do người dùng có rất nhiều tên đăng nhập và mật khẩu trên rất
nhiều trang web khác nhau như: Google, Facebook, Yahoo, v.v. Dẫn đến, họ có thể bị
quên và khó quản lý được hết những tên đăng nhập và mật khẩu khác nhau này. Vì
vậy, OpenID được đề xuất nhằm mục đích khắc phục những vấn đề đang tồn tại này.
OpenID là một dịch vụ chia sẻ định danh cho phép người dùng đăng nhập vào
nhiều trang web khác nhau chỉ cần sử dụng một định danh số duy nhất. OpenID cung
cấp cho người dùng URI [10] duy nhất để đăng nhập vào những RP khác nhau.
Tháng 5/2005, Brad Fitzpatrick, người sáng lập trang web nổi tiếng LiveJournal,
đã phát triển giao thức xác thực OpenID đầu tiên khi đang làm việc tại Six Apart. Tính
đến tháng 12 năm 2009, OpenID đã được chấp nhận rộng rãi, với khoảng hơn một tỉ
tài khoản OpenID và xấp xỉ chín triệu trang web cho phép hỗ trợ người dùng sử dụng
OpenID. Ngoài ra, có nhiều trang web nổi tiếng đã xây dựng thành phần Identity
Provider như Google, Yahoo, Facebook, Microsoft. Điều này cho thấy, hệ thống
OpenID đã sử dụng rất phổ biến hiện nay.
Một hệ thống OpenID gồm ba thành phần là: Identity Provider, Relying Party, và
Identity Selector. Thành phần Identity Selector ở đây chính là Browser hay UA (User
Agent).
2.2.1 Giao thức OpenID
Hiện tại, có hai phiên bản OpenID được sử dụng là: OpenID 1.1 [11] và OpenID
2.0 [12]. Phiên bản OpenID 2.0 có tương thích ngược được với OpenID 1.1.
Trước khi bắt đầu tìm hiểu chi tiết giao thức OpenID, người dùng phải đăng ký
một OpenID với IdP. OpenID của người dùng ở đây là một URI.
Chi tiết giao thức OpenID được thể hiện trong Hình 2.4.
1. UA → RP: Người dùng dựa vào UA để yêu cầu RP một trang đăng nhập.
2. RP → UA: RP trả về một trang đăng nhập có chứa form đăng nhập OpenID.
3. Người dùng → UA: Người dùng nhập “OpenID identifier” của họ vào form
OpenID ở trang đăng nhập.
4. RP: RP khám phá địa chỉ IdP. RP sử dụng “OpenID identifier” do người
dùng cung cấp để khám phá ra địa chỉ IdP.
1. Khám phá địa chỉ IdP dựa vào HTML: RP yêu cầu một tài liệu được xác
định bởi một URL OpenID của người dùng. Tài liệu này có chứa thông tin
cần thiết để khám phá ra địa chỉ của IdP.
2. Khám phá địa chỉ IdP dựa vào XRSD: RP yêu cầu một tài liệu XRSD có
chứa thông tin cần thiết để khám phá ra địa chỉ của IdP. Nếu “OpenID
identifier” của người dùng là một XRI thì RP s ẽ lấy một tài liệu XRSD
được xác định bởi XRI do người dùng cung cấp. Nếu “OpenID identifier”
là URL thì RP s ử dụng giao thức Yadis để lấy tài liệu XRSD. Nếu có lỗi
xẩy ra thì RP sẽ trở lại với phương pháp khám phá IdP dựa trên HTML.
- Xem thêm -