ĐỒ án môn học bảo mật THÔNG TIN NGHIÊN cứu HOẠT ĐỘNG OPENID

MỤC LỤC CHƯƠNG 1: TỔNG QUAN VỀ OPENID 1.1 Tổng quan 1.2 Lịch sử phát triển 1.3 Ứng dụng giải pháp công nghệ .3 1.3.1 Ứng dụng 1.3.2 Giải pháp 1.4 Các thành phần hệ thống quản lý định danh 1.5 Quy trình hoạt động hệ thống quản lý định danh CHƯƠNG 2: PHƯƠNG THỨC HOẠT ĐỘNG CỦA OPENID 2.1 Giao tiếp giữa thành phần hệ thống OpenID 2.2 Cơ chế hoạt động OpenID .3 2.2.1 Cơ chế Smart mode .3 2.2.1.1 Quy trình xác định thành phần Identity Provider .3 2.2.1.2 Quy trình gởi thuộc tính định danh 2.2.1.3 Quy trình kiểm tra thuộc tính định danh 2.2.2 Cơ chế Dumb mode 2.3 Cơ chế xác thực OpenID: 2.4 Ứng dụng thuật toán Diffie-Hellman 2.4.1 Mơ hình trao đổi khóa Diffie-Hellman 2.4.2 Tḥt tốn trao đổi khóa Diffie-Hellman 2.5 Sơ đồ quy trình giao tiếp giữa Client – Server .3 2.6 Quy trình xử lý bước giao tiếp CHƯƠNG 3: KẾT QUẢ THỰC NGHIỆM 3.1 Mơ hình triển khai thực nghiệm 3.1.1 Triển khai dịch vụ OpenID website NukeViet .3 3.1.2 Công cụ demo .3 3.2 Các bước thực 3.3 Kết đạt được 3.3.1 Client Hello 3.3.2 Server Hello, Certificate, Server Hello Done 3.3.3 Client Key Exchange 3.3.4 Change Cipher Spec 3.3.5 Application Data RP – OP 3.3.6 Application Data OP – RP 3.3.7 Encrypted Alert .3 3.3.8 Biểu đồ Flow tổng hợp bước giao tiếp giữa client server CHƯƠNG 4: KẾT LUẬN 4.1 Ưu điểm OpenID 4.1.1 Đối với Website nhà phát triển WebApp 4.1.2 Đối với người dùng cuối .3 4.2 Hạn chế OpenID 4.2.1 Triển khai OpenID 4.2.2 Bảo mật OpenID .3 PHỤ LỤC A PHỤ LỤC B TÀI LIỆU THAM KHẢO CHƯƠNG 1: TỔNG QUAN VỀ OPENID 1.1 Tổng quan OpenID dịch vụ định danh (Identify) chia sẻ, hệ thống đăng nhập lần khơng có tính tập trung, cho phép người sử dụng đăng nhập nhiều website khác định danh số, tránh việc sử dụng tài khoản mật khác cho website OpenID định chuẩn mở, miễn phí phân quyền cho phép người dùng điều khiển được thơng tin cá nhân cơng khai Internet Một OpenID dạng liên kết URL, URL tên miền website URL nhà cung cấp định danh OpenID Khi đăng nhập với tài khoản OpenID, bạn phải đăng nhập vào Nhà cung cấp dịch vụ định danh để kiểm tra tính hợp lệ tài khoản OpenID phương thức giúp bạn xác thực tài khoản đăng ký provider mà bạn tin tưởng cho phép người dùng thực việc đăng nhập vào lần sau 1.2 Lịch sử phát triển Phiên OpenID được phát triển vào tháng năm 2005 Brad Fitzpatrick, tác giả trang web cộng đồng LiveJournal, làm việc cho cơng ty Six Apart, ban đầu có tên Yadis (“Yet another distributed identity system": hệ thống đăng nhập phân tán), được gọi OpenID sau tên miền www.openid.net được trao cho Six Apart để sử dụng cho dự án Tháng 6/2005, thảo luận giữa người dùng cuối nhà phát triển từ công ty phần mềm NetMesh khả hợp tác giữa OpenID LID (Một giao thức tương tự được phát triển NetMesh) Kết hợp tác giao thức Yadis được phát triển giữ tên gọi OpenID Giao thức OpenID được công bố tháng 24/10/2005, sau hội thảo Internet Identity Workshop diễn vài ngày Tháng 12, nhà phát triển SXIP (Simple Extensible Identity Protocol) XRI (Một chuẩn nhận dạng Internet) bắt đầu tích hợp vào OpenID, thay nhận dạng URL ban đầu, OpenID phát triển thành chuận nhận dạng đầy đủ cho danh tính người sử dụng Phiên OpenID 2.0 xuất Ngày 31/1/2007, Symantec công bố hổ trợ OpenID trang dịch vụ sản phẩm Một tuần sau, ngày 6/2/2007, Microsoft kết hợp với JanRain, Sxip, VeriSign (Những tổ chức tham gia phát triển OpenID) tuyên bố hổ trợ OpenID xem xét khả tương tác giữa OpenID MS CardSpace (Một phương thức nhận dạng Microsoft), với việc xem xét vấn đề bảo mật cho phát triển OpenID Giữa tháng 2, AOL hổ trợ thử nghiệm OpenID OpenID sau được đại gia Yahoo, Google quan tâm, kéo theo mạng xã hội website có lượng người sử dụng lớn bắt đầu hổ trợ OpenID (Trở thành Provider WebApp hổ trợ OpenID) 1.3 Ứng dụng giải pháp công nghệ 1.3.1 Ứng dụng – Website, mạng xã hội, phần mềm lập trình, Ebank, Windows – Giúp người dùng dễ dàng đăng ký đăng nhập, thao tác xử lý nhanh đơn giản Hoàn toàn phụ thuộc vào việc lựa chọn nhà cung cấp dịch vụ từ phía người dùng tin cậy – Khả tích hợp, triển khai, chế quản lý bảo mật thông tin người dùng cao – Giải qút được tốn lập trình nhanh (kết nối chứng thực qua nhà dịch vụ cho việc xử lý đăng nhập) mà không cần xây dựng chức xử lý đăng nhập cục – Giúp người dùng dễ dàng sử dụng nhiều ứng dụng khác với tài khoản – Cho phép hệ thống sử dụng tài khoản có trước từ bên ngồi dùng tài khoản tạo bên hệ thống:  Chứng thực qua email: Địi hỏi người dùng sau đăng kí tài khoản site phải kích hoạt tài khoản thông qua email  Chứng thực tay: Tất tài khoản tạo người quản trị  Không chứng thực: Người dùng cần đăng kí tài khoản xong, khơng cần xác nhận qua email 1.3.2 Giải pháp OpenID giúp người dùng website xác thực quyền truy cập, cho phép người dùng đăng nhập vào những ứng dụng web khác định danh số (Digital Indentity) Giúp thay thế thủ tục đăng ký, xác thực, đăng nhập truyền thống bước đăng nhập 1.4 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 phong phú Mỗi hệ thống có danh sách thành phần, cách hoạt động, cách giao tiếp khác Tuy nhiên, hệ thống quản lý định danh thơng thường có thành phần: Hình 1.1 Các thành phần hệ thống định danh – Relying Party: dịch vụ sử dụng chế định danh để chứng thực Ví dụ, số trang web sử dụng chế đăng nhập người dùng để định danh trang zing, trang eplay Hiện có nhiều thành phần Relying Party mạng Phần lớn số hỗ trợ định danh hệ thống khác tài khoản email Yahoo hay Gmail Hình 1.2 Ví dụ thành phần Relying Party – Identity Provider (IdP): thành phần có nhiệm vụ quản lý thuộc tính định danh người dùng hệ thống IdP có chức truyền những thơng tin cần thiết để thực chứng thực đến Relying Party sau xác định người dùng sử dụng dịch vụ Hiện có nhiều hệ thống tiếng xây dựng thành phần Identity Provider cho riêng dựa chế hệ thống OpenID Google, Yahoo… – Identity Selector (IS): thành phần trung gian hệ thống, cầu nối giữa người dùng, Relying Party, Identity Provider Mọi hoạt động thành phần được điều khiển trực tiếp người dùng 1.5 Quy trình hoạt động hệ thống quản lý định danh Hình 1.3 Quy trình hoạt động hệ thống quản lý định danh Quy trình hệ thống quản lý định danh được minh họa Hình 1.3 bao gồm bước sau để thực trình chứng thực: – Bước 1: Người dùng cung cấp thông tin Identity Provider cho thành phần Identity Selector – Bước 2: Thành phần Identity Selector tự động giao tiếp với thành phần Relying Party Sau đó, Identity Selector truyền thơng tin Identity Provider người dùng cung cấp bước đến thành phần Relying Party – Bước 3: Thành phần Relying Party sử dụng thông tin người dùng cung cấp để kết nối với thành phần Identity Provider (thơng qua kênh truyền an tồn) Sau đó, Relying Party gởi danh sách tên thuộc tính cần thiết để thực định danh đến thành phần Identity Provider thơng qua kênh truyền an tồn được thiết lập – Bước 4: Thành phần Identity Provider tạo thuộc tính cần định danh mà thành phần Relying Party yêu cầu bước Sau đó, Identity Provider ký xác nhận thơng tin tạo chữ ký Cuối cùng, Identity Provider truyền thông điệp ký Identity Selector – Bước 5: Identity Selector lên thông tin định danh tương ứng Sau đó, người dùng kiểm tra thơng tin xác nhận có truyền những thuộc tính định danh đến Relying Party hay khơng – Bước 6: Các thuộc tính định danh được truyền đến Relying Party nếu người dùng xác nhận bước – Bước 7: Relying Party kiểm tra những thuộc tính định danh trả kết cho người dùng CHƯƠNG 2: PHƯƠNG THỨC HOẠT ĐỘNG CỦA OPENID 2.1 Giao tiếp giữa thành phần hệ thống OpenID OpenID cung cấp cho người dùng URI để đăng nhập vào những Relying Party khác URI đóng vai trị thuộc tính định danh được quản lý Identity Provider Sự giao tiếp giữa thành phần hệ thống OpenID với URI địa Identity Provider được thể hình 2.1 Hình 2.1 URI địa Identity Provider Tuy nhiên, URI không thiết phải địa Identity Provider Ví dụ, URI thật Identity Provider lưu máy khác hình 2.2 Trong trường hợp này, hệ thống phải sử dụng hệ thống Web Server Location of Identifier URI để xác định được địa URI thật Identity Provider Hình 2.2 URI khơng phải địa Identity Provider 2.2 Cơ chế hoạt động OpenID OpenID có hai chế giao tiếp Smart mode Dumb mode Hai chế được dựa khả Relying Party Trong chế độ Smart mode, Relying Party có khả lưu lại khóa chia sẻ bí mật cho việc chứng thực sau Ngược lại, chế độ Dumb mode, Relying Party khơng có khả lưu trữ thông tin nên phải thực thêm số bước để hồn tất q trình chứng thực 2.2.1 Cơ chế Smart mode Quy trình định danh hệ thống OpenID chế độ Smart Mode chia làm quy trình sau: – Quy trình xác định thành phần Identity Provider – Quy trình gởi thuộc tính định danh – Quy trình kiểm tra thuộc tính định danh 2.2.1.1 Quy trình xác định thành phần Identity Provider Hình 2.3 Quy trình xác định thành phần Identity Provider Quy trình xác định thành phần Identity Provider gồm bước hình 2.3: – Địa IP đích là: 124.108.121.156 – Giao thức hoạt động truyền dữ liệu http – Giao thức sử dụng server https – Chiều dài gói dữ liệu 96 bytes – Chuỗi mã hóa dữ liệu “d70a6e38b69059fadd…” 3.3.6 Application Data OP – RP Hình 3.32 Application Data OP – RP – – – – – Quy trình truyền nhận dữ liệu giữa server client Địa IP nguồn là: 124.108.121.156 Địa IP đích là: 192.168.1.3 Nội dung truyền tải ứng dụng data, chiều dài dữ liệu 32 bytes 464 bytes Chuỗi mã hóa dữ liệu “d70a6e38b69059fadd…” “462f8c68a8b63f1d8a34…” 3.3.7 Encrypted Alert Hình 3.33 Encrypted Alert – Thơng điệp kết thúc quy trình bắt tay giữa client server – Địa IP nguồn là: 124.108.121.156 – Địa IP đích là: 192.168.1.3 – Loại nội dung cảnh báo có chiều dài 32 bytes 3.3.8 Biểu đồ Flow tổng hợp bước giao tiếp giữa client và server Hình 3.34 Biểu đồ Flow tổng hợp bước giao tiếp giữa client server Quy trình được thực bắt đầu người dùng gửi yêu cầu chấp nhận nhà cung cấp dịch vụ OpenID IDP đáng tin cậy được lựa chọn WebApp bắt tay thỏa thuận trực tiếp với nhà cung cấp dịch vụ OpenID IDP thực thỏa thuận cho phép, xác thực chứng thực tài khoản đăng ký người dùng Nhà cung cấp dịch vụ OpenID IDP chứng thực tài khoản người dùng cung cấp thông tin tài khoản (tên tài khoản, mật khẩu, họ tên, email) WebApp quy định cấu trúc lập trình để thực lưu trữ trường dữ liệu mẫu vào sở dữ liệu Người dùng sau đăng nhập lần thực yêu cầu khác từ WebApp dùng tài khoản đăng nhập vào lần tiếp theo  Ghi chú: Quy trình được thực theo bước được thực thi lặp lặp lại để đảm bảo trình bắt tay giao tiếp giữa WebApp OpenID IPD được liên tục Q trình kết thúc người dùng hồn tất thủ tục đăng ký đăng nhập thành công vào WebApp CHƯƠNG 4: KẾT LUẬN Sự đời OpenID đồng thời đặt cho nhà phát triển những thách thức an ninh bảo mật, lợi dụng việc đăng nhạp OpenID tin tưởng người dùng để đánh cắp tài khoản Sau số vấn đề ứng dụng vào website 4.1 Ưu điểm OpenID 4.1.1 Đối với Website và nhà phát triển WebApp – Tăng tỷ lệ “khách viếng thăm” trở thành “thành viên”  Nghiên cứu Google cho thấy tỷ lệ người viếng thăm (Lần đầu vào WebApp) kích hoạt tài khoản những trang có sử dụng OpenID 90% việc trở thành “thành viên” đơn giản thực vài nhấp chuột thay phải điền q nhiều thơng tin xác thực địa email cách làm truyền thống – Giảm thất vọng người dùng việc nhớ mật  Đăng nhập OpenID trường OpenID URL người dùng cần nhớ thông tin thay phải ghi tên sử dụng, mật giấy, note… khơng cịn phải quan tâm tới link “click nếu quên mật khẩu” thường gặp nữa – Kết nối website tới mạng xã hội  Các mạng xã hội Yahoo Meme, Google Buzz, MySpace, Facebook… hổ trợ OpenID cho tất tài khoản họ, bạn tận dụng lượng người dùng này, quảng bá thông tin WebApp để thu hút lượng người dùng từ mạng xã hội Hơn nữa, bạn cịn tiếp cận với danh sách liên kết họ để tiến hành chiến dịch SEO – Mở khả kết nối với ứng dụng khác  Ví dụ: Q trình thâu tóm Google ứng dụng YouTube, OrKut, Blogger… phát triển tảng khác Nhưng tài khoản lập Google hay ứng dụng đăng nhập sử dụng được mà không gặp trở ngại nhờ sử dụng chế xác thực OpenID 4.1.2 Đối với người dùng cuối – Việc đăng ký trở nên dễ dàng Bỏ qua số bước bắt buộc nhiều thời gian, cảm thấy đơn giản để vào tài khoản Các thông tin người dùng cần thiết cho ứng dụng dần được bổ sung sau – Đơn giản vấn đề mật  Thay phải giấy bút cố gắng nhớ hết mật tất forum, blog, webapp… Người dùng cuối cần nhớ thơng tin OpenID URL – Có quyền quyết định nơi lưu trử thông tin cá nhân  Provider lưu trử số thông tin cá nhân bạn có quyền qút định lựa chọn Provider tin tưởng để lưu trử thông tin – Giảm thiểu rủi ro bảo mật  Quá trình xác thực Provider yêu cầu người dùng xác nhận cho phép WebApp truy cập thông tin Một số Provider tạo dấu điện tử để đề phịng cơng phishing Cùng với những biện pháp bảo mật khác OpenID ngày trở nên an toàn so với cách lưu trữ mật truyền thống 4.2 Hạn chế OpenID 4.2.1 Triển khai OpenID – Yêu cầu lớn Provider: với những public provider, phải đảm bảo server đủ mạnh để q trình xác thực diễn nhanh chóng, khơng nhiều thời gian người dùng cuối – Để triển khai provider, đòi hỏi developer phải am hiểu bảo mật web service Đảm bảo giao tiếp khơng bị cướp phiên giao dịch, an tồn trước kiểu công ăn cắp mật – Các provider khác lưu trử những thông tin khác nhau: OpenID đời năm 2005, Provider lớn Google, Yahoo, Windows Live đời từ lâu, thơng tin lưu trử người dùng provider không giống nhau, OpenID Foundation dần nâng cấp tiêu chuẩn phiên để đồng hóa tất provider 4.2.2 Bảo mật đối với OpenID – Một số ý kiến cho OpenID điểm yếu lừa đảo phishing (một kiểu giả dạng website để đánh cắp mật khẩu) Ví dụ, lúc vào WebApp có hổ trợ OpenID, chuyển đến trang yêu cầu xác thực username password provider giả Vậy họ bị hack pass provider giả mạo Và nổ lực chống tình trạng phishing, nhiều phương án được đưa xác nhận cho phép đăng nhập, dấu cho provider… tùy thuộc vào provider – Tháng 12/2008, nhóm phát triển OpenID ban hành sách xác thực mở rộng, yêu cầu tất provider phải cho người dùng quản lý phê chuẩn tất kết nối đến OpenID URL họ PHỤ LỤC A CÁC THƠNG ĐIỆP CỦA OPENID Để hồn thành trình chứng thực, thành phần OpenID phải trao đổi nhiều thông điệp khác Những thông điệp theo định dạng chuẩn, Relying Party Identity Provider phải tuân theo những định dạng để giao tiếp Mỗi thơng điệp có cặp (request response) Request response có những tập tham số khác Tùy vào loại thông điệp, Relying Party Identity Provider 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 HTTP GET dùng cho liên lạc gián tiếp) Sau số thông điệp được sử dụng 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 thơng điệp associate request để thiết lập khóa chia sẻ bí mật giữa Relying Party Identity Provider Thơng điệp được Relying Party gửi vào lúc Đây liên lạc trực tiếp giữa Relying Party Identity Provider nên HTTP POST được sử dụng cho thông điệp associate Relying Party gửi số tham số kèm với associate request Sau danh sách tham số associate request: – openid.ns: tham số tùy chọn Tham số dùng để khai báo phiên OpenID Nếu tham số openid.ns không được khai báo, hệ thống tự hiểu phiên OpenID OpenID Authentication Compatibility Mode – openid.mode: tham số dùng để phân biệt loại thơng điệp Có thể có giá trị “associate” – openid.assoc_type: tham số được dùng để thuật toán sử dụng để ký lên thơng điệp Ở có hai giá trị có là: “HMAC-SHA1” “HMACSHA256” – openid.session_type: được dùng để khai báo loại mã hóa được sử dụng thơng điệp để mã hóa khóa MAC (Message Authentication Code) Thuật tốn dùng khóa cá nhân với thông điệp đầu vào cho đoạn mã Trong OpenID hỗ trợ hai thuật toán “DH-SHA1“ “DHSHA256” Nếu giá trị tham số “no-encryption”, MAC khơng được mã hóa Điều nên sử dụng sử dụng kết nối SSL giữa Relying Party Identity Provider – openid.dh_modulus: tham số kèm với DH-SHA1 DH-SHA256 – openid.dh_gen: tham số kèm với DH-SHA1 DH-SHA256 – openid.dh_consumer_public: tham số kèm với DH-SHA1 DHSHA256 Ba tham số thơng số cho tḥt tốn DH-SHA1 DH-SHA256, chi tiết việc sinh giá trị cho tham số được nêu chi tiết RFC-2631 (DiffieHellman Key Agreement Method) Bảng A.1 ví dụ thơng điệp associate request  Bảng A.1 Ví dụ về 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ả thông điệp HTTP 200 được định nghĩa Hypertext Transfer Protocol [RFC 2616] Thông điệp kết hợp giữa Identity Provider 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 bao gồm xử lý thông điệp thời gian sống xử lý tính giây Ngược lại, lỗi được trả Danh sách tham số associate response: – openid.ns: được giải thích – openid.assoc_handle: tham số chuỗi ASCII với chiều dài tối đa 255 ký tự được dùng để quyết định khóa được sử dụng lại cho trình mã hóa giải mã – openid.session_type: tham số giống trường hợp request nếu kết hợp thành công Ngược lại, tham số “unsuccessful response” Có nhiều lý khác cho việc kết hợp khơng thành cơng Ví dụ, Relying Party u cầu sử dụng SHA256 Identity Provider hỗ trợ SHA1 – openid.assoc_type: tham số giống trường hợp request nếu kết hợp thành công Ngược lại, tham số “unsuccessful response” – openid.expires_in: tham số thời gian (tính giây) kết hợp khơng cịn hiệu lực nữa Relying Party nên yêu cầu kết hợp – openid.mac_key: tham số được sử dụng giá trị “openid.session_type” “no-encryption” Giá trị tham số khóa MAC mã hóa dựa số 64 – openid.dh_server_public: tham số khóa cơng cộng Identity Provider Tham số đượ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ố 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 ví dụ về thơng điệp associate response  Thông điệp checkid_setup checkid_immediate request: Những thông điệp checkid_immediate 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 được khởi tạo Relying Party Giao tiếp gián tiếp được sử dụng những thông điệp nên Relying Party sử dụng phương thức HTTP GET thay cho phương thức HTTP POST để gởi nhận thông điệp Như vậy, thông điệp ngang qua trình duyệt web Thơng điệp checkid_immediate checkid_setup giống khác trường hợp sử dụng Thông điệp checkid_immediate thường được sử dụng Relying Party hỗ trợ jax thông điệp checkid_setup thường được sử dụng Relying Party không dùng Ajax Danh sách tham số checkid_setup request: – openid.ns: được giải thích – openid.mode: có giá trị “checkid_setup” – openid.claimed_id: tham số tùy chọn dùng để identifier được yêu cầu Tham số “openid.claimed_id” “openid.identiy” thường với Nếu khơng có tham số diện, thông điệp không chứa thông tin identifier mà chứa thông tin payload sử dụng mở rộng (Extensions) – openid.identity: tham số tùy chọn khác Nếu OP Local Identifier khác không được xác định, identifier được yêu cầu phải được sử dụng giá trị openid.identity – openid.assoc_handle: tham số tùy chọn Tham số kết hợp được khởi tạo giữa OpenID Relying Party Tham số được miêu tả phần associate request – openid.return_to: tham số được sử dụng để khai báo cho máy chủ OpenID vị trí UR nơi chuyển tiếp cho trình duyệt sau xử lý yêu cầu Máy chủ OpenID sử dụng địa UR để gởi response cho Relying Party – openid.realm: tham số tùy chọn khác URL máy chủ sử dụng để định danh Relying Party cách Realm bao gồm ký tự wildcard “*” Ví dụ, realm http://*.conformix.com  Bảng A.3 ví dụ về thơng điệp checkid_setup request  Thông điệp checkid_setup checkid_immediate response Mỗi lần máy chủ OpenID nhận thông điệp checkid_setup, OpenID xử lý gởi phản hồi cho Relying Party thông qua trình duyệt Trong thơng điệp phản hồi, OpenID gởi nhiều tham số cho Relying Party Danh sách tham số checkid_setup response: – openid.ns: được giải thích – openid.mode: có giá trị “id_res” kết hợp thành công Ngược lại mang – – – – giá trị:  “setup_needed” request checkid_immediate  “cancel” request checkid_setup openid.op_endpoint: URL máy chủ OpenID openid.claimed_id: được giải thích openid.identity: được giải thích openid.return_to: tham số chép URL Relying Party gởi với thông điệp request – openid.response_nonce: tham số được sử dụng để tránh công replay được dùng đơn cho thông điệp, có chiều dài tối đa 255 ký tự, bao gồm nhãn thời gian ký tự ASCII thêm vào để trở thành đơn Relying Party từ chối kết hợp nếu nhãn thời gian xa so với thời điểm Ngày được định dạng phần 5.6 [RFC3339] (Klyne, G and C Newman, “Date and Time on the Internet: Timestamps”) với quy ước sau:  Nằm múi 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 xử lý (handle) gắn với request có hay khơng Nếu khơng đúng, tham số tùy chọn Mặt khác, xử lý sai nên được gắn với tham số giúp cho Relying Party loại bỏ xử lý sai từ record Relying Party – openid.assoc_handle: handle được dùng để ký thơng điệp Handle khác với handle gốc được Relying Party gởi với request nếu OpenID không nhận handle gốc Trong trường hợp này, máy chủ giữ chép handle để Relying Party sử dụng cho mục đích kiểm tra – openid.signed: bao gồm danh sách tham số được ký Các tham số cách dấu phẩy – openid.sig: bao gồm chữ ký được mã hóa dựa số 64  Bảng A.4 ví dụ về thông điệp checkid_setup response  Thông điệp check_authentication response Các thông điệp check_authentication request response 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ắn những người công không gởi thông điệp xác thực giả mạo OpenID Server Do thông điệp được sử dụng trình giao tiếp trực tiếp giữa Relying Party OpenID Server nên phương thức HTTP POST được sử dụng Đối với thông điệp check_authentication cần lưu ý số vấn đề sau: – Thông điệp không được gởi nếu tồn kết hợp giữa Relying Party OpenID Server (đã trao đổi khóa chia sẻ dùng để ký thơng điệp) – Relying Party gởi tham số “openid.assoc_handle” request OpenID Server gởi ngược lại handle response để Relying Party biết OpenID Server đồng ý sử dụng handle kết hợp tồn trường hợp có kết hợp tồn được sử dụng – Nếu OpenID Server không đồng ý sử dụng handle kết hợp được cung cấp Relying Party, thông điệp response bao gồm tham số “openid.invalidate_handle” tham số “openid.assoc_handle” khác Sau đó, Relying Party sử dụng thông điệp check_authentication để xác nhận tính hợp lệ việc xác thực – Khi chế độ dumb mode được sử dụng, Relying Party trạng thái stateless không lưu trữ thông tin handle kết hợp trước nên thơng điệp check_authentication request luôn được sử dụng Danh sách tham số check_authentication request: – openid.mode: có giá trị “check_authentication” – Các tham số lai giống với checkid_setup response  Bảng A.5 Ví dụ về thông điệp check_authentication request  Thông điệp check_authentication response Danh sách tham số check_authentication response: – openid.ns: được giải thích – is_valid: tham số có giá trị “true” “false” để xác định chữ ký việc xác thực tính hợp lệ request – invalidate_handle: tham số tùy chọn được sử dụng trường hợp tham số is_valid mang giá trị “true”, Relying Party loại bỏ handle từ danh sách handle lưu trữ  Bảng A.6 Ví dụ về thơng điệp check_authentication response Để tăng tính linh hoạt vả tương thích, số mở rộng (extension) OpenID được đề xuất Một số mở rộng hoàn thiện số khác giai đoạn phác thảo, thử nghiệm Những thông tin mở rộng xem http://openid.net/developers/specs Những mở rộng phát triển có chức giải quyết công việc sau: – Đăng ký người dùng (User Registration): cho phép Relying Party đăng ký người dùng họ đăng nhập lần vào website – Tra cứu khóa dịch vụ (OpenID Service Key Discovery) sử dụng Yadis – Thông điệp DTP (DTP Message), được mã hóa MIME – Trao đổi thuộc tính (Attribute Exchange) – Độ tin cậy xác thực (Assertion Quality) – Quản lý sách chứng thực Identity Provider (Provider Authentication Policy Extension – PAPE), dùng để chống giả mạo (anti-phishing) 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 ví dụ việc sử dụng 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 kèm với việc cung cấp email URL Identity PHỤ LỤC B DANH SACH CAC HÊ THÔNG HÔ TRƠ OPENID TỔ CHỨC ĐỊNH DANH URL Google https://www.google.com/accounts/o8/id Yahoo! me.yahoo.com Microsoft LiveJournal accountservices.passport.net username.livejournal.com MySpace myspace.com/username WordPress username.wordpress.com username.blogger.com Blogger blogid.blogspot.com Verisign username.pip.verisignlabs.com Typepad blogname.typepad.com MyOpenID username.myopenid.com Lanchpad launchpad.net/~username claimID claimid.com/username openid.orange.fr/username Orange orange.fr/ Tonido OpenID Steam http://username.tonidoid.com/app/openid steamcommunity.com/openid/ TÀI LIỆU THAM KHẢO [1] http://nukeviet.vn/ [2] https://tools.ietf.org/html/draft-ietf-kitten-sasl-openid-08 [3] http://www.lifewiki.net/openid/OpenIDSpecification [4] Tài liệu Internet ... nhớ thơng tin OpenID URL – Có quyền qút định nơi lưu trử thông tin cá nhân  Provider lưu trử số thơng tin cá nhân bạn có quyền quyết định lựa chọn Provider tin tưởng để lưu trử thông tin – Giảm... lâu, thông tin lưu trử người dùng provider không giống nhau, OpenID Foundation dần nâng cấp tiêu chuẩn phiên để đồng hóa tất provider 4.2.2 Bảo mật đối với OpenID – Một số ý kiến cho OpenID. .. được sử dụng 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