Cơ chế của OpenID

• Tổng quan về OpenID.

OpenID là một hệ thống đăng nhập một lần không có tính tập trung. Đối với những trang web có sử dụng OpenID thì người sử dụng không cần phải nhớ các thông tin về username và password cho riêng trang đó nữa. Thay vào đó họ chỉ cần đăng ký trước 1 tài khoản OpenID tại một trong những nhà cung cấp OpenID, hay thường gọi là i-broker. Do OpenID không mang tính tập trung nên bất kỳ trang web nào cũng có thể sử dụng được OpenID như là một cách đăng nhập cho người dùng. OpenID hiện đang được ứng dụng rộng rãi trong các trang web lớn như AOL, Facebook, Yahoo, gmail... Thêm vào đó, việc tích hợp hỗ trợ OpenID có mức ưu tiên cao trong bản Firefox 3. Microsoft cũng đang tiến hành phát triển OpenID 2.0 cho bản Windows Vista và windows 7 của họ. • Các thuật ngữ cơ bản của openID a. End-user: người dùng cuối b. Identifier or OpenID: là các URL hoặc XRI mà người dùng cuối dùng để xác thực danh tính cho họ c. Identity provider or OpenID provider( OP): là nhà cung cấp dịch vụ hoặc nhà cung cấp openid d. Relying party(RP): là các trang web để xác minh người dùng cuối sử dụng OpeniD e. User-agent: Các chương trình (chẳng hạn như một trình duyệt) được sử dụng bởi người dùng cuối để truy cập vào một nhà cung cấp OpenID hoặc RP.

Liên kết giữa các thành phần của OpenID a. Có ba thành phần chính trong bất kỳ hệ thống OpenID: Consumer, Identity Provider, và User Agent các thành phần này tương tác với nhau trong quá trình xác thực. i. Consumer: đó là trang web mà người đang đăng nhập, tương tác với các nhà cung cấp nhận dạng và các User agent (các trình duyệt web). Người dùng cuối sẽ đăng nhập vào các trang web sử dụng OpenID. Trong quá trình chứng thực, Consumer một vài tin nhắn trực tiếp đến OP với sự chuyển hướng thông điệp của HTTP.

OP sẽ gửi một URL đến người dùng cuối iii. trình duyệt sẽ là một nhân tố trung gian giữa OP và web site Consumer cho một số thông điệp khi lien kết giữa chúng.ii. Người dùng cuối cùng sẽ tương tác với Consumer và nhận dạng OP qua User agent. . Trong quá trình xác thực. Thông thường Consumer sẽ tương tác với trình duyệt tốt như OP trong quá trình xác thực. User agent là trình duyệt. Identity Provider : là một máy chủ chứa thông tin của người dùng cuối.

• Truyền dữ liệu ( Trực tiếp và gián tiếp): Có hai phương pháp cơ bản thông tin liên lạc giữa các thực thể khác nhau trong một hệ thống OpenID: truyền thông trực tiếp và gián tiếp. hai thực thể trực tiếp nói chuyện với nhau khác sử dụng giao thức HTTP. Trong cơ chế truyền thông trực tiếp. Phương thức HTTP POST được sử dụng cho truyền trực tiếp .Liên lạc giữa các thành phần khác nhau của hệ thống OpenID với URI nhận dạng và các nhà cung cấp nhận dạng trên cùng một máy Liên lạc giữa các thành phần khác nhau của hệ thống OpenID với URI và bản chat nhận diện nhà cung cấp được trên các máy khác nhau.

• Phương thức hoạt động của OpenID : Có hai chế độ hoạt động chính: chế độ Dumb và chế độ thông minh. Chế độ Dumb: Trong chế độ Dumb. Đăng nhập vào Consumer website .verisignlabs. những RP không duy trì trạng thái của kết nối. trình duyệt và OP. A. Điều này thực thể thứ ba thường là trình duyệt web.com The Consumer là kmasecurity.net 1. không thể được sử dụng một lần nữa . Rhông tin liên lạc gián tiếp có thể xảy ra thông qua HTTP hoặc qua chuyển hướng chuyển hướng mẫu HTML.Với các thông gián tiếp. hai thực thể nói chuyện với nhau thông qua một phần ba thực thể. Các bước chứng thực và đăng nhập ở nơi giao tiếp giữa Consumer. Các bước này được ánh xạ đồ họa như hình sau: Ví dụ: Identity provider là : pip. vì vậy bất kỳ thông tin đã được sử dụng trong một đăng nhập trước đó.

com )để bạn xác thực acc 3. B. 8. Trong thời khẳng định thành công. người dùng cuối sẽ đăng nhập vào trang web. nếu bạn đã đăng nhập vào các trang web cung cấp Identity trang web. phần này có thể được bỏ qua hoàn toàn. Nếu người dùng cuối chưa đăng nhập. Lưu ý rằng đây là truyền thông gián tiếp giữa các Identity Provider và consumer. Các phương thức HTTP GET được sử dụng trong bước này là tốt.pip. 7. 4. các tiêu dùng (kmasecurity. những người tiêu dùng (kmasecurity.com).net) sau đó sẽ phân tích cú pháp nó và xác định vị trí của Identity Provider (OpenID Server). Nhà Identity Provider (pip. những Consumer sau đó sẽ phân tích cú pháp nó và xác định vị trí của Identity Provider (OpenID Server). Nếu không có gì bất hợp. Sau khi lấy trang. Nếu không đăng nhập sẽ thất bại. tốt hơn một phiên SSL an toàn. verisignlabs. 6.2. Quá trình này còn được gọi là phân tích cú pháp khám phá. Sự khẳng định này sẽ đại diện hoặc một chứng thực thành công hay thất bại. Identity Provider sẽ gửi lại và yêu cầu đăng nhập Nhà cung cấp để quyết định làm thế nào để xác thực người dùng cuối. Trong một số trường hợp.com) sẽ trả lại sự khẳng định thông tin có chữ ký của mình cho Consumer (kmasecurity. 5. Consumer (kmasecurity ) sẽ thiết lập kết nối trực tiếp với Identity provider (Pip.net ) thông qua chuyển hướng trình duyệt. Các consumer sẽ xóa sạch các url nhận dạng và trả bạn về chỗ cũ và lấy thông tin từ khi bạn xác thực từ URL nhận dạng. Điều này là để kiểm tra tính hợp lệ của khẳng định trong trường hợp một User agent (hoặc một kẻ tấn công) đang cố gắng để lừa gạt. Điều này thông tin được nhúng bên trong các trang web HTML và chúng ta sẽ thảo luận về các trang đó ngay. Nó sẽ yêu cầu xác thực thông tin trực tiếp từ Identity Provider và so sánh nó với các thông tin khẳng định đã nhận được thông qua User Agent (web browser).verisignlabs. Trang web đó sẽ gửi cho bạn 1 url ( ví dụ rpip. Sau khi phân tích cú pháp.versignlabs. Chế độ thông minh .net) sau đó sẽ Sau khi lấy trang.

Bước 6: Identity Provider sẽ trả lại các thông tin khẳng định với mình chữ ký để người tiêu dùng thông qua trình duyệt chuyển hướng. Bước 3: Consumer web sẽ xóa sạch các url nhận dạng và lấy dữ liệu tự vị trí hiện tại của nó Bước 4: Sau khi lấy trang. tiêu dùng các phân tích nó và xác định vị trí của Identity Provider (OpenID Server). Nếu không đăng nhập sẽ thất bại. Nếu có một trận đấu ở bước trước. Bước 7: Sau một sự khẳng định thành công. cuối cùng Người dùng sẽ đăng nhập vào các trang web. người tiêu dùng có thể gửi Hiệp hội đề nghị với các nhà cung cấp nhận dạng và trao đổi chia sẻ quan trọng như trong 4a bước trên hình trên. Tùy chọn. Sự khẳng định này sẽ đại diện hoặc là xác thực thành công hay thất bại. các Identity provider có thể yêu cầu người dùng cuối để đăng nhập. các Người tiêu dùng sẽ chuyển hướng trình duyệt web để các nhà cung cấp nhận dạng để có được các thông tin khẳng định. Cơ chế xác thực của openID: . Bước 5: Nếu người dùng cuối không phải là đã đăng nhập vào để nhận dạng nhà cung cấp.Bước 1: Người dùng vào RP ( consumer) Bước 2: Các trang web sẽ có 1 form đăng nhập. Và người dùng tiến hành đăng nhập. Sau khi phân tích cú pháp. người tiêu dùng xác minh sự khẳng định sử dụng việc chia sẻ lưu trữ chính.

Các cơ chế được mô tả trong bản ghi nhớ OpenID này nhằm mục đích tái sử dụng đặc điểm kỹ thuật OpenID có sẵn ở một mức độ tối đa và do đó không thiết lập một chứng thực riêng biệt. sẽ tiếp tục đượcđược sử dụng. như sao chép từ các đặc điểm kỹ thuật 2. XMPP với mục tiêu của modules hóa và bảo mật lớp vì vậy dễ dàng bổ xung các cơ chế mới hơn. Dự kiến an ninh hiện tại lớp. là như sau: . và với sự liên quan ngữ nghĩa. toàn vẹn và cơ chế bảo mật. ý tưởng được rằng người dùng sẽ được chuyển hướng của RP vào một nhà cung cấp danh tính người xác thực người dùng.OpenID sử dụng cơ chế sác thực đơn giản và bảo mật lớp là sử dụng các giao thức lớp ứng dụng nhưu IMAP. chẳng hạn như Transport Layer Security (TLS). POP. Nếu không áp dụng cho trường hợp sử dụng cases HTTP: OpenID ban đầu được hình dung cho HTTP / HTML thông tin liên lạc dựa. và sau đó gửi thông tin nhận dạng và khác thuộc tính (hoặc trực tiếp hoặc gián tiếp) với RP. Các lưu lượng giao thức thực tế.0 OpenID. Hiện nay cơ chế này cho phép SASL và OpenID có sự ảnh hưởng lẫn nhau và khẳng định tính chất riêng. Vì vậy khi các máy chủ( phụ thuộc bên Consumer) quảng cáo SASL thì khách hàng sẽ chọn cơ chế openid.

3. RP xác minh các thông tin nhận từ OP bao gồm cả các kí tự URL được trả lại. Và chia sẻ các thuộc tính của OP cho RP. Cần lưu ý rằng bộ nhận dạng người dùng kèm có thể là một nhận dạng OP.1. website sử dụng OpenID single sing-on và OP sẽ bắt tay nhau và thành lập 1 hiệp hội bảo mật và được chia sẻ bằng cách sử dụng Diffie-Hellman Key Exchange. 4. . 6. OP provider sẽ sử dụng sự thiết lập trên để đồng ý những yêu cầu tiếp theo. Điều này loại bỏ sự cần thiết phải yêu cầu trực tiếp sau mỗi lần yêu cầu chứng thực : Yêu cầu và đáp ứng. website sử dụng openid chuyển hướng người dùng cuối của User-agent 5. OP xác thực người dùng và kết thúc khi người dùng đã xác thực. các RP thực hiện phát hiện trên đó và thiết lập Endpoint OP URL người dùng cuối sử dụng để xác thực. Sau khi bình thường hóa việc nhận dạng người sử dụng Cung cấp. mà cho phép lựa chọn một nhận dạng tuyên bố chủ quyền tại các OP hoặc cho giao thức để tiến hành mà không có một nhận dạng tuyên bố chủ quyền nếu có điều gì hữu ích khác đang được thực hiện thông qua phần mở rộng. xác nhận phát hiện thông tin. Người sử dụng khởi tạo chứng thực bằng việc đưa cung cấp nhận dạng cho RP qua sử dụng của User agent của họ 2. kiểm tra các nonce và xác nhận chữ ký điện tử bằng cách sử dụng hiệp hội ở bước 3 hoặc khi xem xét lưu lượng này trong môi trường của SASL. OpenID chuyển hướng người dùng của user-agent trở lại RP với sự chấp thuận hoặc thống báo đã xác thực hoặc chưa xác thực 7. Và sau đó website sử dụng OpenID sẽ chứng thực những thông điệp. Và RP và user phải thay đổi mã hóa để thi hành SASL.

Một bí mật được chia sẻ thành lập bằng cách sử dụng Diffie-Hellman Key Exchange. Khi xem xét lưu lượng này trong bối cảnh SASL. OpenID có hai phương pháp truyền thông gián tiếp. RP hoặc SASL server sẽ tiến hành quảng bá cơ chế SASL của OpenID cho khách hang 2. RP truyền một yêu cầu xác thực để các OP để có được một sự khẳng định trong các hình thức của một yêu cầu gián tiếp. khi RP và khách hàng cả hai đều phải thay đổi mã của họ để thi hành cơ chế SASL. điều này loại bỏ sự cần thiết cho các yêu cầu sau đó trực tiếp để xác minh chữ ký sau mỗi yêu cầu chứng thực / đáp ứng.0 có khả năng OP có thể được sử dụng một phương pháp mới được định nghĩa trong tài liệu này mà yêu cầu nội dung tin nhắn OpenID được mã hóa bằng cách sử dụng Universal Resource Idenitifier (URI) .*. 5. Để đảm bảo rằng một tiêu chuẩn OpenID 2. chúng tôi biểu lộ nhiều authentiction từ SASL Các bước được tiến hành như sau: 1. Bằng cách đó. Điều này sẽ được thảo luận dưới đây. Thông điệp này được chuyển qua khách hàng hơn là trực tiếp giữa các RP và OP. Trong tương tự. Do đó. chúng tôi lưu ý rằng không giống như một máy chủ web. máy chủ SASL đã có một số loại kỳ họp (có thể là một kết nối TCP) thành lập với khách hàng. RP và OP tùy chọn thiết lập một hiệp hội . Cả hai cơ chế không trực tiếp áp dụng cho sử dụng với SASL. Sau khi bình thường hóa việc nhận người dung . cụ thể là HTTP chuyển hướng và hình thức HTML trình. một dòng tương tự mà giao diện ba bên cần phải được tạo ra. các OP phải vẫn bị ảnh hưởng. các RP thực hiện phát hiện trên đó và thiết lập Endpoint OP URL mà người dùng sử dụng để xác thực. OP này sử dụng một hiệp hội để xác nhận tiếp theo tin nhắn và để RP xác minh những thông điệp. Khách hang khởi tạo một xác thực SASL sử dụng cung cấp nhận dạng tương tự như tùy chọn return_to 3. Tuy nhiên. nó có thể là cần thiết để chuyển hướng một khách hàng SASL để một ứng dụng khác. 4.

Bước này sẽ xảy ra trong SASL. cũng trong phạm vi đặc điểm kỹ thuật này. Các máy chủ SASL gửi một phản ứng SASL phù hợp với client. 9. Một lần nữa bước này xảy ra trong SASL. nếu không có hiệp hội đã được thành lập. 10. hoặc bởi các SASL client ứng dụng hoặc xử lý thích hợp. Các THỂ RP gửi một yêu cầu trực tiếp check_authentication OpenID cho OP. với các tùy chọn thuộc Registry đơn giản Open (SREG). Cách thức mà người sử dụng cuối cùng là chứng thực cho mình OP tương ứng và bất kỳ chính sách xung quanh xác thực như vậy là trong phạm vi của OpenID và do đó. URL này được chuyển đến các OP. Các client truyền qua HTTP chuyển hướng kết quả OP cho RP. 11. Các SASL ở client gửi một phản hồi trống. . 7. Các OP sẽ truyền tải thông tin về sự thành công hay thất bại của giai đoạn thẩm định lại cho RP. và các OP được dự kiến sẽ trả lời.6. Bước này sẽ xảy ra trong SASL. Tiếp theo client tùy chọn xác nhận cho OP và sau đó chấp thuận hoặc không chấp nhận chứng thực với OP. các ứng dụng máy khách phải xây dựng một URL có chứa các nội dung nhận được trong tin nhắn trước đây từ RP. một lần nữa bằng cách sử dụng một gián tiếp đáp ứng thông qua trình duyệt của client hoặc xử lý. Tại thời điểm này. như xác thựctiếp tục thông qua các dòng chảy OpenID bình thường. chẳng hạn như một trình duyệt 8.

theo quy định tại các đặc điểm kỹ thuật OpenID. “initial-response = Identifier UTF8NUL openid-version Identifier = URI | XRI . ." 1*DIGIT ] Cú pháp XRI được định nghĩa trong [XRI2. nó sẽ hiển thị tên "OpenID" trong danh sách cơ chế hỗ trợ SASL.0]. hỗ trợ phiên bản của OpenID được chỉ định. Bắt đầu: Một client bắt đầu một chứng thực OpenID với SASL của XRI hay URI. Identifer is specified in Sec.Tóm lược cơ chế: 1.2 of the OpenID 2. 2.0 Syntax URI is specified in RFC 3986. trong quá trình ứng dụng phiên họp bắt đầu. Quảng cáo: Để quảng cáo rằng một máy chủ hỗ trợ OpenID. Ngoài ra. openid-version = 1*DIGIT [ ". .0 spec. 7. XRI as specified by OASIS 2.

. Sự trả lời của server: RP bây giờ xác nhận các phản ứng mà nó nhận được từ khách hàng thông qua HTTP hoặc SSL. vắng mặt chương trình. Yêu cầu chứng thực: Các Server SASL gửi một thông báo OpenID có chứa một openid. Các client hàng bây giờ gửi có yêu cầu thông qua một HTTP GET để các OP. Dải "openid.error openid. Phản ứng của RP bao gồm một ứng dụng cụ thể .error_code và bất kỳ thông tin hữu ích khác chẩn đoán NÊN được bao gồm trong thất bại chứng thực . Điều trị các concatentation kết quả là tham số URI được phân cách bởi ambersand một (&) và mã hóa là một trong những sẽ là một cơ quan URI. và openid.com&fullname=Eliot%20Lear Nếu các giao thức ứng dụng cho phép. theo quy định tại các đặc điểm kỹ thuật OpenID.sreg. Tiến trình mã hóa như sau: 1. 4.mode của một trong hai "checkid_immediate" "checkid_setup". và đánh dấu các câu hỏi.3. 2.mã phản hồi cho biết thành công hay thất bại của chứng thực. Ví dụ : email=lear@example. như chuyển hướng để làm điều đó từ một máy chủ HTTP. Các Client phải xử lý cả hai xác thực người dùng và các OP xác nhận hoặc từ chối của authentiation của RP." từ mỗi tên của thuộc tính. Các Client phải xử lý cả hai xác thực người dùng và các OP xác nhận hoặc từ chối của authentiation của RP.

Sign up to vote on this title
UsefulNot useful