THÔNG TIN TÀI LIỆU
ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ TRƯƠNG ĐÌNH TRƯỜNG TÍCH HỢP OPENID VÀ OAUTH MỞ RỘNG VỚI THẺ THÔNG TIN CARDSPACE LUẬN VĂN THẠC SĨ CƠNG NGHỆ THƠNG TIN Hà Nợi - 2012 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ TRƯƠNG ĐÌNH TRƯỜNG TÍCH HỢP OPENID VÀ OAUTH MỞ RỘNG VỚI THẺ THƠNG TIN CARDSPACE Ngành: Chun ngành: Mã sơ: Cơng nghệ thông tin Công nghệ phần mềm 60 48 10 LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN NGƯỜI HƯỚNG DẪN KHOA HỌC: TS VÕ ĐÌNH HIẾU Hà Nợi - 2012 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 Chƣơng TỔNG QUAN VỀ 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 và 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) là 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 nào 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) là đị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ể và thuộc tính này 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 1.2 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ý 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 và cách sử dụng khác [4] 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 và 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): là dịch vụ sử dụng 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 hệ thống, là cầu nối người dùng, Relying Party, Identity Provider 10 1.2.2 Quy trình hoạt đợng hệ thống định danh Quy trình hệ thống quản lý định danh minh qua 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 toà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 này và 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 và 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 Tính tiện dụng: Đảm bảo sự thoải mái quá trì nh người dùng sử dụng hệ thống 1.4 Phân loại hệ thống quản lý định danh Hệ thống quản lý định danh phân làm ba loại là: hệ thống quản lý định danh tập trung, hệ thống quản lý định danh dựa phân tích 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ó ưu điểm nhược điểm khác Sau đây, trình bày 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 định danh người dùng chứng thực, lưu trữ nơi cung cấp định danh tập trung (Identity Provider) thuộc hệ thống quản lý định danh 11 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 Tất thuộc tính định danh giai đoạn chứng thực, phân quyền quản lý tập trung IdP 1.4.2 Hệ thống quản lý định danh dựa phân tích dữ liệu ngƣời dùng Các hệ thống quản lý định danh dựa phân tích liệu người dùng thường có chức khai thác liệu để phân loại định danh Ví dụ, hệ thống dựa vào độ tuổi, nghề nghiệp 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 phương pháp quản lý định danh dựa phân tích liệu người dùng là giúp cho hệ thống linh hoạt trình hiển thị thơng tin liên quan, đưa 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 ứng dụng thương mại Tuy nhiên, phương pháp quản lý định danh dự phân tích liệu người dùng không tốt dẫn đến thông tin hiển thị khơng xác Điều này khiến cho người dùng thiếu thừa 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 lưu trữ và chứng thực Identity Provider khác [7] Dữ liệu hệ thống quản lý định danh phân tán thường quản lý trực tiếp người dùng Tuy nhiên, số trường hợp, cần phải có tổ chức thứ ba để chứng nhận liệu người dùng hợp lệ Thuộc tính định danh lưu trữ máy tính cá nhân, IdP khác mạng 12 Chƣơng TỔNG QUAN VỀ CARDSPACE, OPENID VÀ OAUTH 2.1 CardSpace CardSpace là phần phần mềm khách mà cho phép người dùng cung cấp nhận dạng số họ tới dịch vụ trực tuyến cách đơn giản, an toàn, tin cậy và Microsoft tích hợp sẵn Windows Vista Để người dùng sử dụng thẻ nhân xác thực với trang web RP CardSpace đã đưa luồng giao thức tương tác thẻ thông tin với trang web RP Chi tiết của luồng giao thức được minh họa thông qua bước sau [8]: UA → RP: Người dùng yêu cầu trang đăng nhập từ RP RP → UA: Một trang đăng nhập RP trả lại Trang đăng nhập có chứa thẻ cho phép gọi CardSpace sách bảo mật RP nhúng vào trang đăng nhập Người dùng → UA: Trang đăng nhập RP đưa gợi ý cho người dùng lựa chọn CardSpace Việc lựa chọn kích hoạt Selector thõa mãn sách RP Selector → InfoCards: Sau kiểm tra, thẩm định sách RP Selector hiển thị bật thẻ mà thỏa mãn với sách RP Người dùng → Selector: Sau hiển thị thẻ thõa mãn với sách RP người dùng lựa chọn thẻ nhân phù hợp Tuy nhiên, người dùng tạo chọn thẻ cá nhân Người dùng chỉnh sửa trường thơng tin bên thẻ để cho thẻ thỏa mãn với sách, yêu cầu RP Selector ↔ SIIP: IS 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) UA → RP: RSTR gửi tới UA và sau UA chuyển RSTR tới RP RP → Người dùng : RP kiểm tra, thẩm định token Nếu thỏa mãn yêu cầu RP RP cho phép người dùng quyền truy cập và ngược lại trình RP thẩm định kiểm tra token bị lỗi người dùng khơng có quyền truy cập 2.2 OpenID OpenID là 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 cần sử dụng định danh số OpenID cung cấp cho người dùng URI [10] để đăng nhập vào RP khác 13 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 là Browser hay UA (User Agent) 2.2.1 Giao thức OpenID Chi tiết giao thức OpenID thể thông qua bước sau UA → RP: Người dùng dựa vào UA để yêu cầu RP trang đăng nhập RP → UA: RP trả trang đăng nhập có chứa form đăng nhập OpenID Người dùng → UA: Người dùng nhập “OpenID identifier” họ vào form OpenID trang đăng nhập RP: RP khám phá địa IdP RP sử dụng “OpenID identifier” người dùng cung cấp để khám phá địa IdP Khám phá địa IdP dựa vào HTML Khám phá địa IdP dựa vào XRSD RP ↔ IdP: Bước tùy chọn Tại bước này, RP và IdP đồng ý chia sẻ với khóa bí mật Khóa này sử dụng cho chuỗi yêu cầu phản hồi qua lại RP IdP Q trình chia sẻ khóa bí mật suốt với người dùng RP và IdP tương tác với nhau: RP IdP giao tiếp với theo cách thức sau: checkid_immediate checkid_setup Với cách thức checkid_immediate RP IdP giao tiếp với mà khơng có tương tác người dùng Còn với cách thức checkid_setup RP IdP giao tiếp với mà có tương tác người dùng Nếu checkid_immediate sử dụng RP gửi yêu cầu xác thực OpenID tới IdP IdP gửi lại kết yêu cầu xác thực này và bước thực Nếu checkid_setup sử dụng RP chuyển hướng người dùng tới IdP theo yêu cầu xác thực OpenID (OpenID authentication request) và bước thực giao thức OpenID IdP ↔ Người dùng: Nếu cần thiết IdP xác thực người dùng Nếu thành cơng IdP gửi “OpenID assertion token”, token này bao gồm thuộc tính, thơng tin người dùng, nonce, timestamp, MAC máy tính Nếu khóa bí mật chia sẻ bước IdP sử dụng khóa này để sinh MAC, khơng có khóa chia sẻ bước IdP dùng khóa riêng để sinh MAC IdP → UA → RP: IdP chuyển hướng người dùng quay lại RP với kết tùy thuộc vào cho phép hay không cho phép người dùng bước RP → Người dùng: RP thẩm định MAC kết trả lại xác thực OpenID (OpenID authentication response) IdP Nếu hợp lệ RP cho phép người dùng truy cập Các tham số 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 tìm thấy phiên OpenID 1.1 RP sử dụng tham số timestamp 14 để loại bỏ phản hồi cũ Do hạn chế thời gian nhận kết phản hồi Nếu khóa bí mật chia sẻ bước RP sử dụng khóa này để xác minh MAC Nếu khóa bí mật mà khơng chia sẻ bước RP phải gửi yêu cầu tới IdP để nhờ IdP kiểm tra MAC Thông thường, việc kiểm tra này thực thông qua kênh truyền có TLS/SSL Q trình u cầu - đáp ứng (request – response) biết đến chế kiểm tra xác thực và chấp nhận trình tích hợp chương trình 2.2.2 Tích hợp OpenID với CardSpace Từ giao thức OpenID việc tích hợp OpenID và CardSpace thể thông qua bước sau [13] UA → RP: Người dùng yêu cầu trang đăng nhập từ RP RP → UA: Một trang đăng nhập RP trả lại Trang đăng nhập có chứa thẻ cho phép gọi CardSpace trường, sách bảo mật RP nhúng vào trang đăng nhập RP trả Extension → UA: Chương trình tích hợp thực bước sau: Extension kiểm tra trang đăng nhập mà RP trả cho UA để phát xem RP có hỗ trợ CardSpace hay khơng Nếu RP có hỗ trợ chương trình tiếp tục xử lý RP khơng hỗ trợ chương trình dừng lại Extension xem xét sách RP để kiểm tra xem việc sử dụng thẻ cá nhân có chấp nhận hay khơng Nếu có tiếp tục xử lý khơng cho CardSpace hoạt động bình thường Extension giữ lại trường khai báo mà RP yêu cầu Extension chỉnh sửa sách RP bao gồm kiểu trường sử dụng IDCard Extension khám phá giao thức mà RP sử dụng để giao tiếp HTTP HTTPS Người dùng → UA: Trang đăng nhập RP đưa gợi ý cho người dùng lựa chọn CardSpace Việc lựa chọn kích hoạt Selector thỏa mãn sách RP Selector → InfoCards: Sau kiểm tra thẩm định sách RP Selector hiển thị bật thẻ mà thỏa mãn với sách RP Người dùng → Selector: Sau hiển thị thẻ thỏa mãn với sách RP người dùng lựa chọn thẻ cá nhân phù hợp Tuy nhiên, người dùng tạo chọn thẻ cá nhân Người dùng chỉnh sửa trường thơng tin bên thẻ để cho thẻ tạo thỏa mãn với sách yêu cầu RP Selector ↔ SIIP: IS tạo gửi yêu cầu token bảo mật SAML ( Request Security Token - RST) tới SIIP Khi SIIP nhận yêu cầu trả lại RSTR (Request Security Token Response) 15 Selector → Extension/UA: Sau người sử dụng lựa chọn gửi OAuthCard 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 và xây dựng yêu cầu xác thực OpenID (OpenID authentication request), yêu cầu này Extension chuyển tới địa IdP (địa IdP xác định từ nội dung RSTR.) Nếu RP sử dụng HTTPS, Extension hỏi và yêu cầu người dùng nhập vào “OpenID identifier” họ Sau khi, người dùng cung cấp OpenID họ Extension khởi tạo và xây dựng yêu cầu xác thực OpenID, sau Extension chuyển yêu cầu này tới địa IdP (địa IdP xác định dựa OpenID mà người dùng cung cấp) 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 chương trình kết thúc Nếu thành cơng IdP yêu cầu người dùng quyền để IdP gửi “OpenID assertion token” tới trang RP 10 IdP chuyển hướng trực tiếp UA quay lại trang RP với “OpenID authentication response” hơp lệ hay không hợp lệ phụ thuộc vào cho phép hay không cho phép bước 11 Extension → UA: Extension xác minh MAC-protected OpenID authentication response việc tương tác với IdP sử dụng chế “check authentication” thông qua kênh TLS/SSL Nếu thành cơng khởi tạo SAML token CardSpace thích hợp chuyển tới RP Nếu việc xác minh bị lỗi Extension báo cho người dùng biết kết thúc 12 RP → Người dùng: RP xác minh SAML token (bao gồm xác minh chữ ký RSTR, PPID, nonce, timestamp, v.v) Nếu thỏa mãn cho truy cập Thẻ bảo mật SAML tạo Extension bước 11 bao gồm thuộc tính người chèn IdP chữ ký số RSTR phát SIIP (có chứa PPID), cho phép RP xác minh chữ ký SIIP 2.3 OAuth OAuth là giao thức mở OAuth cho phép người dùng chia sẻ nguồn tài nguyên riêng tư được lưu trữ một trang web với một trang web khác mà không cần phải cung cấp tên đăng nhập và mật khẩu cho các trang web đó 2.3.1 Giao thức OAuth Chi tiết giao thức OAuth thể thông qua bước sau [14] RP → IdP: RP gửi yêu cầu tới IdP để lấy thẻ yêu cầu (request token) IdP → RP: IdP trả lại cho RP thẻ truy cập gồm: “token secret” và “token key” Thẻ u cầu này khơng có quy ền truy cập vào liệu người dùng IdP 16 RP → UA → IdP: RP sử dụng thẻ yêu cầu đ ể chuyển hướng người dùng tới IdP Mục đích bước RP muốn sử dụng thẻ yêu cầu đ ể xin quyền truy cập vào liệu người dùng IdP IdP → Người dùng: Tại đây, IdP xác thực người dùng và đưa gợi ý mục đích RP xin quyền truy cập vào liệu người dùng IdP Người dùng → IdP: Người dùng đồng ý hay từ chối cho RP truy cập vào liệu người dùng IdP IdP → RP: IdP trả cho RP mã oauth_verifier để thông báo cho RP biết là người dùng đã xác thực với IdP và đã ủy quyền cho RP truy cập vào liệu người dùng IdP RP → IdP: RP gửi lại oauth_verifier và thẻ yêu cầu lên IdP đ ể trao đổi lấy thẻ truy cập IdP → RP: Sau IdP kiểm tra tính hợp lệ giá trị thẻ yêu cầu oauth_verifier Nếu hợp lệ IdP trả thẻ truy cập (access token) cho RP Khi RP nhận thẻ truy cập từ phía IdP RP sử dụng thẻ truy cập này để truy cập liệu người dùng IdP 2.3.2 Tich hợp OAuth với CardSpace Từ giao thức OAuth việc tích hợp OAuth với CardSpace thể thơng qua bước sau [15]: UA → RP: Người dùng yêu cầu trang đăng nhập từ RP RP → UA: Một trang đăng nhập RP trả lại Trang đăng nhập có chứa thẻ cho phép gọi CardSpace trường sách bảo mật RP nhúng vào trang đăng nhập RP trả Extension → UA: Chương trình tích hợp thực bước sau: Extension kiểm tra trang đăng nhập mà RP trả cho UA để phát xem RP có hỗ trợ CardSpace hay khơng Nếu RP có hỗ trợ chương trình tiếp tục xử lý RP khơng hỗ trợ chương trình dừng lại Extension xem xét sách RP để kiểm tra xem việc sử dụng thẻ cá nhân có chấp nhận hay khơng? Nếu có tiếp tục xử lý khơng cho CardSpace hoạt động bình thường Extension giữ lại trường khai báo mà RP yêu cầu Extension khám phá giao thức mà RP sử dụng để giao tiếp HTTP HTTPS Nếu HTTP sử dụng, Extension thay đổi sách RP để sách bao gồm trường sử dụng thể OAuth (OAuthCard) Người dùng → UA: Trang đăng nhập RP đưa gợi ý cho người dùng lựa chọn CardSpace Việc lựa chọn kích hoạt Selector thỏa mãn sách RP 17 Selector → InfoCards: Sau kiểm tra thẩm định sách RP Selector hiển thị bật thẻ mà thỏa mãn với sách RP Người dùng → Selector: Sau hiển thị thẻ thỏa mãn với sách RP người dùng lựa chọn thẻ cá nhân phù hợp Tuy nhiên, người dùng tạo chọn thẻ cá nhân Người dùng chỉnh sửa trường thông tin bên thẻ để cho thẻ tạo thỏa mãn với sách yêu cầu RP 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 ↔ 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 OAuthCard 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 Extension sử dụng nội dung RSTR để khởi tạo xây dựng yêu cầu OAuth, yêu cầu Extension chuyển tiếp tới IdP phù hợp (địa IdP khám phá và xác định từ RSTR) 10 IdP ↔ Người dùng: Sau Extension khởi tạo yêu cầu OAuth chuyển hướng người dùng tới IdP thích hợp 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 11 IdP → Extension/UA: Sau IdP xác thực người dùng thành công và người dùng đã ủy quyền cho RP truy cập vào liệu IdP chuyển hướng UA trở lại với RP theo URI đã cung cấp, bao gồm mã thông báo truy cập tham số cần thiết Extension đọc sử dụng thẻ truy cập (access token) đã cung cấp để yêu cầu lấy giá trị thuộc tính mà RP yêu cầu từ IdP thông qua giao tiếp trực RP với IdP 12 Extension/UA → RP: Sau lấy giá trị thuộc tính yêu cầu người sử dụng từ RP, Extension xây dựng mã thông báo SAML giống CardSpace và gửi mã SAML tới RP Mã thơng báo SAML bao gồm thuộc tính người dùng mà IdP cung cấp chữ ký số RSTR SIIP phát (có chứa PPID), từ cho phép RP xác minh chữ ký mà SIIP phát 13 RP → Người dùng: RP xác minh mã thông báo SAML (bao gồm xác minh chữ ký RSTR, PPID, nonce, time-stamps, v v ), thỏa mãn, RP cho phép truy cập Nếu không chương trình kết thúc 18 Chƣơng TÍCH HỢP OPENID VÀ OAUTH MỞ RỘNG VỚI THẺ THÔNG TIN CARDSPACE 3.1 OpenID và OAuth mở rộng Một nhà cung cấp (ví dụ: Yahoo, Google, v v) sử dụng OpenID chế xác thực người dùng và sử dụng OAuth cho việc truy cập vào liệu người dùng Như vậy, để giảm bớt trình sử dụng OpenID và OAuth, nhà cung cấp hỗ trợ việc mở rộng là: cho phép RP nhúng yêu cầu chấp nhận OAuth (OAuth approval request) vào bên yêu cầu xác thực OpenID (OpenID authentication request) Như vậy, đã hình thành nên đặc tả là đặc tả OpenID OAuth mở rộng 3.2 Giao thức OpenID OAuth mở rộng Luồng giao thức OpenID và OAuth mở rộng minh họa qua bước sau [16]: RP → IdP: RP gửi yêu cầu tới IdP để lấy thẻ yêu cầu (request token) đã ủy quyền người dùng Cụ thể: RP nhúng yêu cầu chấp nhận OAuth (OAuth approval request) vào yêu cầu xác thực OpenID (OpenID authentication request) gửi tới IdP IdP → Người dùng: Tại đây, IdP xác thực người dùng và đưa gợi ý mục đích RP xin quyền truy cập vào liệu người dùng IdP Người dùng → IdP: Người dùng đồng ý hay từ chối cho RP truy cập vào liệu người dùng IdP IdP → RP: Sau IdP xác thực xong người dùng IdP gửi thẻ yêu cầu đã ủy quyền người dùng phía RP là phần kết phản hồi phía RP IdP RP → IdP: RP sử dụng thẻ yêu cầu để 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 IdP → RP: IdP thẩm định kiểm tra giá trị RP gửi lên như: request token, timestamp, nonce, v.v Nếu thỏa mãn IdP gửi thẻ truy cập (access token) cho RP kết trả 3.3 Tích hợp OpenID OAuth với CardSpace Từ việc nghiên cứu , tìm hiều việc tích hợp OpenID với CardSpace , OAuth với CardSpace ở chương 2, đã đưa giao thức tích hợp OpenID và OAuth mở rộng với CardSpace thể Hình 3.1 và gốm bước sau: UA → RP: Người dùng yêu cầu trang đăng nhập từ RP 19 RP → UA: Một trang đăng nhập RP trả lại Trang đăng nhập có chứa thẻ cho phép gọi CardSpace trường sách bảo mật RP nhúng vào trang đăng nhập RP trả Extension → UA: Chương trình tích hợp thực bước sau: Extension kiểm tra trang đăng nhập mà RP trả cho UA để phát xem RP có hỗ trợ CardSpace hay khơng Nếu RP có hỗ trợ chương trình tiếp tục xử lý RP khơng hỗ trợ chương trình dừng lại Extension xem xét sách RP để kiểm tra xem việc sử dụng thẻ cá nhân có chấp nhận hay khơng Nếu có tiếp tục xử lý khơng cho CardSpace hoạt động bình thường Extension giữ lại trường khai báo mà RP yêu cầu Extension chỉnh sửa sách RP bao gồm kiểu trường sử dụng IDCard Ví dụ: “OpenID identifier” người dùng lưu trữ trường “web page” IDCard, sau Extension phải đảm bảo sách bảo mật RP có trường “web page” Chú ý việc thêm kiểu trường này vào sách RP để đảm bảo token cung cấp SIIP có chứa giá trị trường mà xử lý Extension Extension khám phá giao thức mà RP sử dụng để giao tiếp HTTP hay HTTPS Người dùng → UA: Trang đăng nhập RP đưa gợi ý cho người dùng lựa chọn CardSpace Việc lựa chọn kích hoạt Selector thỏa mãn sách RP Selector → InfoCards: Sau kiểm tra thẩm định sách RP Selector hiển thị bật thẻ mà thỏa mãn với sách RP Người dùng → Selector: Sau hiển thị thẻ thỏa mãn với sách RP người dùng lựa chọn thẻ cá nhân phù hợp Tuy nhiên, người dùng tạo chọn thẻ cá nhân Người dùng chỉnh sửa trường thơng tin bên thẻ để cho thẻ tạo thỏa mãn với sách yêu cầu RP 20 RP User Agent Plug-in Selector (CardSpace - enable IdP HTTP yêu cầu trang đăng nhập User gọi và 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ý và ngăn chặn SAML token User gọi CardSpace Plug-in: Bắt SAML và 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 và 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 và xây dựng yêu cầu xác thực OpenID, yêu cầu này Extension chuyển tiếp tới IdP phù hợp (địa IdP khám phá và xác định từ RSTR) Yêu cầu xác thực OpenID này có nhúng thêm yêu cầu chấp nhận OAuth 21 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 này 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 và 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 này 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 và xây dựng yêu cầu xác thực OpenID, yêu cầu này Extension chuyển hướng tới IdP (địa IdP này xác định dựa vào URI mà người dùng cung cấp) Yêu cầu OpenID này 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 yêu cầu người sử dụng từ IdP, Extension xây dựng mã thông báo SAML giống CardSpace và 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 và 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ẻ 22 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 và IdP Tăng hiệu của mô hì nh tí ch hợp với thẻ thông tin CardSpace 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 và 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 23 Chƣơng THỰC NGHIỆM HỆ THỐNG Chương trình bày về 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ì nh 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 Id entity Provider được 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 là t hẻ 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 càng nhiều và để tải nhạc và bình luận vào bài hát mà người dùng 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ý 24 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 là nơi lưu trữ hát ca sĩ và 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 là tài khoản trang Sannhac.com Người dùng sử dụng thẻ CardSpace này để đă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 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à: PPID, RSTR đã ký SIIP, RSTR cấp InfoCard chọn tảng và thông tin người dùng IdP cung cấp, này cung cấp người dùng xác thực thành cơng với IdP Ngồi , tham số nonce và 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”, và 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 này tách “identity selector” chạy với phần lại máy người dùng Điều này giúp bảo vệ “identity selector” với chương trì nh độc hại nào 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 và 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 đã đạ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 và chấp nhận bởi trang web sannhac.com 25 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 OpenID 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 là ba , 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 26 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 thành phần của 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 và giao thức của 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 C ardSpace, 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 và giao thức OpenID và 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 và 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à 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 c hương trì nh cũng không yêu cầu sự hợp tác kỹ thuật giữa Microsoft và nhà cung cấp dịch vụ So sánh, đánh giá việc sử dụng OpenID và 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 việc sử dụng OpenID và OAuth mở rộng so với việc sử dụng OpenID hoặc OAuth Những ưu điểm của việc sử dụng OpenID và 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 và 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 và 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 27 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 và 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 như: 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à hoàn thiện chương trì nh để có thể hỗ trợ việc gọi CardSpace từ nhiều trì nh duyệt khác như: Firefox, Opera, Chrome, v.v 28 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 29 [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 Thank you for evaluating AnyBizSoft PDF Splitter A watermark is added at the end of each output PDF file To remove the watermark, you need to purchase the software from http://www.anypdftools.com/buy/buy-pdf-splitter.html ... 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... 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... TRƯỜNG TÍCH HỢP OPENID VÀ OAUTH MỞ RỘNG VỚI THẺ THÔNG TIN CARDSPACE Ngành: Chuyên ngành: Mã sô: Công nghệ thông tin Công nghệ phần mềm 60 48 10 LUẬN VĂN THẠC SĨ CÔNG NGHỆ THÔNG TIN NGƯỜI
Ngày đăng: 06/03/2020, 00:12
Xem thêm: