Tích hợp OpenID và OAuth mở rộng với thẻ thông tin CardSpace : Luận văn ThS. Công nghệ thông tin: 60 48 10

3 MỤC LỤC Danh mục các ký hiệu, các chữ viết tắt Danh mục các hì nh vẽ GIỚI THIỆU Chương 1: TỔNG QUAN VỀ HỆ THỐNG QUẢN LÝ ĐỊNH DANH 1.1 Định danh số 1.2 Hệ thống quản lý định danh 1.2.1 Các thành phần hệ thống quản lý định danh 10 1.2.2 Quy trình hoạt động hệ thống định danh 12 1.3 Các vấn đề 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 phân tích 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 OAuth mở rộng 39 3.2 Giao thức OpenID 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 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 bảo mật 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 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 Danh mục các hì nh vẽ Hình 1.1: Các thành phần hệ thống định danh 10 Hình 1.2: Một số ví dụ thành phần Relying Party 11 Hình 1.3: Thành phần bợ chọn lọc (Identity Selector) CardSpace 11 Hình 1.4: Các bước quy trình hoạt động 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 RP thẻ thơng tin CardSpace .20 Hình 2.3: Cách thức tạo PPID cặp khóa public/private 21 Hình 2.4: Giao thức OpenID 23 Hình 2.5: Các bước 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 Identity Provider 25 Hình 2.7: Các bước quy trình gửi thuộc tính định danh 26 Hình 2.8: Các bước quy trình kiểm tra thuộc tính định danh 27 Hình 2.9: Giao thức tích hợp OpenID CardSpace 28 Hình 2.10: Giao thức OAuth 32 Hình 2.11: Giao thức tích hợp OAuth CardSpace 36 Hình 3.1: Giao thức tích hợp OpenID 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 người dùng lựa chọn CardSpace để đăng nhập 48 Hình 4.4: Đoạn mã javascript thực việc gọi CardSpace Microsoft 49 Hình 4.5: Người dùng lựa chọn CardSpace giao diện IS .50 Hình 4.6: Yêu cầu xác thực OpenID 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 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 truy cập vào hệ thống phải thực trình định danh để xác định tính hợp lệ người dùng Hiện nay, số chế định danh sử dụng phổ biến như: tên đăng nhập mật khẩu, nhận dạng khuôn mặt, vân tay Tuy nhiên, người dùng sử dụng nhiều hệ thống mà hệ thống lại có chế thực định danh khác nên người dùng cảm thấy khó khăn việc nhớ quản lý thuộc tính định danh mình, từ người dùng dễ bị lộ định danh hệ thống khác Chẳng hạn người dùng sử dụng nhầm lẫn thuộc tính định danh đăng nhập vào trang giả mạo dẫn đến để lộ thông tin tên đăng nhập mật Vì vậy, hệ thống quản lý định danh đời để giúp quản lý thuộc tính định danh người dùng, từ đảm bảo tính an tồn tiện dụng người dùng thực trình định danh Nhằm nỗ lực cho việc quản lý định danh tốt số hệ thống quản lý định danh tiếng đề xuất như: CardSpace, OpenID, OAuth, v.v Trong đó, CardSpace hệ thống hoàn chỉnh Microsoft xây dựng hoạt động máy có hệ điều hành Windows Mặc dù, hệ thống quản lý định danh có danh sách thành phần, cách hoạt động, cách giao tiếp khác nhau, hệ thống quản lý định danh thơng thường có thành phần:  Bên tin cậy (Relying Party - RP): Là dịch vụ sử dụng chế định danh để chứng thực  Nhà cung cấp định danh (Identity Provider - IdP): Là nơi lưu trữ quản lý thuộc tính định danh  Bộ chọn định danh (Identity Selector – IS): Là thành phần trung gian hệ thống, cầu nối người dùng, Relying Party Identity Provider Trong thực tế, RP hỗ trợ đăng nhập thẻ thông tin CardSpace nhà cung cấp dịch vụ IdP hỗ trợ OpenID, OAuth hệ thống hoạt động độc lập với Từ thực trạng trên, việc xây dựng hệ thống có tính sẵn sàng cao nhóm người dùng rộng lớn khả tương tác hệ thống quản lý định danh độc lập việc cần thiết Do đó, luận văn tập trung vào một số nội dung sau:  Tìm hiểu mối quan hệ RP hỗ trợ thẻ tin CardSpace với nhà cung cấp định danh hỗ trợ OpenID, OAuth User Agent (UA – thường trình duyệt web) hỗ trợ việc gọi thẻ thông tin CardSpace  Đề xuất mô hình phương pháp tích hợp OpenID OAuth mở rộng hỗ trợ RP IdP với hệ thống thẻ thông tin CardSpace  Xây dựng chương trình họa cho mơ hình phương pháp tích hợp OpenID OAuth mở rộng với thẻ thông tin CardSpace Nội dung luận văn trình bày gồm:  Chương 1: Tổng quan hệ thống quản lý định danh trình bày chi tiết hệ thống quản lý định danh, bao gồm nguyên tắc, mô hình hoạt động chung, số hệ thống quản lý định danh nay, số vấn đề xây dựng hệ thống quản lý định danh  Chương 2: Tổng quan CardSpace, OpenID OAuth trình bày chi tiết 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 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 phương pháp tích hợp OpenID OAuth mở rộng với CardSpace Chương  Chương 3: Tích hợp OpenID 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 OAuth mở rộng, phân tích ưu điểm OpenID OAuth mở rộng so với OpenID, OAuth Từ đưa mơ hình phương pháp tích hợp OpenID 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 phần thực nghiệm cho mơ hình, phương pháp mà luận văn đã đề xuất ở Chương  Kết luận trình bày kết mà luận văn đạt hướng phát triển luận văn tương lai Chương TỔNG QUAN VỀ HỆ THỐNG QUẢN LÝ ĐỊNH DANH Chương trình bày chi tiết hệ thống quản lý định danh, bao gồm ngun tắc, mơ hình hoạt động chung, số hệ thống quản lý định danh nay, số vấn đề xây dựng hệ thống quản lý định danh 1.1 Định danh số Hiện nay, học viên tham gia khóa học thạc sĩ trường đại học cấp thẻ học viên thẻ học viên có chứa tập thuộc tính như: mã số học viên, họ tên, khoa, trường Từ đó, nhà trường sử dụng thẻ học viên vật thể định danh để xác định học viên Vì vậy, Định danh (identity) tập thuộc tính để mơ tả người, vật nhóm [1] Thơng thường, thuộc tính định danh chứa vật thể định danh vật thể định danh sử dụng cho mục đích định Chẳng hạn, thẻ học viên học viên sử dụng phạm vi trường đại học Tuy nhiên, có vật thể định danh sử dụng cho nhiều ngữ cảnh khác Ví dụ: thẻ chứng minh nhân dân sử dụng cho học viên Trường Đại học Công Nghệ thi cuối môn, để xác định quyền cơng dân học viên Từ định nghĩa định danh, có khái niệm định danh số: Định danh số (digital identity) định danh số hóa để lưu trữ thiết bị điện tử Trong thực tế, có nhiều thuộc tính mơ tả định danh cụ thể thuộc tính tổ chức cách liên hợp, phân tán nhiều kho lưu trữ liệu khác [2] Có nghĩa là, thuộc tính để định danh chủ thể chia thành nhiều phần, phần lưu trữ nhiều nơi khác Trước đây, rút tiền ngân hàng, người dùng 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 kiểm tra thủ cơng thuộc tính chứng minh nhân dân chữ ký xem có khớp với thơng tin đăng ký trước Nếu tất thuộc tính khớp, nhân viên ngân hàng tiến hành cho người dùng rút tiền Ngày nay, người dùng cần thẻ ATM mật thẻ rút tiền từ ngân hàng Khi người dùng sử dụng thẻ ATM nhân viên ngân hàng kiểm tra thông tin cách thủ cơng trước Từ ví dụ minh họa trên, thấy việc áp dụng định danh số vào q trình định danh làm nâng cao tính tiện dụng cho người dùng Ngồi ra, q trình định danh ví dụ thực kết hợp hai tập thuộc tính định danh: tập thơng tin chứng minh nhân dân thông tin chữ ký trước đây, hay tập thông tin thẻ ATM thông tin mật Hơn nữa, tập thuộc tính định danh đặt nhiều nơi khác Sự kết hợp làm cho q trình định danh an tồn Tương tự định danh giới thực, định danh số giới world wide web sử dụng chung thuộc tính định danh cho hệ thống khác Chẳng hạn, người dùng sử dụng chung tên đăng nhập mật cho hai hệ thống khác Google Talk GMail thông qua chế đăng nhập lần (Single Sign On – SSO) [3] Trong lĩnh vực khoa học máy tính, tất liệu lưu trữ dạng bit Vì vậy, thuật ngữ định danh định danh số xem Trong phạm vi luận văn này, thuật ngữ định danh sử dụng thay cho thuật ngữ định danh số Hiện có nhiều thuộc tính sử dụng để thực trình định danh Để tiện quản lý trình định danh, người ta tiến hành phân loại thuộc tính định danh Các thuộc tính định danh phân làm hai loại là: Thuộc tính nhận dạng thuộc tính thơng tin [1] Trong đó:  Thuộc tính nhận dạng: thuộc tính mơ tả thơng tin mà có chủ thể định danh sở hữu Nói cách khác, thuộc tính nhận dạng dùng để phân biệt thành phần định danh khác Ví dụ, ta dùng thuộc tính dấu vân tay, khuôn mặt để phân biệt đối tượng định danh  Thuộc tính thơng tin: thuộc tính mơ tả chung đối tượng Thuộc tính chung mơ tả thơng tin đối tượng Thuộc tính thơng tin ổn định, khơng thay đổi giới tính, họ tên, q qn, ngày sinh Những thuộc tính hay biến động, thay đổi 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 nhiều trang web, ứng dụng khác như: Facebook, Twitter, Yahoo, Google Đại đa số 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 mật Sự kết hợp tên đăng nhập mật dẫn đến phân mảnh thông tin người dùng có nhiều tên đăng nhập mật nhiều trang web khác Để giảm số lượng mật phải nhớ, người dùng có xu hướng sử dụng chung tên đăng nhập mật cho nhiều tài khoản khác Điều dẫn đến vấn đề dễ bị lộ mật hệ thống Ví dụ, kẻ cơng tạo trang web giả dụ người dùng đăng nhập Nếu người dùng sử dụng chung tên đăng nhập mật thơng tin người dùng bị lộ Để giải vấn đề này, cần phải có hệ thống quản lý thuộc tính định danh người dùng, hệ thống quản lý định danh Hệ thống quản lý định danh (Digital Identity Management System) hệ thống dùng để quản lý thuộc tính định danh người dùng [1] Ngày nay, có nhiều hệ thống quản lý định danh; hệ thống lại có giao thức, định dạng trao đổi thơng tin cách sử dụng khác [4] Vì vậy, nhu cầu cần có hệ thống quản lý tất hệ thống quản lý định danh người dùng, 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 hệ thống mô tả công nghệ, tiêu chuẩn trường hợp sử dụng dùng để giúp định danh sử dụng xuyên suốt nhiều hệ thống khác [2] Các hệ thống tiêu chuẩn hệ thống quản lý định danh liên hợp giúp cho hệ thống định danh dễ dàng giao tiếp với nhau, mà hỗ trợ cho hệ thống định danh sau 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 hệ thống quản lý định danh Các hệ thống quản lý định danh đa dạng phong phú Mỗi hệ thống có cách hoạt động, cách giao tiếp, danh sách thành phần khác Tuy nhiên, hệ thống quản lý định danh thông thường có thành phần:  Bên tin cậy (Relying Party - RP): dịch vụ sử dụng chế định danh để chứng thực  Nhà cung cấp dịch vụ (Identity Provider - IdP): nơi lưu trữ quản lý thuộc tính định danh  Bộ chọn lọc (Identity Selector – IS): thành phần trung gian hệ thống, cầu nối người dùng, Relying Party, Identity Provider Hình 1.1 minh họa trình giao tiếp thành phần với 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 hệ thống định danh  Bên tin cậy (Relying Party - RP) RP dịch vụ sử dụng chế định danh để chứng thực [5] Ví dụ, số trang web sử dụng chế đăng nhập người dùng để định danh trang Zing, Yahoo Hình 1.2 minh họa trình định danh sử dụng tên đăng nhập mật với hình bên trái trang đăng nhập Zing hình bên phải trang đăng nhập Yahoo Hiện có nhiều thành phần RP mạng nhiều RP hỗ trợ định danh tài khoản hệ thống khác tài khoản email Yahoo hay Gmail (trong ví dụ Hình 1.2 trang Zing Yahoo) Đây tảng hệ thống OpenID OAuth sử dụng luận văn  Nhà cung cấp định danh (Identity Provider – IdP) 11 IdP thành phần có nhiệm vụ quản lý thuộc tính định danh người dùng hệ thống IdP có chức truyền thông tin cần thiết để thực chứng thực đến RP sau xác định người dùng sử dụng dịch vụ [5] Hiện có nhiều hệ thống tiếng xây dựng thành phần IdP cho riêng dựa chế hệ thống OpenID, OAuth Google, Yahoo http://login.me.zing.vn/ https://login.yahoo.com/ Hình 1.2: Một số ví dụ thành phần Relying Party  Bộ chọn lọc (Identity Selector – IS) IS thành phần trung gian hệ thống, cầu nối người dùng, RP IdP Mọi hoạt động IS điều khiển trực tiếp người dùng [5] Thành phần IS tiếng CardSpace được tích hợp sẵn 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) CardSpace 12 1.2.2 Quy trình hoạt động hệ thống định danh Hình 1.4: Các bước quy trình hoạt động hệ thống quản lý định danh Quy trình hệ thống quản lý định danh minh họa Hình 1.4 bao gồm bước sau để thực trình chứng thực:  Bước 1: Người dùng cung cấp thông tin IdP cho thành phần IS  Bước 2: Thành phần IS tự động giao tiếp với thành phần RP Sau đó, IS truyền thông tin IdP người dùng cung cấp bước đến thành phần RP  Bước 3: Thành phần RP 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 kênh truyền an tồn) Sau đó, RP gửi danh sách tên thuộc tính cần thiết để thực định danh đến thành phần IdP thông qua kênh truyền an toàn thiết lập  Bước 4: Thành phần IdP tạo thuộc tính cần định danh mà thành phần RP yêu cầu bước Sau đó, IdP ký xác nhận thơng tin tạo chữ ký Cuối cùng, IdP truyền thông điệp ký IS  Bước 5: IS lên thông tin định danh tương ứng Sau đó, người dùng kiểm tra thơng tin xác nhận có truyền thuộc tính định danh đến RP hay khơng  Bước 6: Các thuộc tính định danh truyền đến RP người dùng xác nhận bước  Bước 7: RP kiểm tra thuộc tính định danh trả kết cho người dùng 1.3 Các vấn đề việc xây dựng hệ thống định danh Trong việc xây dựng hệ thống quản lý định danh, cần có tính chất làm tiêu chí để đánh giá chất lượng hệ thống Các tính chất bao gồm:  Tính riêng tư: Đảm bảo an toàn cho thuộc tính định danh 43 RP User Agent Plug-in Selector (CardSpace - enable IdP HTTP yêu cầu trang đăng nhập User gọi Gửi IDcard RP trả lại trang đăng nhập (policy của RP được nhúng vào trang đăng nhập) Highlight ID Card Yêu cầu SAML Plug-in xử lý ngăn chặn SAML token User gọi CardSpace Plug-in: Bắt SAML nhúng OAuth approval vào OpenID auth request SAML phản hồi Phân tích Chuyển OpenID auth request tới IdP Auth user OpenID auth response chứa access token Ủy quyền Plug-in: Nhận thuộc tí nh user bằng cách sử dụng access token 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 Hình 3.1: Giao thức tích hợp OpenID OAuth mở rộng với CardSpace Selector ↔ SIIP: Selector tạo gửi yêu cầu token bảo mật SAML (RST - Request Security Token) tới SIIP Khi SIIP nhận yêu cầu trả lại RSTR (Request Security Token Response) Selector → Extension/UA: Sau người sử dụng lựa chọn gửi OpenIDOAuthCard phù hợp, khơng giống trường hợp chuẩn, RSTR không gửi tới RP ngay, thay vào Extension chặn RSTR tạm thời lưu trữ RSTR lại Nếu RP sử dụng HTTP: Extension sử dụng nội dung RSTR để khởi tạo xây dựng yêu cầu xác thực OpenID, yêu cầu Extension chuyển tiếp tới IdP phù hợp (địa IdP khám phá xác định từ RSTR) Yêu cầu xác thực OpenID có nhúng thêm yêu cầu chấp nhận OAuth 44 Nếu RP sử dụng HTTPS: Đầu tiên, Extension hỏi người dùng xem có muốn sử dụng giao thức tích hợp hay khơng Nếu người dùng khơng muốn sử dụng Extension dừng chương trình lại cho phép CardSpace hoạt động bình thường Nếu người dùng muốn sử dụng giao thức tích hợp Extension hướng dẫn người dùng nhập vào URI IdP Sau người dùng nhập URI IdP Extension khởi tạo xây dựng yêu cầu xác thực OpenID, yêu cầu Extension chuyển hướng tới IdP (địa IdP xác định dựa vào URI mà người dùng cung cấp) Yêu cầu OpenID có nhúng thêm yêu cầu chấp nhận OAuth IdP → Người dùng: IdP xác thực người dùng Nếu xác thực khơng thành cơng chương trình kết thúc Nếu IdP xác thực người dùng thành cơng đưa gợi ý cho người dùng việc ủy quyền cho RP lấy truy cập vào liệu người dùng IdP Nếu người dùng đồng ý IdP gửi thẻ yêu cầu cho RP 10 RP ↔ IdP: RP sử dụng thẻ yêu cầu người dùng ủy quyền để trao đổi lấy thẻ truy cập với IdP Quá trình trao đổi giống với trình trao đổi OAuth chuẩn RP sử dụng giá trị để tạo yêu cầu thẻ truy cập:  consumer key: RP sử dụng chung “consumer key” với IdP  consumer secret: RP sử dụng chung “consumer secret” với IdP  oauth token: RP sử dụng “request token” bước trước  oauth token secret: RP sử dụng chuỗi trống  IdP thẩm định lại giá trị mà RP gửi Nếu thỏa mãn IdP gửi “access token” cho RP 11 Extension/UA → RP: Sau khơi phục giá trị thuộc tính u cầu người sử dụng từ IdP, Extension xây dựng mã thơng báo SAML giống CardSpace gửi tới RP Một mã thông báo bao gồm thuộc tính người dùng mà cung cấp IdP chữ ký số RSTR SIIP phát (có chứa PPID) 12 RP → Người dùng: RP xác minh SAML token (bao gồm xác minh chữ ký RSTR, PPID, nonce, timestamp, …) Nếu thỏa mãn RP cho phép người dùng truy cập Dựa nội dung giao thức OpenID, OAuth, OpenID OAuth mở rộng mà luận văn tìm hiểu việc sử dụng OpenID OAuth mở rộng tích hợp với thẻ thơng tin CardSpace có ưu điểm so với sử dụng OpenID OAuth sau: Những ưu điểm việc sử dụng OpenID OAuth mở rộng với OAuth  OAuth sử dụng chế ba bước gồm: Bước RP lấy thẻ yêu cầu (request token) từ IdP, bước xác thực xin quyền truy cập người dùng cho thẻ 45 yêu cầu, bước RP dùng thẻ yêu cầu để trao đổi thẻ truy cập (access token) từ IdP, có thẻ truy cập RP truy cập vào dữ liệu người dùng Trong đó, OpenID OAuth mở rộng sử dụng với hai bước sau: Bước RP lấy thẻ yêu cầu mà có ủy quyền người dùng từ IdP, bước 2, RP dùng thẻ yêu cầu để trao lấy thẻ truy cập từ IdP  Giảm tương tác giữa RP IdP : Trong OAuth, để RP lấy liệu người dùng từ IdP phải trải qua ba bước Còn sử dụng OAuth OpenID mở rộng, cần trải qua bước RP lấy liệu người dùng IdP Từ đó, việc sử OAuth OpenID mở rộng làm giảm tương tác RP IdP so với việc sử dụng OAuth  Tăng hiệu của mô hì nh tí ch hợp với thẻ thông tin CardSpace: Từ mơ hình, phương pháp tích hợp OAuth với CardSpace, OpenID OAuth mở rộng với CardSpace thấy việc xác thực lấy thông tin người dùng sử dụng OpenID OAuth mở rộng nhanh so với việc sử dụng OAuth Điều xuất phát từ việc giảm thiểu số bước trao đổi thông tin RP IdP OpenID OAuth mở rộng so với OAuth Nhưng ưu điểm của việc sử dụng OpenID OAuth mở rộng với OpenID  Sử dụng OpenID chỉ là một chế xác thực người dùng  Sử dụng OpenID OAuth mở rộng vừa là chế xác thực người dùng vừa l chế truy cập vào dữ liệu của người dùng Trong chương 3, luận văn đã trình bày chi tiết nội dung , giao thức OpenID OAuth mở rộng, phân tích ưu điểm OpenID OAuth mở rộng so với OpenID, OAuth Từ đưa mơ hình phương pháp tích hợp OpenID OAuth mở rộng với thẻ thông tin CardSpace 46 Chương THỰC NGHIỆM HỆ THỐNG Chương trình bày phần thực nghiệm hệ thống cho mơ hình , phương pháp mà luận văn đã đề xuất ở Chương 4.1 Thử nghiệm hệ thống Chương trì nh thực nghiệm thể cho phương pháp mà luận văn đã đề xuất chương được xây dựng máy laptop có cấu hì nh sau:  CPU: Intel Core Duo CPU T660 2.2 GHz  RAM 4GB  Windows Home Premium phiên bản 64 bit Các thành phần hệ thống mô tả bảng 4.1 bao gồm: Bảng 4.1 Các thành phần hệ thống thực nghiệm Thành phần Mô tả Chương trì nh được thực nghiệm trì nh duyệt Internet Explorer Trong quá trì n h thực nghiệm có sự tương tác của người dùng Người dùng và Browser Thành phần Identity Provider sử dụng chương trì nh thực nghiệm là: Google Identity Provider Thành phần Relying Party xây dựng dựa ngôn ngữ PHP , javascript, HTML với server web là Apache Relying Party Thành phần CardSpace thẻ người dùng tạo gi ao diện Identity Selector CardSpace 4.2 Thực nghiệm chương trì nh Hiện nay, số lượng người dùng nghe nhạc mạng ngày nhiều để tải nhạc bình luận vào hát mà người dùng yêu thích người dùng phải có tài khoản trang web âm nhạc Do vậy, để tránh phải đăng ký 47 tài khoản trang web âm nhạc chương trình thực nghiệm đưa ngữ cảnh sau: Trang web sannhac.com nơi lưu trữ hát ca sĩ thu âm người dùng Người dùng muốn tải bình luận hát thu âm người dùng phải có tài khoản trang Sannhac.com Để tránh phải đăng ký tài khoản người dùng sử dụng thẻ CardSpace tạo máy tính tài khoản trang Sannhac.com Người dùng sử dụng thẻ CardSpace để đăng nhập, tải nhạc bình luận Trang Sannhac.com phải hỗ trợ việc đăng nhập thẻ CardSpace Việc xác thực thông tin người sử dụng thẻ hợp lệ hay không thực nhà cung cấp định danh Google Trong trường hợp thì: RP sannhac.com, IdP Google IS giao diện hình CardSpace Ngữ cảnh người dùng tham gia trang web sannhac.com minh họa Hình 4.1 Relying Party (sannhac.com) Identity Provider (Google) Người dùng CardSpace Hình 4.1: Ngữ cảnh thực thi chương trì nh 48 Đầu tiên ngườ i dùng truy cập vào trang sannhac com đăng nhập c ách dùng thẻ CardSpace Identity Selector (IS) được hiển thị bằng cách sử dụng thẻ nội dụng trong thẻ có dạng Hì nh 4.2 giao diện người dùng lựa chọn CardSpace được hiển thị Hì nh 4.3: Hình 4.2: Đoạn mã hiển thị Identity Selector Hình 4.3: Chức người dùng lựa chọn CardSpace để đăng nhập Khi người dùng ấn vào biểu tượng CardSpace đoạn mã javascript Hình 4.4 thực thi để gọi thẻ CardSpace Microsoft Đoạn mã u cầu thẻ CardSpace phải có thơng tin trường như: 49 emailaddress, givenname, streetaddress, gender, webpage, privatepersonalidentifier hiển thị hình Identity Selector Microsoft function SubmitCard(card){ var strPath = 'http://schemas.xmlsoap.org/ws/2005/05/identity/claims/'; card.issuer = 'http://schemas.xmlsoap.org/ws/2005/05/identity/issuer/self'; card.requiredClaims.Add(strPath + 'emailaddress'); card.requiredClaims.Add(strPath + 'givenname'); card.requiredClaims.Add(strPath + 'streetaddress'); card.requiredClaims.Add(strPath + 'gender'); card.requiredClaims.Add(strPath + 'webpage'); card.optionalClaims.Add(strPath + 'privatepersonalidentifier'); 10 var token = document.getElementById("CardSpaceToken2"); 11 try{ 12 13 token.value = card.value; }catch (e){ 14 Alert("error:" + e.number); 15 } 16 var claims = getClaims(token); 17 var openid_identifier = ""; 18 for(var i = 0; i < claims.length; i++){ 19 var webpage = strPath + 'webpage'; 20 var uname = strPath + 'givenname'; 21 var mail = strPath + 'emailaddress'; 22 if (claims[i].type == webpage) { 23 openid_identifier = claims[i].value; 24 } else if (claims[i].type == uname) { 25 username = claims[i].value; 27 } else if (claims[i].type == mail) { 28 email = claims[i].value; 29 } 30 } 31 openLoginWindow2(openid_identifier); 32 } Hình 4.4: Đoạn mã javascript thực việc gọi CardSpace Microsoft 50 Sau đoạn mã javascript Hình 4.4 thực thi hình giao d iện Identity Selector của Microsoft được hiển thị để người dùng có thể chọn hoặc tạo một thẻ phù hợp với trang sannhac.com Giao diện IS được minh họa Hình 4.5 Người dùng chọn thẻ CardSpace phù hợp Hình 4.5: Người dùng lựa chọn CardSpace giao diện IS Sau người dùng chọn và gửi một CardSpace phù hợp thì chương trì nh Extension sẽ chặn mã SAML chứa thông tin của thẻ CardSpace này và khởi tạo, xây dựng yêu cầu xác thực OpenID, yêu cầu Extension chuyển hướng tới Google Yêu cầu OpenID có nhúng thêm yêu cầu chấp nhận OAuth Chi tiết yêu cầu xác thực OpenID minh họa Hình 4.6 https://www.google.com/accounts/o8/ud?openid.ns=http://specs.openid.net/auth /2.0&openid.claimed_id=http://specs.openid.net/auth/2.0/identifier_select&openi d.identity=http://specs.openid.net/auth/2.0/identifier_select&openid.return_to=ht tp://id.ming.vn/cardspace/authenIdP.php&openid.realm=http://id.ming.vn&openi d.mode=checkid_setup&openid.ns.ui=http://specs.openid.net/extensions/ui/1.0&o penid.ns.ext1=http://openid.net/srv/ax/1.0&openid.ext1.mode=fetch_request&open id.ext1.type.email=http://axschema.org/contact/email&openid.ext1.type.first=http:/ /axschema.org/namePerson/first&openid.ext1.type.last=http://axschema.org/name Person/last&openid.ext1.type.country=http://axschema.org/contact/country/home &openid.ext1.type.lang=http://axschema.org/pref/language&openid.ext1.required= email,first,last,country,lang&openid.ns.oauth=http://specs.openid.net/extension s/oauth/1.0&openid.oauth.consumer=id.ming.vn&openid.oauth.scope=http:// www.google.com/m8/feeds/http://www.opensocial.googleusercontent.com/api/pe ople/ Hình 4.6: Yêu cầu xác thực OpenID gửi tới Google 51 Extension ở là toà n bộ mã javascript được sử dụng để xử lý việc có hỗ trợ đăng nhập bằng thẻ CardSpace sannhac.com, chặn mã SAML chứa thông tin của thẻ CardSpace khởi tạo yêu cầu xác OpenID tới Google Nội dung Hì nh 4.4 mợt phần Extension Nhìn vào Hình 4.4 thấy từ dịng 16 đến dịng 29 Extension phân tích thơng tin thẻ CardSpace lưu trữ tạm thời thông tin lại, dòng 30 khởi tạo xác thực OpenID tới Google Sau yêu cầu xác thực OpenID gửi tới Google Google xác thực người dùng hỏi người dùng có cấp quyền truy cập liệu RP (sannhac.com) Quá trình xác thực người dùng xin quyền người dùng thể qua Hình 4.7 oo le c th c n i d ng id n qu n tru c p Hình 4.7: Google xác thực người dùng Sau Google xác thực người dùng thành công thì một mã SAML được gửi tới Sannhac.com Mã SAML bao gồm thuộc tính người dùng mà cung cấp Google chữ ký số RSTR SIIP phát Hình 4.8 họa phần thơng tin của thẻ CardSpace mã SAML Sannhac.com kiểm thông tin mã SAML này Nếu thông tin là hợp lệ thì Sannhac.com cho phép người dùng truy cập Hình 4.9 kết việc sử dụng thẻ CardSpace đăng nhập vào Sannhac.com truongtd217 truongtd217@gmail.com 52 1 google.com/accounts/o8/id google.com/accounts/o8/id OcGHXGQcRpYVGUpDkfxneSZaJ2+/ZYNHXAz9 sK33K3g= Hình 4.8: Thơng tin của thẻ CardSpace nằm mã SAML Hình 4.9: Kết quả sử dụng CardSpace đăng nhập vào Sannhac.com 4.3 Phân tích bảo mật tính dễ sử dụng SAML token không ký sinh Extension bước 11 mục 3.2 bao gồm PPID , thuộc tính người dùng cung cấp IdP , RSTR ký SIIP phát Một thực thể giả tạo tạo SAML để giả danh trang RP, khơng có quyền truy cập tới ba thành phần token là: 53 PPID, RSTR ký SIIP, RSTR cấp InfoCard chọn tảng thông tin người dùng IdP cung cấp, cung cấp người dùng xác thực thành công với IdP Ngoài , tham số nonce timestamp sử dụng để ngăn chặn công lặp lại Chương trình có ưu điểm là: lợi “Cardspace Identity Selector”, hỗ trợ tính bảo mật xây dựng CardSpace Ví dụ: gọi, “Identity selector” chạy môi trường sandbox, môi trường tách “identity selector” chạy với phần lại máy người dùng Điều giúp bảo vệ “identity selector” với chương trì nh đợc hại mà chạy máy người dùng Ngoài ra, tất giá trị chèn vào số trường thẻ cá nhân lưu trữ, mã hóa máy người dùng 4.4 Kết quả thực nghiệm Với mục đí ch minh họa việc tí ch hợp giao thức OpenID và OAuth mở rộng với thẻ thông tin CardSpace, xây dựng ngữ cảnh chương trình thực nghiệm dựa trang web sannhac com với nhà cung cấp dị ch vụ là Google Thông qua q trình thực nghiệm chúng tơi đạt được những kết quả nhau:  Thể hiện được các bước của giao thức tí ch hợp OpenID và OAuth mở rộng với CardSpace ngữ cảnh chương trì nh , từ việc người dù ng đăng nhập , lựa chọn thẻ CardSpace , xác thực với nhà cung cấp dịch vụ Google chấp nhận bởi trang web sannhac.com  Chương trì nh thực thi cũng minh họa và thể hiện được sự khác biệt giữa việc sử dụng giao thức OpenI D và OAuth mở rộng so với việc chỉ sử dụng OAuth Sự khác biệt đó thể hiện qua số bước tương tác giữ a sannhac.com và Google Nếu s dụng giao thức OAuth số bước tương tác ba , cịn sử dụng giao thức OpenID và OAuth mở rộng thì số bước chỉ là hai  Do CardSpace chỉ mặc đị nh hỡ trợ trình duyệt IE7 trở nên chương trì nh chưa thực hiện được các trì nh duyệt khác : Firefox, Chrome, Opera, v.v Trong chương đã mô tả chi tiết về hệ thớng và đưa ngữ cảnh của chương trình Từ đó, luận văn đã áp dụng mô hì nh và phương pháp tí ch hợp OpenID và OAuth mở rộng ở chương vào ngữ cảnh chương trình 54 KẾT LUẬN Hiện , người dùng sử dụng nhiề u hệ thống quản lý đị nh danh mà mỗi hệ thống lại có chế thực hiện đị nh danh khác nên người dùng sẽ cảm thấy khó khăn việc nhớ và quản lý những thuộc tí nh đị nh danh của mì nh , vậy, hệ thớng quản lý đị nh danh đã đời để giúp để giúp quản lý các thuộc tí nh đị nh danh người dùng , đảm bảo tí nh an toàn và tiện quản lý các thuộc tí nh đị nh danh của người dùng Từ đó, luận văn đã tì m hiểu được nội dung và các t hành phần 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 , số vấn đề xây dựng hệ thống quản lý định danh Ngoài ra, luận văn cũng t ìm hiểu nội dung giao thức CardSpace , OpenID, OAuth, mối quan hệ giữa các hệ thống quản lý đị nh danh CardSpace , OpenID, OAuth và phương pháp tí ch hợp giữa OpenID với CardSpace , giữa OAuth với CardSpace Từ đó , luận văn tiế n hành nghiên cứu, đề xuất, thực hiện và giải quyết được những vấn đề sau:  Tìm hiểu nội dung giao thức OpenID OAuth mở rộng  Phương pháp tí ch hợp OpenID OAuth mở rộng với thẻ thông tin CardSpace  Xây dựng được chư ơng trì nh thực nghiệm mì nh họa cho phương pháp tí ch hợp OpenID OAuth mở rộng với CardSpace Chương trì nh này là suốt với IdP và IS , sử dụng một trì nh duyệt mở rộng và chỉ yêu cầu thay đổi nhỏ RP Chương trì nh đã lợi dụng được điểm giống giữa IdP và CardSpace, điều này làm giảm công sức cần thiết cho việc xây dựng một hệ thống tí ch hợp đầy đủ Ngoài ra, việc thực hiện chương trì nh cũng không yêu cầu sự hợp tác kỹ thuật Microsoft nhà cung cấp dịch vụ  So sánh, đánh giá việc sử dụng OpenID OAuth mở rộng với việc sử dụng OpenID, OAuth Luận văn cũng đưa được những ưu điểm của việc sử dụng OpenID OAuth mở rộng so với việc sử dụng OpenID OAuth Những ưu điểm của việc sử dụng OpenID OAuth so với OAuth  OAuth sử dụng chế ba bước để có thể xin được sự ủy quyền của người dùng, thẻ truy cập truy cập vào liệu người dùng so với sử dụ ng OpenID OAuth mở rộng với chỉ có hai bước  Giảm tương tác RP IdP : Trong OAuth, để RP lấy liệu người dùng từ IdP phải trải qua ba bước Còn sử dụng OAuth OpenID mở rộng, cần trải qua bước RP lấy liệu người dùng IdP Từ đó, việc sử OAuth OpenID mở rộng làm giảm tương tác RP IdP so với việc sử dụng OAuth  Tăng hiệu của mô hì nh tí ch hợp với CardSpace : Từ mơ hình, phương pháp tích hợp OAuth với CardSpace, OpenID OAuth mở rộng với 55 CardSpace chúng tơi thấy việc xác thực lấy thông tin người dùng sử dụng OpenID OAuth mở rộng nhanh so với việc sử dụng OAuth Điều xuất phát từ việc giảm thiểu số bước trao đổi thông tin RP IdP OpenID OAuth mở rộng so với OAuth Những ưu điểm của việc sử dụng OpenID và OAuth mở rộng so với OpenID  Sử dụng OpenID chỉ là một chế xác thực người dùng  Sử dụng OpenID OAuth mở rộng vừa là chế xác thực người dùng vừa l chế truy cập vào dữ liệu của người dùng Kế hoạch tương lai luận văn sẽ tiếp tục nghiên cứu CardSpace Identity Selector phép truy cập và tí ch hợp tới nhà cung cấp nhận dạng khác : Shibboleth, Liberty, OpenID, OAuth, v.v Luận văn cũng sẽ mở rộng chương trình để hỗ trợ đờng thời nhiều nhà cung cấp đị nh danh , nhiều RP mà cho phép hỡ trợ CardSpace Vì CardSpace Microsoft hỗ trợ từ trình duyệt IE7, vậy, luận văn tiếp tục mở rợng và hồn thiện chương trình để hỗ trợ việc gọi CardSpace từ nhiều trì nh duyệt khác như: Firefox, Opera, Chrome, v.v 56 TÀI LIỆU THAM KHẢO Tiếng Anh [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] Thierry Nabeth, Mireille Hildebrandt “D 2.1 Inventory of topics and clusters”, FIDIS WP2, Wednesday, 21 September 2005 http://www.fidis.net/fileadmin/fidis/deliverables/fidis-wp2del2.1_Inventory_of_topics_and_clusters.pdf Axel Bucker (2005) Federated Identity Management And Web Services Security With IBM Tivoli Security Solutions An IBM Redbooks Joseph A Stanko (2007), “ Single sign-on over the internet using public-key cryptography”, US Patent 7, 246, 230 Microsoft (2005), “ Microsoft’s Vision for an Identity Metasystem”, http://www.identityblog.com/stories/2005/10/06/IdentityMetasystem.pdf A Nanda “Identity selector interoperability profile v1 0” Microsoft Corporation, 2007 Andreas Pfitzmann, Marit Hansen (2010) “Anonymity, Unlinkability, Undetectability, Unobservability, Pseudonymity, and Identity Management” http://dud.inf.tu-dresden.de/literatur/Anon_Terminology_v0.31.pdf Gail-Joon Ahn, John Lam (2005), “Managing privacy preferences for federated identity management”, New York, USA: ACM Press http://wiki.piratenpartij.nl/_media/pdf:onderzoek:ahnmanaging_privacy_preferences_for_federated_identity.pdf Michael B Jones, “A Guide to Using the Identity Selector Interoper-ability Profile V1.5 within Web Applications and Browsers Microsoft Corporation”, 2008 Vittorio BertoRPi, Garrett Serack and Caleb Baker, “Understanding windows CardSpace: An introduction to the concepts and challenges of digital identities”, 2007 Tim Berners-Lee (2005) “Uniform Resource Identifier (URI): Generic Syntax” http://tools.ietf.org/html/rfc3986 David Recordon and Brad Fitzpatrick OpenID Authentication 1.1, 2006 http://openid.net/specs/openid-authentication-1_1.html OpenID Community OpenID Authentication 2.0 | Final, 2007 http://openid.net/specs/openid- authentication- 2_0.html Haitham S Al-Sinani and Chris J Mitchell “Client-based CardSpaceOpenID interoperation” In Proceedings of ISCIS '11 | the 26th International Symposium on Computer and Information Sciences, London, UK, 26-28 September 2011 57 [14] Eran Hammer-Lahav The OAuth 1.0 Protocol | RFC5849, 2010 http://tools.ietf.org/html/rfc5849 [15] H S Al-Sinani, “Browser Extension-based Interoperation Between OAuth and Information Card-based Systems”, Technical Report: RHUL–MA– 2011–15 (Department of Mathematics, Royal Holloway, Univer-sity of London), 2011, http://www.ma.rhul.ac.uk/static/techrep/2011/RHUL-MA2011-15.pdf [16] David Recordon, D.Balfanz , D Recordon and J Smarr OpenID OAuth Extension, 10 september 2008 http://step2.googlecode.com/svn/spec/ope nid_oauth_extension/drafts/0/ openid_oauth_extension.html