Trước khi đi vào chi tiết của giao thức OpenID và OAuth mở rộng thì RP và IdP phải thống nhất dùng chung một cặp khóa là: “consumer key” và “consumer secret”. Để có được cặp khóa này thì RP phải đăng ký với IdP. IdP phải chứa thêm vùng thông tin (email, thông tin cá nhân, v...v) mà RP yêu cầu.
Không gian vùng mở rộng (namespace) URI cho OpenID và OAuth này là: http://specs.openid.net/extensions/oauth/1.0 [16]. Vì vậy, tất cả các thông điệp OpenID mà có chứa “OpenID và OAuth mở rộng” thì phải chứa khai báo với phần tên mở rộng như sau: openid.ns.<alias>=http://specs.openid.net/extensions/oauth/1.0. Không gian tên bí danh mở rộng được xác định và quản lý bởi RP để tránh xung đột giữa các phần mở rộng. Trong luận văn này, oauth được sử dụng như một ví dụ cho không gian tên bí danh mở rộng.
Luồng giao thức OpenID và OAuth mở rộng được minh họa qua các bước chính sau [16]:
1. RP → IdP: RP gửi yêu cầu tới IdP để lấy thẻ yêu cầu (request token) đã được sự ủy quyền của người dùng. Cụ thể: RP sẽ nhúng yêu cầu chấp nhận OAuth (OAuth approval request) vào trong một yêu cầu xác thực OpenID (OpenID authentication request) rồi gửi tới IdP.
2. IdP → Người dùng: Tại đây, IdP sẽ xác thực người dùng và đưa ra gợi ý về mục đích của RP xin quyền truy cập vào dữ liệu người dùng trên IdP.
3. Người dùng → IdP: Người dùng đồng ý hay từ chối cho RP truy cập vào dữ liệu của người dùng trên IdP.
4. IdP → RP: Sau khi IdP xác thực xong người dùng thì IdP sẽ gửi thẻ yêu cầu đã được sự ủy quyền của người dùng về phía RP như là một phần của kết quả phản hồi về phía RP của IdP.
5. 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 này giống với quá trình trao đổi trong OAuth chuẩn.
6. IdP → RP: IdP thẩm định và kiểm tra các giá trị RP gửi lên như: request token, timestamp, nonce, v.v. Nếu thỏa mãn thì IdP sẽ gửi thẻ truy cập (access token) về cho RP như một kết quả trả về.
Quá trình lấy thẻ yêu cầu của RP sẽ được mô tả chi tiết trong mục 3.2.1 và RP sử dụng thẻ yêu cầu để trao đổi lấy thẻ truy cập từ IdP sẽ được mô tả chi tiết trong mục 3.2.2.
3.2.1 RP lấy thẻ yêu cầu từ IdP
RP lấy thẻ yêu cầu đã được sự ủy quyền của người dùng từ IdP. Cụ thể: RP sẽ nhúng một yêu cầu chấp nhận OAuth vào trong một yêu cầu xác thực OpenID rồi gửi tới IdP. Những thông tin của một yêu cầu chấp nhận OAuth (OAuth approval request) mà RP gửi tới IdP bao gồm:
openid.ns.oauth (bắt buộc): http://specs.openid.net/extensions/oauth/1.0
openid.oauth.consumer (bắt buộc): Giá trị của consumer key.
openid.oauth.scope (tùy chọn).
IdP sẽ thẩm định những thông tin mà RP gửi lên. Nếu thỏa mãn và được sự ủy quyền của người dùng thì IdP sẽ gửi thẻ yêu cầu như là một phần của kết quả về phía RP. Thẻ yêu cầu sẽ được trả theo các tham số sau:
openid.ns.oauth: http://specs.openid.net/extensions/oauth/1.0.
openid.oauth.request_token: Một request token mà được người ủy quyền
openid.oauth.scope (tùy chọn).
Nếu người dùng từ chối RP truy cập dữ liệu trên IdP thì kết quả trả về từ phía IdP chỉ có tham số: openid.ns.oauth.
3.2.2 RP trao đổi mã truy cập với IdP
RP sử dụng thẻ yêu cầu để trao đổi lấy thẻ truy cập từ IdP. Quá trình trao đổi này giống với quá trình trao đổi trong OAuth chuẩn. Có nghĩa là để yêu cầu một thẻ truy cập, RP phải tạo một yêu cầu HTTP rồi gửi tới URL “access token” của IdP . RP sử dụng những giá trị dưới đây để 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 một chuỗi trống.
IdP sẽ thẩm định và kiểm tra các tham số mà RP gửi lên. Nếu thỏa mãn thì IdP sẽ trả lại phía RP một “access token” theo các tham số sau:
openid.ns.oauth: http://specs.openid.net/extensions/oauth/1.0.
openid.oauth.access_token: Giống với access token như ở trong OAuth chuẩn.
openid.oauth.access_token_secret: Giống với “token secret” trong OAuth chuẩn.
3.3 Tích hợp OpenID và OAuth với CardSpace (adsbygoogle = window.adsbygoogle || []).push({});
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, chúng tôi đã đưa ra giao thức tích hợp giữa OpenID và OAuth mở rộng với CardSpace được thể hiện như trong Hình 3.1 và gốm các bước chính sau:
1. UA → RP: Người dùng yêu cầu một trang đăng nhập từ RP
2. RP → UA: Một trang đăng nhập được RP trả lại. Trang đăng nhập này có chứa những thẻ cho phép gọi CardSpace và những trường và chính sách bảo mật của RP cũng được nhúng vào trong trang đăng nhập của RP trả về.
3. Extension → UA: Chương trình tích hợp sẽ thực hiện các bước sau:
1. Extension kiểm tra trang đăng nhập mà RP trả về cho UA để phát hiện xem RP có hỗ trợ CardSpace hay không. Nếu RP có hỗ trợ thì chương trình tiếp tục xử lý còn nếu RP không hỗ trợ thì chương trình sẽ dừng lại. 2. Extension xem xét chính sách của RP để kiểm tra xem việc sử dụng thẻ
cá nhân có được chấp nhận hay không. Nếu có thì tiếp tục xử lý và nếu không thì cho CardSpace hoạt động bình thường.
3. Extension giữ lại các trường và những khai báo mà RP yêu cầu.
4. Extension chỉnh sửa chính sách của RP bao gồm kiểu của các trường được sử dụng trong IDCard. Ví dụ: nếu “OpenID identifier” của người dùng được lưu trữ trong trường “web page” của IDCard, thì sau đó Extension phải đảm bảo rằng chính sách bảo mật của RP sẽ có trường “web page”. Chú ý rằng việc thêm kiểu trường này vào chính sách RP để đảm bảo rằng token được cung cấp bởi SIIP có chứa những giá trị của những trường này mà có thể được xử lý bởi Extension
5. Extension khám phá ra giao thức mà RP sử dụng để giao tiếp là HTTP hay HTTPS.
4. Người dùng → UA: Trang đăng nhập của RP sẽ đưa ra gợi ý cho người dùng lựa chọn CardSpace. Việc lựa chọn này sẽ kích hoạt Selector nếu như thỏa mãn được các chính sách của RP.
5. Selector → InfoCards: Sau khi kiểm tra và thẩm định các chính sách của RP thì Selector sẽ hiển thị nổi bật những thẻ mà thỏa mãn với chính sách của RP. 6. Người dùng → Selector: Sau khi hiển thị những thẻ thỏa mãn với chính sách
của RP thì người dùng sẽ lựa chọn một thẻ cá nhân phù hợp nhất. Tuy nhiên, người dùng có thể tạo và chọn một thẻ cá nhân mới. Người dùng có thể chỉnh sửa những trường thông tin bên trong thẻ để sao cho thẻ được tạo ra thỏa mãn với những chính sách và yêu cầu của RP.
Hình 3.1: Giao thức tích hợp giữa OpenID và OAuth mở rộng với CardSpace 7. Selector ↔ SIIP: Selector sẽ 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).
8. Selector → Extension/UA: Sau khi người sử dụng lựa chọn và gửi một OpenIDOAuthCard phù hợp, thì không giống như trường hợp chuẩn, RSTR sẽ không được gửi tới RP ngay, thay vào đó Extension sẽ chặn RSTR và tạm thời lưu trữ RSTR lại.
1. Nếu RP sử dụng HTTP: Extension sẽ sử dụng nội dung của RSTR để khởi tạo và xây dựng một yêu cầu xác thực OpenID, yêu cầu này sẽ được Extension chuyển tiếp tới một IdP phù hợp (địa chỉ IdP được 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.
User Agent
Plug-in Selector
Yêu cầu SAML SAML phản hồi User gọi và Gửi một IDcard High ligh t ID Car d
HTTP yêu cầu trang đăng nhập RP trả lại trang đăng nhập (policy của
RP được nhúng vào trang đăng nhập) Plug-in xử lý và ngăn
chặn một SAML token User gọi CardSpace
Plug-in: Bắt SAML và nhúng OAuth approval vào OpenID auth request. Chuyển OpenID auth request tới IdP
OpenID auth response chứa access token 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 (CardSpace - enable RP IdP Phân tích Auth user Ủy quyền
2. Nếu RP sử dụng HTTPS: Đầu tiên, Extension sẽ 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 thì Extension sẽ 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 thì Extension sẽ hướng dẫn người dùng nhập vào URI của IdP. Sau khi người dùng đã nhập URI của IdP rồi thì Extension sẽ khởi tạo và xây dựng một yêu cầu xác thực OpenID, yêu cầu này sẽ được Extension chuyển hướng tới IdP (địa chỉ IdP này được 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.
9. IdP → Người dùng: IdP sẽ xác thực người dùng. Nếu xác thực không thành công thì chương trình sẽ kết thúc. Nếu IdP xác thực người dùng thành công thì sẽ đưa ra gợi ý cho người dùng về việc ủy quyền cho RP lấy và truy cập vào dữ liệu của người dùng trên IdP. Nếu người dùng đồng ý thì IdP sẽ gửi thẻ yêu cầu về cho RP.
10.RP ↔ IdP: RP sử dụng thẻ yêu cầu đã được người dùng ủy quyền để trao đổi lấy thẻ truy cập với IdP. Quá trình trao đổi này giống với quá trình trao đổi trong OAuth chuẩn. RP sử dụng những giá trị dưới đây để tạo yêu cầu thẻ truy cập: (adsbygoogle = window.adsbygoogle || []).push({});
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 một chuỗi trống.
IdP thẩm định lại các giá trị mà RP gửi. Nếu thỏa mãn thì IdP sẽ gửi “access token” về cho RP.
11.Extension/UA → RP: Sau khi khôi phục các giá trị thuộc tính yêu cầu của người sử dụng từ IdP, Extension xây dựng một mã thông báo SAML giống như CardSpace và gửi nó tới RP. Một mã thông báo như vậy bao gồm các thuộc tính của người dùng mà được cung cấp bởi IdP và chữ ký số RSTR được SIIP phát ra (có chứa PPID).
12.RP → Người dùng: RP xác minh SAML token (bao gồm xác minh cả chữ ký RSTR, PPID, nonce, timestamp, …). Nếu thỏa mãn thì RP cho phép người dùng truy cập.
Dựa trên những nội dung và giao thức của OpenID, OAuth, OpenID và OAuth mở rộng mà luận văn đã tìm hiểu được thì việc sử dụng OpenID và OAuth mở rộng tích hợp với thẻ thông tin CardSpace có những ưu điểm so với chỉ sử dụng OpenID hoặc OAuth như sau:
Những ưu điểm của việc sử dụng OpenID và OAuth mở rộng với OAuth
OAuth sử dụng cơ chế ba bước gồm: Bước 1 là RP lấy thẻ yêu cầu (request token) từ IdP, bước 2 là xác thực và xin quyền truy cập người dùng cho thẻ
yêu cầu, bước 3 là RP dùng thẻ yêu cầu để trao đổi thẻ truy cập (access token) từ IdP, khi có thẻ truy cập thì RP có thể truy cập vào dữ liệu người dùng. Trong khi đó, OpenID và OAuth mở rộng chỉ sử dụng với hai bước sau: Bước 1 là RP lấy thẻ yêu cầu mà đã có sự ủy quyền của 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 : Trong OAuth, để RP có thể lấy được dữ liệu người dùng từ IdP phải trải qua ba bước. Còn khi sử dụng OAuth và OpenID mở rộng, chỉ cần trải qua 2 bước thì RP có thể lấy được dữ liệu của người dùng trên IdP. Từ đó, việc sử OAuth và OpenID mở rộng sẽ làm giảm tương tác giữa RP và IdP so với việc sử dụng OAuth.
Tăng hiệu năng 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 và OAuth mở rộng với CardSpace thì chúng ta thấy việc xác thực và lấy thông tin người dùng khi sử dụng OpenID và OAuth mở rộng sẽ nhanh hơn so với việc sử dụng OAuth. Điều này xuất phát từ việc giảm thiểu số bước trao đổi thông tin giữa RP và IdP của OpenID và 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 với OpenID
Sử dụng OpenID chỉ là một cơ chế xác thực người dùng.
Sử dụng OpenID và OAuth mở rộng vừa là cơ chế xác thực người dùng vừa l à cơ 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 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
Chương này 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 ở trong Chương 3.
4.1 Thử nghiệm hệ thống
Chương trình thực nghiệm thể hiện cho phương pháp mà luận văn đã đề xuất trong chương 4 được xây dựng trên máy laptop có cấu hình như sau:
CPU: Intel Core 2 Duo CPU T660 2.2 GHz.
RAM 4GB
Windows 7 Home Premium phiên bản 64 bit
Các thành phần của hệ thống được mô tả trong bảng 4.1 bao gồm: Bảng 4.1 Các thành phần trong hệ thống thực nghiệm
Thành phần Mô tả
Người dùng và Browser
Chương trình được thực nghiệm trên trình duyệt Internet Explorer 7. Trong quá trìn h thực nghiệm có sự tương tác của người dùng.
Identity Provider (adsbygoogle = window.adsbygoogle || []).push({});
Thành phần Identity Provider được sử dụng trong chương trình thực nghiệm là: Google
Relying Party
Thành phần Relying Party được xây dựng dựa trên ngôn ngữ PHP , javascript, HTML với server web là Apache.
CardSpace
Thành phần CardSpace là những thẻ được người dùng tạo ra trên gi ao diện Identity Selector.
4.2 Thực nghiệm chương trình
Hiện nay, số lượng người dùng nghe nhạc trên mạng ngày càng nhiều và để có thể tải nhạc và bình luận vào những bài hát mà người dùng yêu thích thì người dùng phải có tài khoản trên những trang web âm nhạc này. Do vậy, để tránh phải đăng ký
một tài khoản mới trên mỗi trang web âm nhạc như vậy thì chương trình thực nghiệm đưa ra ngữ cảnh sau:
1. Trang web sannhac.com là nơi lưu trữ những bài hát của các ca sĩ và những bài thu âm của người dùng.
2. Người dùng muốn tải và bình luận những bài hát và những bài thu âm thì người dùng phải có tài khoản trên trang Sannhac.com.
3. Để tránh phải đăng ký một tài khoản mới thì người dùng sử dụng một thẻ CardSpace được tạo ra trên máy tính như là một tài khoản trên trang Sannhac.com. Người dùng có thể sử dụng thẻ CardSpace này để có thể đăng nhập, tải nhạc và bình luận.
4. Trang Sannhac.com phải hỗ trợ việc đăng nhập bằng thẻ CardSpace.
5. Việc xác thực những thông tin của người sử dụng thẻ là hợp lệ hay không được thực hiện bởi nhà cung cấp định danh là Google.
Trong trường hợp này thì: RP là sannhac.com, IdP là Google và IS là giao diện màn hình CardSpace.
Ngữ cảnh của người dùng khi tham gia và trang web sannhac.com được minh họa như trên Hình 4.1.
Hình 4.1: Ngữ cảnh thực thi chương trình
Relying Party (sannhac.com)
Người dùng CardSpace
Identity Provider (Google)
2
3
4 5
Đầu tiên ngườ i dùng truy cập vào trang sannhac .com và đăng nhập bằng c ách dùng thẻ CardSpace . Identity Selector (IS) được hiển thị bằng cách sử dụng thẻ <object> và nội dụng trong trong thẻ <object> có dạng như trong Hình 4.2 và giao diện người dùng lựa chọn CardSpace được hiển thị như trong Hình 4.3:
Hình 4.2: Đoạn mã hiển thị Identity Selector
Hình 4.3: Chức năng người dùng lựa chọn CardSpace để đăng nhập