Tích hợp OpenID với CardSpace

Một phần của tài liệu Tích hợp OpenID và OAuth mở rộng với thẻ thông tin CardSpace (Trang 25 - 28)

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

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

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

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

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

Hình 2.9: Giao thức tích hợp giữa OpenID và CardSpace 1. UA → RP: Người dùng yêu cầu một trang đăng nhập từ RP

2. RP → UA: Một trang đăng nhập được RP trả lại. Trang đăng nhập này có chứa những thẻ cho phép gọi CardSpace và những trường, chính sách bảo mật của RP cũng được nhúng vào trong trang đăng nhập của RP trả về.

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

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

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

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

User Agent RP

(CardSpace - enable - IdP

Highlight

IDcard

Selector Plug-in

Chuyển OpenID auth request tới IdP OpenID auth response

SIIP

Plug-in: Khởi tạo SAML token (RSTR + thuộc tính user)

Cho phép /từ chối user truy cập

Phân tích Thẩm định Quyết định Plug-in: Bắt SAML và khởi tạo một

OpenID auth request.

HTTP yêu cầu trang đăng nhập RP trả lại trang đăng nhập (policy của

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

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

Yêu cầu SAML SAML phản hồi User gọi và Gửi một IDcard High ligh t ID Car d Phân tích Auth user Ủy quyền

4. Extension chỉnh sửa chính sách của RP bao gồm kiểu của các trường được sử dụng trong IDCard. Ví dụ: nếu “OpenID identifier” của người dùng được lưu trữ trong trường “web page” của IDCard, thì sau đó Extension phải đảm bảo rằng chính sách bảo mật của RP sẽ có trường “web page”. Chú ý rằng việc thêm kiểu trường này vào chính sách RP để đảm bảo rằng token được cung cấp bởi SIIP có chứa những giá trị của những trường này mà có thể được xử lý bởi Extension.

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

4. Người dùng → UA: Trang đăng nhập của RP sẽ đưa ra gợi ý cho người dùng lựa chọn CardSpace. Việc lựa chọn này sẽ kích hoạt Selector nếu như thỏa mãn được các chính sách của RP.

5. Selector → InfoCards: Sau khi kiểm tra và thẩm định các chính sách của RP thì Selector sẽ hiển thị nổi bật những thẻ mà thỏa mãn với chính sách của RP. 6. Người dùng → Selector: Sau khi hiển thị những thẻ thỏa mãn với chính sách

của RP thì người dùng sẽ lựa chọn một thẻ cá nhân phù hợp nhất. Tuy nhiên, người dùng có thể tạo và chọn một thẻ cá nhân mới. Người dùng có thể chỉnh sửa những trường thông tin bên trong thẻ để sao cho thẻ được tạo ra thỏa mãn với những chính sách và yêu cầu của RP.

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

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

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

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

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

10.IdP chuyển hướng trực tiếp UA quay lại trang RP với một “OpenID authentication response” hơp lệ hay không hợp lệ phụ thuộc vào sự cho phép hay không cho phép ở bước 9.

11.Extension → UA: Extension xác minh MAC-protected OpenID authentication response bằng việc tương tác với IdP sử dụng cơ chế “check authentication” thông qua kênh TLS/SSL. Nếu thành công thì nó khởi tạo một SAML token CardSpace thích hợp và chuyển nó tới RP. Nếu việc xác minh bị lỗi thì Extension sẽ báo cho người dùng biết và kết thúc.

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, v.v). Nếu thỏa mãn thì cho truy cập. Thẻ bảo mật SAML được tạo ra bởi Extension ở bước 11 bao gồm các thuộc tính của người được chèn bởi IdP và chữ ký số RSTR được phát ra bởi SIIP (có chứa PPID), cho phép RP xác minh chữ ký SIIP.

Giao thức tích hợp OpenID vớ i CardSpace sẽ có sự khác nhau khi RP sử dụng HTTP hay HTTPS. Nếu RP sử dụng HTTPS thì RSTR mà Selector gửi về cho UA sẽ được mã hóa, từ đó, Extension sẽ không thể biết được thông tin của thẻ CardSpace và địa chỉ của IdP. Nếu RP sử dụng HTTP thì RSTR sẽ không được mã hóa và Extension sẽ biết được thông tin của thẻ CardSpace và địa chỉ của IdP.

Một phần của tài liệu Tích hợp OpenID và OAuth mở rộng với thẻ thông tin CardSpace (Trang 25 - 28)