Giao thức tích hợp giữa OpenID và CardSpace- 123docz.net

Hình 2 .6 Sử dụng Yadis để xác định địa chỉ của Identity Provider

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 của

RP được nhúng và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 tích hợp OpenID vớ i CardSpace sẽ có sự khác nhau khi RP sử dụng HTTP hay HTTPS. Nếu RP sử dụng HTTPS thì RSTR mà Selector gửi về cho UA sẽ được mã hóa, từ đó, Extension sẽ không thể biết được thông tin của thẻ CardSpace và địa chỉ của IdP. Nếu RP sử dụng HTTP thì RSTR sẽ không được mã hóa và Extension sẽ biết được thông tin của thẻ CardSpace và địa chỉ của IdP.

2.3 OAuth

Hiện nay, người dùng có rất nhiều dữ liệu trên những trang web khác nhau như: Facebook, Twitter, Yahoo, v.v. Tại mỗi thời điểm người dùng muốn truy cập hay lấy dữ liệu của họ thì những người dùng này phải cung cấp tên đăng nhập và mật khẩu. Một câu hỏi được đặt ra là: làm thế nào để người dùng không phải cung cấp tên đăng nhập và mật khẩu mà vẫn có thể lấy và truy cập được dữ liệu của họ trên những trang web khác nhau. Vì vậy, OAuth (Open authentication) đã được đề xuất và đã đưa ra được giải pháp để giải quyết yêu cầu của người dùng được nêu ra ở trên.

OAuth là một giao thức mở . OAuth cho phép người dùng chia sẻ nguồn tài nguyên riêng tư được lưu trữ trên một trang web với một trang web khác mà không cần phải cung cấp tên đăng nhập và mật khẩu cho các trang web đó.

Một số thuật ngữ được sử dụng trong đặc tả OAuth là:

 Consumer: Là một trang web hay ứng dụng. Consumer ở đây giống như Rypling Party (RP) trong đặc tả OpenID.

 Service Provider (SP): Là một trang web mà có chứa thông tin người dùng và dữ liệu của người dùng. Service Provider ở đây giống như Identity Provider (IdP) trong đặc tả OpenID.

 Người dùng: Là những người có tài nguyên được lưu trữ trên một hoặc nhiều Service Provider.

 Nếu không có OAuth thì người dùng sẽ phải chia sẻ những thông tin của họ cho những ứng dụng không đáng tin cậy.

 OAuth giải quyết vấn đề này bằng cách cho phép người dùng cấp quyền , hủy quyền truy cập của một ứng dụng trong một thời gian có giới hạn.

 OAuth không yêu cầu người dùng tin tưởn g vào các ứng dụng khách . Thay vào đó, ứng dụng khách là tin cậy khi sủ dụng OAuth.

 OAuth không tự động cấp quyền truy cập tài nguyên của người dùng cho các ứng dựng khách. Thay vào đó, người dùng sẽ cấp quyền cho ứng dụng có triển khai OAuth để những ứng dụng đó có thể lấy được những tài nguyên riêng tư của người dùng.

Ví dụ: RP không có quyền của người dùng truongtd để truy cập vào những tài nguyên của truongtd trên IdP . Tuy nhiên, truongtd có thể ủy quyền cho RP bằng một thẻ truy cập (access token). Khi thẻ truy cập này được xác định là hợp lệ thì RP có thể truy cập được tài nguyên của ngư ời dùng truongtd . Để lấy và xác thực được một thẻ try cập thì trong mục 2.3.1 của luận văn sẽ mô tả chi tiết.

2.3.1 Giao thức OAuth

Trước khi bắt đầu tìm hiểu chi tiết giao thức OAuth, RP và IdP thống nhất sử dụng chung một cặp khóa để giao tiếp với nhau là: “consumer key” và “secret key” . Để có được cặp khóa này thì RP phải đăng ký với IdP. Trong đó:

 Consumer key: IdP sử dụng “consumer key” để xác định duy nhất một RP. Mỗi RP sẽ có một “consumer key” khác nhau.

 Secret key: Được RP và IdP sử dụng để tạo ra chữ ký mỗi khi có yêu cầu gửi từ RP tới IdP.

Chi tiết giao thức OAuth được thể hiện trong Hình 2.10 [14].

1. RP → IdP: RP gửi một yêu cầu tới IdP để lấy thẻ yêu cầu (request token). 2. IdP → RP: IdP trả lại cho RP một thẻ truy cập gồm: “token secret” và “token

key”. Thẻ yêu cầu này không có quy ền truy cập vào dữ liệu của người dùng trên IdP.

3. RP → UA → IdP: RP sử dụng thẻ yêu cầu đ ể chuyển hướng người dùng tới IdP. Mục đích của bước này là RP muốn sử dụng thẻ yêu cầu đ ể xin quyền truy cập vào dữ liệu người dùng trên IdP.

4. 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.

5. 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.

6. IdP → RP: IdP trả về cho RP một 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 dữ liệu của người dùng trên IdP.

7. RP → IdP: RP gửi lại oauth_verifier và thẻ yêu cầu lên IdP đ ể trao đổi lấy thẻ truy cập .