Tài liệu Tích hợp openid và oauth mở rộng với thẻ thông tin cardspace

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.