Tích hợp OpenID và OAuth mở rộng với thẻ thông tin CardSpace

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.. Tuy nhiên, do người dùng sử dụng nhiều hệ th

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

Danh mục các ký hiệu, các chữ viết tắt

HTTPS Hypertext Transfer Protocol Secure

Open Authentication Open Authentication

XHTML Extensible HyperText Markup Language

XRDS Extensible Resource Descriptor Sequence

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

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:

 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

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

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

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

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)

(IdP) Bộ chọn lọc (IS)

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

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

http://login.me.zing.vn/ https://login.yahoo.com/

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

 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

 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

 Khả năng phòng tránh lỗi

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

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

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

Ư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

 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

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

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)

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

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

Người dùng chọn CardSpace

HTTP yêu cầu trang login

RP (Repling Party)

User Agent

RP trả lại một trang đăng nhập

User chọn và

gửi một IDCard

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

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ự

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)

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

Hình 2.4: Giao thức OpenID

5 RP ↔ IdP: Bước này là tùy chọn Tại bước này, RP và IdP đồng ý chia sẻ với nhau một khóa bí mật Khóa này được sử dụng cho một chuỗi các yêu cầu và phản hồi qua lại giữa RP và IdP Quá trình chia sẻ khóa bí mật này sẽ trong suốt với người dùng

6 RP và IdP tương tác với nhau: RP và IdP có thể giao tiếp với nhau theo 2 cách thức sau: checkid_immediate và checkid_setup Với cách thức checkid_immediate thì RP và IdP giao tiếp với nhau mà không có sự tương tác của người dùng Còn với cách thức checkid_setup thì RP và IdP giao tiếp với nhau mà có sự tương tác của người dùng Nếu checkid_immediate được

sử dụng thì RP sẽ gửi một yêu cầu xác thực OpenID tới IdP và IdP gửi lại kết quả của yêu cầu xác thực này và bước 9 được thực hiện Nếu checkid_setup được sử dụng thì RP sẽ chuyển hướng người dùng tới IdP theo một yêu cầu xác thực OpenID (OpenID authentication request) và bước 7 sẽ thực hiện tiếp theo của giao thức OpenID

7 IdP ↔ Người dùng: Nếu cần thiết thì IdP xác thực người dùng Nếu thành công thì IdP gửi một “OpenID assertion token”, token này bao gồm các thuộc

HTTP yêu cầu trang login

RP trả lại trang đăng nhập Người dùng nhập vào OpenID

Xác định địa chỉ IdP thông qua OpenID của người dùng

RP và IdP chia sẻ khóa bí

mật IdP yêu cầu xác thực người dùng

IdP yêu cầu xác thực người dùng

Kiểm tra giá trị

RP cho phép user truy cập IdP gửi giá trị của yêu cầu xác thực Open ID

tính, thông tin của người dùng, một nonce, một timestamp, một MAC của máy tính Nếu một khóa bí mật được chia sẻ ở bước 5 thì IdP sẽ sử dụng khóa này để sinh ra MAC, nếu không có một khóa được chia sẻ ở bước 5 thì IdP sẽ dùng một khóa riêng để sinh ra MAC

8 IdP → UA → RP: IdP chuyển hướng người dùng quay lại RP với kết quả tùy thuộc vào sự cho phép hay không cho phép người dùng ở bước 7

9 RP → Người dùng: RP thẩm định MAC trong kết quả trả lại xác thực OpenID (OpenID authentication response) của IdP Nếu hợp lệ thì RP cho phép người dùng truy cập Các tham số trong quá trình thẩm định, kiểm tra, xác minh là: nonce, timestamp, MAC Việc xác minh tham số nonce không được tìm thấy trong phiên bản OpenID 1.1 RP sử dụng tham số timestamp

để loại bỏ những phản hồi quá cũ Do đó hạn chế được thời gian nhận một kết quả phản hồi Nếu một khóa bí mật được chia sẻ tại bước 5 thì RP sẽ sử dụng khóa này để xác minh MAC Nếu một khóa bí mật mà không được chia

sẻ tại bước 5 thì RP phải gửi một yêu cầu tới IdP để nhờ IdP kiểm tra MAC Thông thường, việc kiểm tra này được thực hiện thông qua kênh truyền có TLS/SSL Quá trình yêu cầu - đáp ứng (request – response) được biết đến như một cơ chế kiểm tra xác thực và được chấp nhận trong quá trình tích hợp chương trình

Từ giao thức OpenID ở trên thì q uy trình định danh của hệ thống OpenID có thể chia ra làm 3 quy trình con sau:

 Quy trình xác định thành phần Identity Provider

 Quy trình gửi thuộc tính định danh

 Quy trình kiểm tra thuộc tính định danh

Phần tiếp theo sẽ trình bày chi tiết ba quy trình này

2.2.1.1 Quy trình xác định thành phần Identity Provider

Hình 2.5: Các bước trong quy trình xác định thành phần Identity Provider

Quy trình xác định thành phần Identity Provider gồm 3 bước được minh họa trong Hình 2.5

 Bước 1.1: Người dùng sẽ nhập địa chỉ URL của Relying Party vào trình duyệt

 Bước 1.2: Dựa vào ULR người dùng nhập vào , trình duyệt (Browser) sẽ giao tiếp với thành phần Relying Party

 Bước 1.3: Relying Party sẽ trả về trình duyệt một trang đăng nhập có hỗ trợ OpenID trong đó có textbox yêu cầu người dùng nhập vào URI của Identity Provider

 Bước 1.4: Trình duyệt hiển thị trang đăng nhập cho người dùng

 Bước 1.4: Người dùng sẽ điền URI của Identity Provider vào trình duyệt Sau khi điền vào URI, người dùng nhấn nút “Đăng nhập”

 Bước 1.5: Trình duyệt sẽ chuyển thông tin về URI người dùng nhập vào đến Relying Party Relying Party sẽ lấy thông tin về URI người dùng nhập vào để xác định được thành phần Identity Provider tương ứng URI người dùng nhập vào sẽ có hai loại:

 Loại 1: URI đó chính l địa chỉ của Identity Provider Trong trường hợp này, Relying Party đã có được địa chỉ của Identity Provider chính là URI người dùng nhập cung cấp

 Loại 2: URI này không phải là địa chỉ của Identity Provider Trong trường hợp này, thành phần Relying Party phải dùng Yadis để lấy địa chỉ của Identity Provider Dịch vụ Yadis có vai trò nhận vào một URI và sẽ trả về địa chỉ và thông tin về Identity Provider tương ứng Quá trình xác định địa chỉ Identity Proivder dựa trên Yadis được minh họa trong Hình 2.6

Hình 2.6 Sử dụng Yadis để xác định địa chỉ của Identity Provider

2.2.1.2 Quy trình gửi thuộc tính định danh

Quy trình gửi thuộc tính định danh lên Relying Party gồm 10 bước trong Hình 2.7:

 Bước 2.1: Relying Party sau khi xác định được thành phần Identity Provider ở quy trình xác định thành phần Identity Provider (xem phần 2.2.1.1) Bước 2.1

là bước tùy chọn bao gồm hai trường hợp xảy ra như sau:

 Trường hợp 1: Relying Party và Identity Provider chưa có khóa chia sẻ bí mật ở những lần định danh trước đây, hoặc khóa chia sẻ bí mật đã hết thời gian sử dụng Trong trường hợp này, Relying Party sẽ kết nối bằng một kênh truyền an toàn với Identity Provider để chia sẻ khóa bí mật Khóa bí mật sẽ được sử dụng để kiểm tra các thuộc tính định danh ở quy trình kiểm tra thuộc tính định danh sau này ở bước 3.1 hay những lần định danh sau

đó

 Trường hợp 2: Nếu thành phần Relying Party đã có được khóa bí mật chưa hết thời gian sử dụng ở các lần thực hiện định danh trước đây thì không cần phải thực hiện bước này Vì vậy, bước 2.1 là bước tùy chọn

Hình 2.7: Các bước trong quy trình gửi thuộc tính định danh

 Bước 2.2: Relying Party gửi danh sách tên các thuộc tính yêu cầu Identity Provider cung cấp để chứng thực

 Bước 2.3: Identity Provider sẽ yêu cầu người dùng đăng nhập bằng cách trả về trình duyệt trang đăng nhập

 Bước 2.4: Trình duyệt sẽ hiện thị trang đăng nhập đến người dùng

 Bước 2.5: Người dùng sẽ đăng nhập vào Identity Provider (ví dụ, người dùng

sẽ nhập vào tên đăng nhập và mật khẩu để đăng nhập) Sau đó, người dùng sẽ nhấn nút “đăng nhập”

 Bước 2.6: Trình duyệt sẽ chuyển thông tin đăng nhập người dùng đến Identity Provider để kiểm tra

 Bước 2.7: Identity Provider sẽ kiểm tra thông tin đăng nhập Sau đó, Identity Provider sẽ dựa trên danh sách tên các thuộc tính yêu cầu từ Relying Party; Identity Provider sẽ tạo một thông điệp có chứa các thuộc tính tương ứng Cuối cùng, Identity Provider sẽ ký trên danh sách các thuộc tính định danh và trả về trình duyệt

 Bước 2.8: Trình duyệt sẽ hiện lên tất cả thuộc tính định danh nhận được từ Identity Provider cho người dùng

 Bước 2.9: Người dùng sẽ kiểm tra các thuộc tính định danh có hợp lệ Sau đó, người dùng sẽ xác nhận truyền các thuộc tính định danh

 Bước 2.10: Trình duyệt sẽ truyền các thông tin định danh của người dùng đến Relying Party

2.2.1.3 Quy trình kiểm tra thuộc tính định danh

Hình 2.8: Các bước trong quy trình kiểm tra thuộc tính định danh

Quy trình gửi thuộc tính định danh lên Relying Party gồm 3 bước được minh họa trong Hình 2.8

 Bước 3.1: Dựa trên thuộc tính định danh nhận được từ thành phần Identity Provider ở quy trình gởi thuộc tính định danh (xem phần 2.2.1.2) cùng với khóa chia sẻ bí mật được tạo ra ở bước 2.1 Relying Party sẽ kiểm tra xem thuộc tính định danh có hợp lệ hay không

 Bước 3.2: Relying Party trả về kết quả định danh về trình duyệt

 Bước 3.3: Trình duyệt sẽ hiển thị kết quả định danh đến người dùng

2.2.2 Tích hợp OpenID với CardSpace

Trước khi đi vào chi tiết của giao thức tích hợp OpenID với CardSpace thì cần thực hiện một số yêu cầu sau:

 Người dùng phải có mối quan hệ với cả RP và IdP RP phải tin tưởng vào việc xác thực người dùng của IdP

 Trước khi hoặc trong khi sử dụng giao thức, người dùng phải tạo một thẻ cá nhân CardSpace, thẻ này được xem như một IDCard IDCard này phải có các trường để chứa thông tin về người dùng Người dùng cũng phải đăng ký một nhận dạng OpenID (OpenID identifier) của riêng mình “OpenID identifier” này là một chuỗi ký tự được sử dụng để xác định phiên bản OpenID và địa chỉ URL của IdP

 RP mà cho phép, hỗ trợ CardSpace sẽ không sử dụng một STS Thay vào đó,

RP phải thể hiện chính sách bảo mật bằng cách sử dụng HTML/XHTML và tương tác giữa Selector và RP phải dựa trên HTTP/S thông qua trình duyệt Bời vì, chương trình tích hợp sử dụng một trình duyệt mở rộng (browser extension) và do đó không có khả năng quản lý những thông tin liên lạc cần thiết với STS

Từ giao thức OpenID ở mục 2.2.1 thì việc tích hợp giữa OpenID và CardSpace được thể hiện trong Hình 2.9 [13]

Hình 2.9: Giao thức tích hợp giữa OpenID và CardSpace

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 trường, chính sách bảo mật của RP cũng được nhúng vào trong trang đăng nhập của RP trả về

3 Extension → UA: Chương trình tích hợp sẽ thực hiện các bước sau:

1 Extension kiểm tra trang đăng nhập mà RP trả về cho UA để phát hiện xem RP có hỗ trợ CardSpace hay không Nếu RP có hỗ trợ thì chương trình tiếp tục xử lý còn nếu RP không hỗ trợ thì chương trình sẽ dừng lại

2 Extension xem xét chính sách của RP để kiểm tra xem việc sử dụng thẻ

cá nhân có được chấp nhận hay không Nếu có thì tiếp tục xử lý và nếu không thì cho CardSpace hoạt động bình thường

3 Extension giữ lại các trường và những khai báo mà RP yêu cầu

Chuyển OpenID auth request tới IdP

OpenID auth response

SIIP

Plug-in: Khởi tạo SAML token (RSTR + thuộc tính user) Cho phép /từ chối user truy cập

Phân tích Thẩm định Quyết định

Plug-in: Bắt SAML và khởi tạo một OpenID auth request

HTTP yêu cầu trang đăng nhập

RP trả lại trang đăng nhập (policy của

RP được nhúng vào trang đăng nhập) Plug-in xử lý và ngăn

chặn một SAML token User gọi CardSpace

Yêu cầu SAML

Ủy quyền

4 Extension chỉnh sửa chính sách của RP bao gồm kiểu của các trường được sử dụng trong IDCard Ví dụ: nếu “OpenID identifier” của người dùng được lưu trữ trong trường “web page” của IDCard, thì sau đó Extension phải đảm bảo rằng chính sách bảo mật của RP sẽ có trường

“web page” Chú ý rằng việc thêm kiểu trường này vào chính sách RP để đảm bảo rằng token được cung cấp bởi SIIP có chứa những giá trị của những trường này mà có thể được xử lý bởi Extension

5 Extension khám phá ra giao thức mà RP sử dụng để giao tiếp là HTTP hoặc HTTPS

4 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

5 Selector → InfoCards: Sau khi kiểm tra và 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

6 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 một 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ẻ được tạo ra thỏa mãn với những chính sách và yêu cầu của RP

7 Selector ↔ SIIP: IS sẽ tạo và gửi một yêu cầu token bảo mật SAML ( Request Security Token - RST) tới SIIP Khi SIIP nhận được yêu cầu thì sẽ trả lại một RSTR (Request Security Token Response)

8 Selector → Extension/UA: Sau khi người sử dụng lựa chọn và gửi một OAuthCard phù hợp, thì không giống như trường hợp chuẩn, RSTR sẽ không được gửi tới RP ngay, thay vào đó Extension sẽ chặn RSTR và tạm thời lưu trữ RSTR lại

1 Nếu RP sử dụng HTTP, Extension sẽ sử dụng nội dung của RSTR để khởi tạo và xây dựng một yêu cầu xác thực OpenID (OpenID authentication request), yêu cầu này sẽ được Extension chuyển tới địa chỉ của IdP (địa chỉ của IdP được xác định từ nội dung của RSTR.)

2 Nếu RP sử dụng HTTPS, Extension sẽ hỏi và yêu cầu người dùng nhập vào “OpenID identifier” của họ Sau khi, người dùng cung cấp OpenID của họ thì Extension sẽ khởi tạo và xây dựng một yêu cầu xác thực OpenID, sau đó Extension sẽ chuyển yêu cầu này tới địa chỉ IdP (địa chỉ của IdP được xác định dựa trên OpenID mà người dùng cung cấp)

9 IdP → Người dùng: Nếu cần thiết IdP xác thực người dùng Nếu xác thực không thành công thì chương trình sẽ kết thúc Nếu thành công thì IdP yêu cầu người dùng quyền để IdP gửi “OpenID assertion token” tới trang RP