BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG ĐẠI HỌC KỸ THUẬT CÔNG NGHỆ TP. HCM
BÁO CÁO MÔN HỌC
Đề tài:
OPENID
Môn học: BẢO MẬT THÔNG TIN
Chuyên ngành: MẠNG MÁY TÍNH
Giảng viên hướng dẫn: ThS. Văn Thiên Hoàng
Sinh viên thực hiện:
Trần Hoàng Nhật
Nguyễn Đăng Khoa
Huỳnh Nhật Trường
Nguyễn Hoài Minh Vương
Lớp: 10LDTHM1
TP. Hồ Chí Minh, 5/2012
MỤC LỤC
CHƯƠNG 1: TỔNG QUAN VỀ OPENID
1.1 Tổng quan
OpenID là một dịch vụ định danh (Identify) chia sẻ, là một hệ thống đăng nhập một
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 nhau
chỉ bằng 1 định danh số, tránh việc sử dụng các tài khoản và mật khẩu khác nhau cho mỗi
website. OpenID là định chuẩn mở, miễn phí và phân quyền cho phép người dùng điều
khiển được các thông tin cá nhân của mình công khai trên Internet.
Một OpenID là dạng liên kết URL, URL này có thể là tên miền của website hoặc
URL của 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ệ của tài khoản.
OpenID là một phương thức giúp bạn xác thực tài khoản đăng ký tại một provider duy
nhất mà bạn tin tưởng và cho phép người dùng thực hiện việc đăng nhập vào các lần sau.
1.2 Lịch sử phát triển
Phiên bản đầu tiên của OpenID được phát triển vào tháng 5 năm 2005 bởi Brad
Fitzpatrick, tác giả của trang web cộng đồng LiveJournal, làm việc cho công ty Six Apart,
cục bộ.
– Giúp người dùng dễ dàng sử dụng nhiều ứng dụng khác nhau chỉ với cùng một tài
khoản duy nhất.
– Cho phép hệ thống có thể sử dụng các tài khoản đã có trước từ bên ngoài hoặc
dùng các tài khoản tạo bên trong hệ thống:
• Chứng thực qua email: Đòi hỏi người dùng sau khi đăng kí tài khoản tại site
sẽ phải kích hoạt tài khoản thông qua email
• Chứng thực bằng tay: Tất cả các tài khoản chỉ có thể tạo bởi người quản trị
• Không chứng thực: Người dùng chỉ cần đăng kí tài khoản là 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 và 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 nhau chỉ bằng một định danh số (Digital
Indentity). Giúp thay thế các thủ tục đăng ký, xác thực, đăng nhập truyền thống chỉ bằng
một bước đăng nhập duy nhất.
1.4 Các thành phần của một hệ thống quản lý định danh
Các hệ thống quản lý định danh rất đa dạng và phong phú. Mỗi hệ thống có thể có
danh sách các thành phần, cách hoạt động, cách giao tiếp khác nhau.
Tuy nhiên, trong hệ thống quản lý định danh thông thường có các thành phần:
Hình 1.1. Các thành phần chính của hệ thống định danh
– Relying Party: là dịch vụ sử dụng cơ chế định danh để chứng thực. Ví dụ, một
số trang web sử dụng cơ chế đăng nhập người dùng để định danh như trang
zing, trang eplay Hiện nay đã có rất nhiều thành phần Relying Party trên
mạng. Phần lớn trong số đó đã hỗ trợ định danh bằng hệ thống khác như tài
khoản email của Yahoo hay Gmail.
Hình 1.2. Ví dụ về thành phần Relying Party
– Identity Provider (IdP): là thành phần có nhiệm vụ quản lý các thuộc tính định
danh của người dùng hệ thống. IdP có chức năng truyền những thông tin cần
thiết để thực hiện chứng thực đến Relying Party sau khi xác định đúng là người
dùng đang sử dụng dịch vụ. Hiện nay đã có rất nhiều hệ thống nổi tiếng đã xây
CHƯƠNG 2: PHƯƠNG THỨC HOẠT ĐỘNG CỦA OPENID
2.1 Giao tiếp giữa các thành phần trong hệ thống OpenID
OpenID cung cấp cho người dùng URI duy nhất để đăng nhập vào những Relying
Party khác nhau. URI đóng vai trò là thuộc tính định danh được quản lý tại Identity
Provider. Sự giao tiếp giữa các thành phần trong hệ thống OpenID với URI là địa chỉ của
Identity Provider được thể hiện như hình 2.1.
Hình 2.1. URI là địa chỉ của Identity Provider.
Tuy nhiên, URI không nhất thiết phải là địa chỉ Identity Provider. Ví dụ, URI thật
của Identity Provider có thể lưu ở một máy khác như trong 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 để có thể xác
định được địa chỉ URI thật sự của Identity Provider.
Hình 2.2. URI không phải là địa chỉ của Identity Provider.
2.2 Cơ chế hoạt động của OpenID
OpenID có hai cơ chế giao tiếp là Smart mode và Dumb mode. Hai cơ chế này được
dựa trên khả năng của Relying Party. Trong chế độ Smart mode, Relying Party có khả
năng 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ả năng lưu trữ thông tin nên phải thực hiện thêm một số
bước để hoàn tất quá trình chứng thực.
2.2.1 Cơ chế Smart mode
Quy trình định danh của hệ thống OpenID ở chế độ Smart Mode có thể chia làm 3
quy trình con 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 6 bước như hình 2.3:
– Bước 1.1: Người dùng sẽ nhập địa chỉ URL của Relying Party vào Browser.
– Bước 1.2: Dựa vào URL người dùng nhập vào, Browser sẽ giao tiếp với thành
phần Relying Party.
sau đó.
• Trường hợp 2: Nếu thành phần Relying Party đã có được khóa bí mật
chưa hết thời gian sử dụng ở các lần thực hiện định danh trước đây thì
không cần phải thực hiện bước này. Vì vậy bước 2.1 là bước tùy chọn.
– Bước 2.2: Relying Party gởi danh sách tên các thuộc tính yêu cầu Identity
Provider cung cấp để chứng thực.
– Bước 2.3: Identity Provider sẽ yêu cầu người dùng đăng nhập bằng cách trả về
Browser trang đăng nhập.
– Bước 2.4: Browser sẽ hiển thị trang đăng nhập đến người dùng.
– Bước 2.5: Người dùng sẽ đăng nhập vào Identity Provider (ví dụ, người dùng
sẽ nhập vào username và password để đăng nhập). Sau đó, người dùng sẽ nhấn
nút “đăng nhập”.
– Bước 2.6: Browser sẽ chuyển thông tin đăng nhập người dùng đến Identity
Provider để kiểm tra.
– Bước 2.7: Identity Provider sẽ kiểm tra thông tin đăng nhập. Sau đó, Identity
Provider sẽ dựa tręn danh sách tęn các thuộc tính yęu cầu từ Relying Party;
Identity Provider sẽ tạo một thông điệp có chứa các thuộc tính tương ứng. Cuối
cùng, Identity Provider sẽ ký trên danh sách các thuộc tính định danh và trả về
Browser.
– Bước 2.8: Browser sẽ hiện lên tất cả thuộc tính định danh nhận được từ Identity
Provider cho người dùng.
– Bước 2.9: Người dùng sẽ kiểm tra các thuộc tính định danh có hợp lệ. Sau đó,
người dùng sẽ xác nhận truyền các thuộc tính định danh.
– Bước 2.10: Browser sẽ truyền các thông tin định danh của người dùng đến
Relying Party.
2.2.1.3 Quy trình kiểm tra thuộc tính định danh
Hình 2.6. Quy trình kiểm tra thuộc tính định danh
Quy trình gởi thuộc tính định danh lên Relying Party gồm 3 bước được minh họa
trong hình 2.6:
– Bước 3.1: Dựa trên thuộc tính định danh nhận được từ thành phần Identity
– Bước 3: Sau khi nhận dạng người dùng, các Relying Party thiết lập Endpoint
OpenID Provider URL người dùng để xác thực.
– Bước 4: Relying Party và OpenID Provider sử dụng thuật toán Diffier_Hellman
thiết lập một khóa bí mật.
– Bước 5: Relying Party truyền một yêu cầu xác thực để các OpenID Provider 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. Thông điệp
này được chuyển qua client hơn là trực tiếp giữa các Relying Party và OpenID
Provider.
– Bước 6: Các SASL ở client gửi một phản hồi trống, tiếp tục xác thực thông qua
OpenID
– Bước 7: Các ứng dụng máy client phải xây dựng một URL có chứa nội dung
trong tin nhắn trước đây từ Relying Party. URL này được chuyển đến các
OpenID Provider, hoặc tới SASL client hoặc xử lý thích hợp. Chẳng hạn như
một trình duyệt …
– Bước 8: Client xác nhận cho OpenID Provider và sau đó chấp thuận hoặc
không chấp nhận chứng thực với OpenID Provider. Cuối cùng là chứng thực
cho OpenID Provider trong phạm vi của OpenID
– Bước 9: Các OpenID Provider 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 cho Relying Party. 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, các client truyền qua
HTTP chuyển hướng kết quả OpenID Provider cho Relying Party.
– Bước 10: Các thẻ Relying Party gửi một yêu cầu trực tiếp check_authentication
OpenID cho OpenID Provider.
– Bước 11: Các máy chủ SASL gửi một phản ứng SASL phù hợp với client.
2.4 Ứng dụng thuật toán Diffie-Hellman
2.4.1 Mô hình trao đổi khóa Diffie-Hellman
Năm 1976, Whitfield Diffie và Martin Hellman đã đưa ra một giao thức để trao đổi
các giá trị khóa quy ước giữa các đối tác trên đường truyền có độ bảo mật trung bình. Sự
ra đời của giao thức trao đổi khóa Diffie-Hellman được xem là bước mở đầu cho lĩnh vực
mã hóa khóa công khai.
mod n) và gởi cho B.
Tương tự, user B cũng tạo ra một số riêng X
b <n
tính giá trị Y
b
= (g
xb
mod n) và
gởi lại cho A. X
a
và X
b
tương đương khóa private, Y
a
và Y
b
tương đương khóa
public.
– User B xác định được khóa bí mật dùng cho phiên làm việc bằng cách tính giá
trị (g
xa
mod n)
xb
= (g
xaxb
mod n). Bằng cách tương tự, user A cũng xác định được
cùng khóa bí mật này bằng cách tính giá trị (g
xb
mod n)
xa
. Vì vậy
khóa bí mật này thường được gọi là khóa phiên.
2.5 Sơ đồ quy trình giao tiếp giữa Client – Server
Hình 2.11. Sơ đồ giao tiếp giữa Client - Server
2.6 Quy trình xử lý các bước giao tiếp
Các thông số mật mã của trạng thái session được tạo ra bởi giao thức bắt tay TLS,
hoạt động trên đầu trang của TLS Layer. Khi một khách hàng TLS và máy chủ đầu tiên
bắt đầu giao tiếp, họ đồng ý trên một phiên bản giao thức, chọn thuật toán mã hóa, tùy
chọn xác thực lẫn nhau, và sử dụng kỹ thuật mã hóa khóa công khai để tạo ra bí mật được
chia sẻ. Các giao thức bắt tay TLS bao gồm các bước sau đây:
– Trao đổi thông điệp bắt tay thỏa thuận đồng ý giữa các bên về các thuật toán,
trao đổi ngẫu nhiên giá trị, và kiểm tra phiên giao dịch.
– Trao đổi các thông số mật mã cần thiết để cho phép người dùng cuối và máy
chủ đồng ý trên một khóa bí mật premaster.
– Giấy chứng nhận exchange và thông tin mật mã để cho phép máy khách và máy
chủ xác thực bản thân.
– Tạo ra một bí mật tổng thể từ bí mật premaster và trao đổi ngẫu nhiên giá trị.
– Cung cấp các thông số an ninh lớp ghi.
– Cho phép các máy người dùng cuối và máy chủ xác minh, tính toán các thông
số an ninh và những cái bắt tay xảy ra mà không làm bị can thiệp từ bên thứ ba
tấn công.
Hình 2.12. Cấu trúc giao thức bắt tay
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 trên website NukeViet
NukeViet OpenID hỗ trợ OpenID 2.0 Directed Identity Protocol, cho phép những tên
miền được lưu trữ rên máy chủ có thể yêu cầu xác thực. Khi có yêu cầu từ một trang web
thứ ba, NukeViet OpenID sẽ thực hiện việc kiểm tra xác thực tên miền hợp lệ. Tên miền
được mã hóa như một ID và lưu trữ trên máy chủ của NukeViet, nếu ID này là phù hợp
thì một yêu cầu xác thực sẽ được trả về cho người dùng yêu cầu họ cho phép gửi thông tin
Hình 3.3. File cấu hình php.ini
• Bỏ dấu “;” ở phía trước dòng “extension=php_curl.dll”.
Hình 3.4. Sửa file cấu hình php.ini cho phép thực thi tính năng cURL
• Lưu lại
• Bật tính năng Put Online cho phép puplic website ra bên ngoài
Hình 3.5. Bật tính năng Put Online
– Tạo CSDL
• Mở trình duyệt web, gõ http://localhost/phpmyadmin
• Tại ô Create new database, nhập tên CSDL “hutech” Create
Hình 3.6. Tạo Database hutech
Copyright: Tài liệu đại học ©