Để hoàn thành quá trình chứng thực, các thành phần trong OpenID sẽ phải trao đổi nhiều thông điệp khác nhau. Những thông điệp này đều theo một định dạng chuẩn,
Relying Party và Identity Provider phải tuân theo những định dạng này để giao tiếp. Mỗi thông điệp sẽ có một cặp (request và response). Request và response có thể có những tập tham số khác nhau. Tùy vào loại thông điệp, Relying Party và Identity Provider sẽ sử dụng phương pháp liên lạc trực tiếp hay gián tiếp (HTTP POST dùng cho liên lạc trực tiếp và HTTP GET dùng cho liên lạc gián tiếp).
Sau đây là một số các thông điệp cơ bản được sử dụng trong hệ thống OpenID:
– Thông điệp associate.
– Thông điệp checkid_immediate.
– Thông điệp checkid_setup.
– Thông điệp check_authentication.
Thông điệp associate request
Thông điệp asscociate request được gửi từ Relying Party tới Identity Provider. Mục đích chính của thông điệp associate request là để thiết lập một khóa chia sẻ bí mật giữa Relying Party và Identity Provider. Thông điệp này có thể được Relying Party gửi vào bất
cứ lúc nào. Đây là một liên lạc trực tiếp giữa Relying Party và Identity Provider nên HTTP POST được sử dụng cho thông điệp associate. Relying Party sẽ gửi một số các tham số kèm với associate request. Sau đây là danh sách các tham số của associate request:
– openid.ns: đây là một tham số tùy chọn. Tham số này dùng để khai báo phiên bản OpenID. Nếu tham số openid.ns không được khai báo, hệ thống sẽ tự hiểu phiên bản của OpenID là OpenID Authentication Compatibility Mode.
– openid.mode: tham số này dùng để phân biệt loại thông điệp. Có thể ở đây sẽ có giá trị là “associate”.
– openid.assoc_type: tham số này được dùng để chỉ ra thuật toán sử dụng để ký lên thông điệp. Ở đây có hai giá trị có thể có là: “HMAC-SHA1” và “HMAC- SHA256”.
– openid.session_type: được dùng để khai báo loại mã hóa được sử dụng trong thông điệp để mã hóa khóa MAC (Message Authentication Code). Thuật toán sẽ dùng một khóa cá nhân cùng với một thông điệp như đầu vào và cho ra một đoạn mã. Trong OpenID hỗ trợ hai thuật toán “DH-SHA1“ và “DH- SHA256”. Nếu giá trị của tham số này là “no-encryption”, MAC sẽ không được mã hóa. Điều này chỉ nên sử dụng khi sử dụng một kết nối SSL giữa Relying Party và Identity Provider.
– openid.dh_modulus: tham số đi kèm với DH-SHA1 hoặc DH-SHA256.
– openid.dh_gen: tham số đi kèm với DH-SHA1 hoặc DH-SHA256.
– openid.dh_consumer_public: tham số đi kèm với DH-SHA1 hoặc DH- SHA256.
Ba tham số trên là các thông số cho thuật toán DH-SHA1 và DH-SHA256, chi tiết về việc sinh ra giá trị cho các tham số này được nêu chi tiết trong RFC-2631 (Diffie- Hellman Key Agreement Method). Bảng A.1 là một ví dụ về thông điệp associate request.
Bảng A.1 Ví dụ về một thông điệp associate request
Thông điệp associate response
Thông điệp associate response được gởi từ Identity Provider đến Relying Party. Đây lả một thông điệp HTTP 200 được định nghĩa trong Hypertext Transfer Protocol [RFC 2616]. Thông điệp này chỉ ra sự kết hợp giữa Identity Provider và Relying Party thành công hay thất bại. Trong trường hợp kết hợp thành công, thông điệp sẽ bao gồm một xử lý thông điệp và thời gian sống của xử lý đó tính bằng giây. Ngược lại, một lỗi sẽ được trả về. Danh sách các tham số của associate response:
– openid.ns: đã được giải thích ở trên.
– openid.assoc_handle: tham số này chỉ ra một chuỗi ASCII với chiều dài tối đa 255 ký tự được dùng để quyết định khóa nào sẽ được sử dụng lại cho quá trình mã hóa và giải mã.
– openid.session_type: tham số này giống như trong trường hợp request nếu kết hợp thành công. Ngược lại, tham số này sẽ là “unsuccessful response”. Có nhiều lý do khác nhau cho việc kết hợp không thành công. Ví dụ, Relying Party yêu cầu sử dụng SHA256 nhưng Identity Provider chỉ hỗ trợ SHA1.
– openid.assoc_type: tham số này giống như trong trường hợp request nếu kết hợp thành công. Ngược lại, tham số này sẽ là “unsuccessful response”.
– openid.expires_in: tham số này chỉ ra thời gian (tính bằng giây) sự kết hợp này sẽ không còn hiệu lực nữa và Relying Party nên yêu cầu một sự kết hợp mới.
– openid.mac_key: tham số này được sử dụng chỉ khi giá trị của
“openid.session_type” là “no-encryption”. Giá trị của tham số này là khóa MAC mã hóa dựa trên cơ số 64.
– openid.dh_server_public: tham số này là khóa công cộng của Identity
Provider. Tham số này được sử dụng nếu request yêu cầu sử dụng thuật toán Diffie-Hellman.
– openid.enc_mac_key: tham số này là khóa MAC đã được mã hóa, được sử dụng nếu request yêu cầu sử dụng thuật toán Diffie-Hellman.
Bảng A.2 là một ví dụ về thông điệp associate response.
Thông điệp checkid_setup và checkid_immediate request:
Những thông điệp checkid_immediate và checkid_setup được sử dụng để lấy thông tin xác nhận từ máy chủ OpenID. Những thông điệp này được khởi tạo bởi Relying Party. Giao tiếp gián tiếp được sử dụng trong những thông điệp này nên Relying Party sẽ sử dụng phương thức HTTP GET thay cho phương thức HTTP POST để gởi và nhận thông điệp. Như vậy, các thông điệp sẽ đi ngang qua trình duyệt web. Thông điệp checkid_immediate và checkid_setup khá giống nhau chỉ khác nhau ở trường hợp sử dụng. Thông điệp checkid_immediate thường được sử dụng bởi các Relying Party hỗ trợ
jax trong khi thông điệp checkid_setup thường được sử dụng bởi các Relying Party không dùng Ajax. Danh sách các tham số của checkid_setup request:
– openid.ns: đã được giải thích ở trên.
– openid.mode: có giá trị “checkid_setup”.
– openid.claimed_id: đây là một tham số tùy chọn dùng để chỉ ra các identifier được yêu cầu. Tham số “openid.claimed_id” và “openid.identiy” thường đi cùng với nhau. Nếu không có tham số nào hiện diện, thông điệp này không chứa thông tin về identifier mà chỉ chứa các thông tin trong payload sử dụng các mở rộng (Extensions).
– openid.identity: đây là một tham số tùy chọn khác. Nếu một OP Local
Identifier khác không được xác định, các identifier được yêu cầu phải được sử dụng như giá trị của openid.identity.
– openid.assoc_handle: tham số này là tùy chọn. Tham số này chỉ ra một sự kết hợp đã được khởi tạo giữa OpenID và Relying Party. Tham số này đã được miêu tả trong phần associate request.
– openid.return_to: tham số này được sử dụng để khai báo cho máy chủ OpenID vị trí của UR nơi sẽ chuyển tiếp cho trình duyệt sau khi xử lý yêu cầu. Máy chủ OpenID sẽ sử dụng địa chỉ UR này để gởi response về cho Relying Party.
– openid.realm: một tham số tùy chọn khác chỉ ra một URL máy chủ sử dụng để định danh một Relying Party trong một cách duy nhất. Realm có thể bao gồm các ký tự wildcard như “*”. Ví dụ, realm có thể là
http://*.conformix.com.
Thông điệp checkid_setup và checkid_immediate response
Mỗi lần máy chủ OpenID nhận thông điệp checkid_setup, OpenID sẽ xử lý và gởi phản hồi về cho Relying Party thông qua trình duyệt. Trong thông điệp phản hồi, OpenID sẽ gởi nhiều tham số về cho Relying Party. Danh sách các tham số của checkid_setup response:
– openid.ns: đã được giải thích ở trên.
– openid.mode: có giá trị “id_res” khi kết hợp thành công. Ngược lại sẽ mang giá trị:
• “setup_needed” khi request là checkid_immediate.
• “cancel” khi request là checkid_setup.
– openid.op_endpoint: chỉ ra URL máy chủ OpenID.
– openid.claimed_id: đã được giải thích ở trên.
– openid.identity: đã được giải thích ở trên.
– openid.return_to: tham số này là bản sao chép của URL Relying Party đã gởi với thông điệp request.
– openid.response_nonce: tham số này được sử dụng để tránh các tấn công replay và được dùng đơn nhất cho mỗi thông điệp, có chiều dài tối đa 255 ký tự, bao gồm một nhãn thời gian và các ký tự ASCII thêm vào để trở thành đơn nhất. Relying Party có thể từ chối kết hợp nếu nhãn thời gian quá xa so với thời điểm hiện tại. Ngày và giờ được định dạng trong phần 5.6 của
[RFC3339] (Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps”) với các quy ước sau:
• Nằm trong múi giờ của UTC được nhận biết với ký tự “Z”.
• Không được phép có phân số.
• Ví dụ: 2012-05-15T17:11:51ZUNIQUE.
– openid.invalidate_handle: được sử dụng khi xử lý (handle) gắn với request có đúng hay không. Nếu không đúng, tham số này là tùy chọn. Mặt khác, các xử lý sai nên được gắn với tham số này sẽ giúp cho Relying Party loại bỏ các xử lý sai từ các record của Relying Party.
– openid.assoc_handle: handle được dùng để ký thông điệp. Handle này có thể khác với handle gốc được Relying Party gởi với request nếu OpenID không nhận ra handle gốc. Trong trường hợp này, máy chủ sẽ giữ một bản sao chép của handle mới để Relying Party có thể sử dụng cho mục đích kiểm tra.
– openid.signed: bao gồm danh sách các tham số được ký. Các tham số cách nhau bởi dấu phẩy.
– openid.sig: bao gồm chữ ký được mã hóa dựa trên cơ số 64.
Thông điệp check_authentication response
Các thông điệp check_authentication request và response là công cụ cần thiết cho việc kiểm tra thông tin xác thực nhận được từ Relying Party để chắc chắn rằng những người tấn công không gởi các thông điệp xác thực giả mạo OpenID Server. Do các thông điệp này được sử dụng trong quá trình giao tiếp trực tiếp giữa Relying Party và OpenID Server nên phương thức HTTP POST sẽ được sử dụng. Đối với các thông điệp
check_authentication cần lưu ý một số vấn đề sau:
– Thông điệp này không được gởi đi nếu đã tồn tại sự kết hợp giữa Relying Party và OpenID Server (đã trao đổi khóa chia sẻ dùng để ký thông điệp)
– Relying Party sẽ gởi tham số “openid.assoc_handle” trong request và OpenID Server sẽ gởi ngược lại cùng một handle trong response để Relying Party biết rằng OpenID Server đồng ý sử dụng handle kết hợp đang tồn tại trong trường hợp có một sự kết hợp đang tồn tại được sử dụng.
– Nếu OpenID Server không đồng ý sử dụng handle kết hợp được cung cấp bởi Relying Party, thông điệp response sẽ bao gồm tham số
“openid.invalidate_handle” và một tham số “openid.assoc_handle” khác. Sau đó, Relying Party sẽ sử dụng thông điệp check_authentication để xác nhận tính hợp lệ của việc xác thực.
– Khi chế độ dumb mode được sử dụng, Relying Party luôn ở trạng thái stateless và không lưu trữ bất kỳ thông tin nào của handle kết hợp trước đó nên thông điệp check_authentication request sẽ luôn luôn được sử dụng. Danh sách các tham số của check_authentication request:
– openid.mode: có giá trị “check_authentication”.
– Các tham số còn lai giống với checkid_setup response.
Thông điệp check_authentication response
Danh sách các tham số của check_authentication response:
– openid.ns: đã được giải thích ở trên.
– is_valid: tham số có giá trị “true” hoặc “false” để xác định chữ ký của việc xác thực tính hợp lệ của request.
– invalidate_handle: tham số tùy chọn được sử dụng trong trường hợp tham số is_valid mang giá trị “true”, Relying Party sẽ loại bỏ handle từ danh sách các handle đã lưu trữ.
Bảng A.6 Ví dụ về một thông điệp check_authentication response
Để tăng tính linh hoạt vả tương thích, một số mở rộng (extension) của OpenID đã được đề xuất. Một số mở rộng đã hoàn thiện trong khi một số khác còn đang trong giai đoạn phác thảo, thử nghiệm. Những thông tin mới nhất về các mở rộng có thể xem tại đây http://openid.net/developers/specs.
Những mở rộng đã và đang phát triển có chức năng giải quyết các công việc sau:
– Đăng ký người dùng (User Registration): cho phép Relying Party đăng ký người dùng mới khi họ đăng nhập lần đầu tiên vào một website.
– Tra cứu khóa dịch vụ (OpenID Service Key Discovery) sử dụng Yadis.
– Trao đổi thuộc tính (Attribute Exchange).
– Độ tin cậy của xác thực (Assertion Quality).
– Quản lý chính sách chứng thực của Identity Provider (Provider
Authentication Policy Extension – PAPE), dùng để chống giả mạo (anti- phishing) và những mục đích khác.
Bảng A.7 Một thông điệp checkid_setup request với Simple Registration Extension
Bảng A.7 đưa ra một ví dụ về việc sử dụng một checkid_setup request kèm với mở rộng Simple Registration để Relying Party yêu cầu Identity Provider chứng thực URL Identity này kèm với việc cung cấp email của URL Identity này.