1. Trang chủ >
  2. Công Nghệ Thông Tin >
  3. Quản trị Web >

OpenID hoạt động như thế nào?

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (502.75 KB, 13 trang )


5.



-



-



-



6.

7.

8.

9.

10.

-



-



-



-



Consumer tìm trong tài liệu này một liên kết tới OpenID

Server, sau đó chuyển hướng User Agent đến đó và cung cấp

thêm vài tham số bổ sung:

openid.mode = checkid_setup : chọn mode dumb, mode này

có nghĩa là Consumer sẽ chuyển hướng User Agent đến

OpenID Server để kiểm tra danh tính của End User. OpenID

Server sẽ trả lời cho Consumer thông qua User Agent sau khi

kiểm tra xong.

openid.identity = http://openid.example.com/User : đây là

danh tính cung cấp bởi End User và OpenID Server phải xác

minh danh tính này cho Consumer.

openid.return_to = http://consumer.example.com/login.cgi?

session_id=User&nonce=123456 : Đây là nơi Consumer

muốn User Agent đến sau khi OpenID Server xác thực xong.

OpenID Server cũng sẽ thêm vài tham số bổ sung để xác

thực người đang trả lời cho Consumer chính là OpenID.

OpenID Server gửi về màn hình đăng nhập cho User.

User gửi ID và mật khẩu đến OpenID Server (phương thức

POST).

OpenID Server gửi về một form trust hỏi User có muốn tin

tưởng cho Consumer dùng danh tính của anh ta.

User Agent POST phản hồi cho OpenID Server (chấp nhận

hoặc không chấp nhận).

OpenID Server chuyển hướng User Agent đến Consumer.

Cung cấp thêm vài thông số sau:

openid.mode = id_res : Giá trị “id_res” chỉ ra rằng OpenID

Server khẳng định End User thực sự sở hữu danh tính này.

Nó sẽ là “cancel” nếu End User không chấp nhận tin tưởng

Consumer.

openid.return_to = http://consumer.example.com/login.cgi?

session_id=User&nonce=123456 : trang thông báo trạng

đăng nhập thành công hay thất bại, nơi mà User Agent sẽ

được chuyển đến sau khi xác thực xong.

openid.signed = mode,identity,return_to : những thông số

mà OpenID Server sẽ “ký” để chứng minh cho Consumer đây

đích thực là OpenID Server của End User.

openid.assoc_handle = *opaque handle* : bộ xử lý mã hóa

của OpenID Server, tạo ra một khóa để dùng cho openid.sig.

openid.sig = *base 64 encoded HMAC signature*: các thông

số mode, identity, return_to được OpenID Server mã hóa

bằng thuật tốn tạo chữ ký HMAC-SHA1 dùng khóa từ bộ xử



11.



12.



13.





lý mã hóa ở trên. Nhằm mục đích “ký” các thơng số này rồi

gửi đến Consumer.

Sau khi OpenID chuyển hướng User Agent đến Consumer và

gửi kèm thêm các thơng số bổ sung để xác nhận danh tính

End User và danh tính của mình bằng cách ký các thơng số

đó. Nhưng Consumer khơng thể tự mình kiểm tra cái “chữ

ký” này và các thông số này đều đến từ End User, có thể nó

đã được hacker chỉnh sửa nhằm xâm nhập vào tài khoản của

End User. Vì vậy Consumer lại chuyển công việc lại cho

OpenID Server, Consumer POST đến OpenID Server rồi gửi

các thông số:

openid.mode = check_authentication: mode này muốn hỏi

OpenID Server liệu đây có đúng là End User không.

openid.signed = mode,identity,return_to: các thông số mà

User bảo OpenID Server đã ký.

openid.assoc_handle = *opaque handle*: bộ xử lý mà User

đã gửi cho Consumer

openid.sig = *base 64 encoded HMAC signature*: “chữ ký”

của OpenID Server xác nhận đây chính là End User.

openid.* = everything else: những thông số đã “ký” (trừ

mode)

Khi OpenID Server nhận được yêu cầu này, nó lấy chữ ký từ

các thơng số đã ký trước đó so sánh với các thông số nhận

được từ Consumer. Nếu khớp nhau, OpenID Server biết là

đây chính là những tham số mà mình đã ký và gửi một thơng

báo cho cho Consumer biết thông tin này hợp lệ: "is_valid:

true". Nếu chữ ký khơng hợp lệ thì OpenID Server trả về

thơng báo "is_valid: false" và Consumer biết được là có kẻ

đang cố tình giả mạo End User.

Consumer gửi cho End User một trang thông báo đăng nhập

thành công hay thất bại, dựa vào kết quả của các bước trên.

Trong trường hợp Consumer không yêu cầu OpenID Server

tương tác với End User, trong tham số gửi đi ở bước 5,

“openid.mode” sẽ là “checkid_immediate”. Điều này cho

phép User Agent bật lên một cửa sổ web mới "openid.user \

_setup \ _url" để End User xác thực với OpenID Server bằng

cách đăng nhập, sau đó gửi kết quả xác thực về cho

Consumer trên phiên làm việc của cửa sổ này thay vì phải

chuyển hướng User Agent. Việc này giúp trải nghiệm của

End User trên trang web mượt mà, không bị ngắt quãng.



b. Smart mode:

Ở dumb mode, mỗi lần End User cần xác thực, OpenID Server gửi

cho Consumer các tham số để xác thực End User và chứng minh

OpenID Server là “chính chủ” thơng qua User Agent (ở bước 10).

Do Consumer không thể xử lý các thông số này vì nó đã được bộ

xử lý của OpenID Server mã hóa, nên Consumer phải trực tiếp gửi

lại các tham số này cho OpenID Server để xác nhận lại chúng.

Việc nay làm tốn khá nhiều CPU của cả OpenID Server và

Consumer. Nếu Consumer và OpenID Server cùng chia sẻ bộ xử lý

mã hóa này thì cả hai sẽ đỡ tốn rất nhiều tài nguyên.



Đó là smart mode, Consumer thiết lập một bộ xử lý mã hóa dùng

chung với OpenID Server. Việc chia sẻ thiết lập này được thực hiện

bất kỳ lúc nào, không nhất thiết phải chờ End User cần xác thực

mới thiết lập (trong ví dụ này chúng sẽ thiết lập ở bước 5).

Consumer sẽ gửi một request POST tới OpenID Server để tiến

hành thiết lập:

-



-



-



openid.mode = associate: mode associate, có nghĩa là

Consumer muốn thiết lập một bộ mã hóa dùng chung với

OpenID Server.

openid.assoc_type = HMAC-SHA1: loại mã hóa mà Consumer

muốn chia sẻ, ở đây OpenID chỉ hỗ trợ HMAC-SHA1.

openid.session_type = DH-SHA1: loại phiên mà bộ xử lý sẽ

được chia sẻ, ở đây dùng giao thức trao đổi khóa DiffieHellman.

openid.dh_* = *meh*: một vài tham số để hỗ trợ giao thức

trao đổi khóa nếu Diffie-Hellman được sử dụng.



Khi Consumer gửi request này tới OpenID Server (bước 6), OpenID

Server tạo một khóa bằng bộ xử lý khóa assoc_\handle như dumb

mode. Nhưng nó có thể lưu giữ trạng thái (stateful) thay vì phi

trạng thái (stateless) như dumb mode. OpenID Server sau đó trả

lời cho Consumer một số tham số để lưu trữ trạng thái này. Hai

tham số trong đó là *assoc\_handle* và *mac\_key* (hoặc

*enc\_mac\_key* nếu Diffie-Hellman được sử dụng) giúp Consumer



có thể hiểu được và xác minh yêu cầu xác thực của OpenID Server

mà khơng cần phải gửi lại.

Các bước còn lại được trình bày giống như dumb mode, tùy theo

mode checkid_\setup hay checkid_\immediate, nhưng khác ở chỗ

khi Consumer nhận được yêu cầu xác thực từ OpenID Server

thông qua User Agent (bước 12), nó sẽ tự hiểu và xác thực thơng

tin này mà không cần gửi lại cho OpenID Server để xác thực, vì

Consumer đã lưu trữ bộ xử lý mã hóa dùng chung với OpenID

Server. Và cuối cùng, Consumer gửi về thông điệp cho User Agent

thông báo việc xác thực thành công hay thất bại (bước 13).



V.



VẤN ĐỀ BẢO MẬT



1. Lỗi xác thực

Do RP chỉ nhận được yêu cầu xác thực của OP thơng qua

trình duyệt của user, kẻ tấn cơng có thể giả mạo u cầu

OpenID mà khơng u cầu địa chỉ email của người dùng và

sau đó chèn địa chỉ email của hắn vào phản hồi của OP. Nếu

kẻ tấn công gửi phản hồi này đến trang web không để ý

tham số không được OP ký, trang web có thể bị lừa đăng

nhập kẻ tấn cơng vào bất kỳ tài khoản cục bộ nào.



2. Pishing



OpenID có điểm yếu về bảo mật và dễ bị tấn cơng pishing. Ví

dụ: một RP độc hại có thể chuyển tiếp người dùng đến trang

OP của google giả mạo yêu cầu người dùng đó nhập thơng

tin đăng nhập của họ. Sau khi hồn thành việc này, RP độc

hại (trong trường hợp này cũng kiểm sốt trang OP giả mạo)

sau đó có thể có quyền truy cập vào tài khoản google của

người dùng, sau đó sử dụng tài khoản đó của người dùng để

đăng nhập vào các dịch vụ khác.



Xem Thêm
Tải bản đầy đủ (.docx) (13 trang)

×