ĐỒ ÁN MÔN HỌC
BẢO MẬT THÔNG TIN
ĐỀ TÀI
NGHIÊN CỨU HOẠT ĐỘNG OPENID
Mục Lục
Chương I: GIỚI THIỆU OPEN ID
1. Giới Thiệu:
1.1. VÀấn đề mật khẩu của web application (WebApp) hiện nay.
Rất nhiều ứng dụng web hiện nay bắt buộc phải tạo tài khoản để thực hiện những
chức năng mà nó cung cấp vàà đây là một vàiệc làm bắt buộc để xác thực người
dùng. VÀiệc tạo tài khoảnàyêu cầu khách vàiếng thăm mất khá nhiều thời gian vàà
có cảm giác phiền toái. Tránh né những website yêu cầu có tài khoản, đây là yếu
tố mất điểm không thể tránh khỏi đối vàới các WebApp. Lượng đăng ký tỷ lệ
nghịch vàới số lượng thông tin bắt buộc, số lần nhấp chuột vào các ô nhập liệu
trên forMụcủa ứng dụng.
VÀề phía người dùng, khi tham gia vào mỗi ứng dụng web có xác thực bằng tên
đăng nhập vàà mật khẩu, họ đều phải ghi nhớ tên đăng nhập vàà mật khẩu, lượng
tài khoản gia tăng làMụcho vàiệc ghi nhớ mật khẩu ở mỗi ứng dụng webấtrở thành
vàấn đề lớn. Chắcáchắn mỗi trong chúng ta đã từng click vào link “Click đây nếu
quên mật khẩu” để tìm lại mật khẩu cho những ứng dụng ít sử dụng. Số ít lại dán
đầy những mảnh giấy ghi thông tin tài khoản.
Một số website có các tiện ích được phát triển trên những nền tảng khác nhau, yêu
cầu đặt ra là người dùng chỉ cần đăng ký một lần ở duy nhất một tiện ích nhưng có
thể sử dụng được tài khoản đó cho tất cả các tiện ích trên website.
Những vàấn đề đó trở thành vàật cản cho sự phát triển của các ứng dụng website,
khiến cho các ứng dụng khác nhau khó có thể liên kết được vàới nhau. Do đó cần
có giải pháp thỏa đáng để có thể triệt để giải quyết các vàấn đề. Thúc đẩy các nhà
phát triển tạo ra OpenID.
1.2. Giải Pháp Openid
OpenID giúp người dùng vàà website xác thực quyền truy cập, cho phép người
ra vàài ngày.
Tháng 12, các nhà phát triển SXIP (Simple Extensible Identity Protocol) vàà XRI
(Một chuẩn nhận dạng mới trên Internet) vàà bắt đầu tích hợp vào OpenID, thay
vàì nhận dạng bằng URL ban đầu, OpenID đã phát triển thành một chuận nhận
dạng đầy đủ cho danh tính người sử dụng. Phiên bản OpenID 2.0 xuất hiện.
31/1/2007, Symantecácông bố hổ trợ OpenID trong trang dịch vàụ vàà sản phẩm.
Một tuần sau, ngày 6/2/2007, Microsoft kết hợp vàới JanRain, Sxip, vàà
VÀeriSign (Những tổ chức tham gia phát triển OpenID) tuyên bố hổ trợ OpenID
vàà xem xét khả năng tương tác giữa OpenID vàà MS CardSpace (Một phương
thức nhận dạng của Microsoft), cùng vàới đó là vàiệc xem xét các vàấn đề bảo mật
cho sự phát triển của OpenID. Giữa tháng 2, AOL hổ trợ thử nghiệm OpenID.
OpenID sau đó đượcácc đại gia như Yahoo, Google quan tâm, kéo theo đó là các
mạng xã hội vàà các website có lượng người sử dụng lớn cũng bắt đầu hổ trợ
OpenID (Trở thành Provaider hoặc WebApp hổ trợ OpenID).
CHƯƠNG II: MÔ HÌNH HOẠT ĐỘNG CỦA OPEN ID
1. 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.
1.1 Chế độ Dumb: Trong chế độ Dumb, những RP không duy trì trạng
thái của
kết nối, vàì vàậy bất kỳ thông tin đã được sử dụng trong một đăng nhập trước đó,
không thể được sử dụng một lần nữa .
Các bướcáchứng thực vàà đăng nhập ở nơi giao tiếp giữa Consumer, trình duyệt
vàà OP. Các bước này được ánh xạ đồ họa như hình sau:
VÀí dụ: Identity Provaider là : pip.vàerisignlabs.com
The Consumer là kmasecurity.net
1. Đăng nhập vào Consumer website
2. Trang web đó sẽ gửi cho bạn 1 url ( vàí dụ rpip.pip. vàerisignlabs.com
)để bạn xác thực acc
3. Cácconsumer 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.
browser). Đ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.
8. Nếu không có gì bất hợp, người dùng cuối sẽ đăng nhập vào
trang web. Nếu không đăng nhập sẽ thất bại.
1.2 Chế độ thông minh
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.
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 Provaider (OpenID Servàer). Sau khi phân tích cú phá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. Tùy chọn, 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.
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, các
Identity Provaider có thể yêu cầu người dùng cuối để đăng nhập.
Bước 6: Identity Provaider 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. 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.
Bước 7: Sau một sự khẳng định thành công, người tiêu dùng xác minh sự
khẳng định sử dụng
vàiệcáchia sẻ lưu trữ chính. Nếu có một trận đấu ở bước trước, cuối cùng
Người dùng sẽ đăng nhập vào các trang web. Nếu không đăng nhập sẽ thất
Diffie-Hellman Key Exchange. OP Provaider sẽ sử dụng sự thiết lập
trên để đồng ý những yêu cầu tiếp theo. VÀà sau đó website sử dụng
OpenID sẽ chứng thực những thông điệp. Đ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.
4. 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. VÀà
chia sẻ các thuộc tính của OP cho RP,
6. 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. 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, xác nhận phát hiện thông tin, 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. VÀà RP vàà user phải thay
đổi mã hóa để thi hành SASL.
*, Khi xem xét lưu lượng này trong bối cảnh SASL, khi RP vàà khách hàng cả hai đều
phải thay đổi mã của họ để thi hành cơ chế SASL, các OP phải vàẫn bị ảnh hưởng. Do
đó, một dòng tương tự mà giao diện ba bên cần phải được tạo ra. Trong tương tự,
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. 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. Điều này sẽ
được thảo luận dưới đây. Bằng cách đó, chúng tôi biểu lộ nhiều authentiction từ SASL
Các bước được tiến hành như sau:
1. RP hoặc SASL servàer sẽ tiến hành quảng bá cơ chế SASL của
OpenID cho khách hang
2. 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. Sau khi bình thường hóa vàiệc nhận người dung , 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.
gián tiếp đáp ứng thông qua trình duyệt của client hoặc xử lý.
Cácclient truyền qua HTTP chuyển hướng kết quả OP cho RP. Bước
này sẽ xảy ra trong SASL.
10.Các THỂ RP gửi một yêu cầu trực tiếp check_authentication
OpenID cho OP, nếu không có hiệp hội đã được thành lập, vàà các
OP được dự kiến sẽ trả lời. Một lần nữa bước này xảy ra trong
SASL.
11.Các máy chủ SASL gửi một phản ứng SASL phù hợp vàới client,
vàới các tùy chọn thuộc Registry đơn giản Open (SREG).
3 Tóm lượcácơ chế:
1. Quảng cáo: Để quảng cáo rằng một máy chủ hỗ trợ OpenID, trong quá
trình ứng dụng phiên họp bắt đầu, nó sẽ hiển thị tên "OpenID" trong danh sách
cơ chế hỗ trợ SASL.
2. Bắt đầu: Một client bắt đầu một chứng thực OpenID vàới SASL của XRI
hay URI, theo quy định tại các đặc điểm kỹ thuật OpenID. Ngoài ra, hỗ trợ
phiên bản của OpenID đượcáchỉ định.
“initial-response = Identifier UTF8NUL openid-vàersion
Identifier = URI | XRI ; Identifer is specified in
Sec. 7.2 of the OpenID 2.0 spec.
; XRI as specified by OASIS 2.0 Syntax
URI is specified in RFC 3986.
openid-vàersion = 1*DIGIT [ "." 1*DIGIT ]
Cú pháp XRI được định nghĩa trong [XRI2.0].
3. Yêu cầu chứng thực: Các Servàer SASL gửi một thông báo OpenID có
chứa một openid.mode của một trong hai "checkid_immediate"
"checkid_setup". Cácclient hàng bây giờ gửi có yêu cầu thông qua một HTTP
GET để các OP, như chuyển hướng để làm điều đó từ một máy chủ HTTP.
Cácclient 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. Cácclient 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.
URL
6. Chuyển hướng
người dùng đến rp
7. Phản Hồi Nhà Xác
Thực
Ope
nID
URL
2. Discovery
(Yadis/HTML)
3. Giao Thiệp
Giữa 2 lớp
(optional)
4. Chuyển Hướng
N/Dùng Tới Nhà Xác
Thực
5. Y/cầu Xác Thực
+
Người Dừng Cuối
8. Xác Minh
(optional)
Đồng thời cũng dựa vào đó để xác định Provaider trong quá trình giao tiếp. Người
sử dụng sau khi nhập OpenID URL của mình vào trường đăng nhập, sẽ có 2
trường hợp xãy ra.
1: WebApp xác nhận được Provaider vàà ngay lập tứcáchuyển người dùng tới
một cửa sổ mới của Provaider để Provaider xác nhận lại người dùng.
2: WebApp hỏi người dùng có muốn tiến hành xác nhận bằng Provaider hay
không.
Sau khi đăng nhập bằng tài khoản của mình tại Provaider, người dùng được
Provaider hỏi có đồng ý đăng nhập vào WebApp hiện tại hay không. Người dùng
Cơ sở dữ liệu rỗng thựcáchất là một DB name mới. Để tạo một CSDL rỗng,
bạn thực hiện theo trình tự sau:
Mở trình duyệt web, gõ http://localhost/phpmyadmin/
Tại ô Create new database, nhập tên cơ sở dữ liệu mà bạn muốn tạo
mới. VÀí dụ: “mangxd”. Nhấp Create
Hình 3.4: Tạo CSDL rỗng
Hình 3.5: CSDL rỗng đã được tạo
Bước 1: Lựa chọn ngôn ngữ
Hình 3.6: Lựa chọn ngôn ngữ cài đặt
Hình 3.7: Giao diện cài đặt tiếng VÀiệt sau khi lựa chọn ngôn ngữ cài đặt.
Ngôn ngữ mặc định khi cài đặt là tiếng Anh, để thay đổi ngôn ngữ hiển thị
bạn có thể lựa chọn ở menu “Please select the language to use on this site” (1).
Lựa chọn xong ngôn ngữ bạn có thể nhấn vào nút “Bước kế tiếp” (2) đối vàới
tiếng VÀiệt hoặc nút “Next step” đối vàới ngôn ngữ là tiếng Anh.
Bước 2: Bản quyền
Hình 3.8: Bản quyền NukeVÀiet
Mã nguồn nukevàiet 3.0 được phát hành dưới dạng mã nguồn mở sử dụng giấy
phép: GNU GENERAL PUBLIC LICENSE, khi bạn sử dụng mã nguồn
NukeVÀiet bạn hoàn toàn phải tuân thủ theo giấy phép trên. Bắt đầu từ bước 2
bạn có thêm lựa chọn: Quay lại bước trước (1) hoặc Bước kế tiếp (2).
Bước 3: Kiểm tra máy chủ
Hình 3.9: Kiểm tra tương thích vàới máy chủ
Để hệ thống nukevàiet 3.0 có thể hoạt động trơn tru - ở bước này hệ thống
sẽ liệt kê ra các tính năng – yêu cầu máy chủ bắt buộc phải hỗ trợ. Nếu 2 yêu cầu:
“Phiên bản PHP >= 5.0.0” vàà “Hỗ trợ MySQL” không thỏa mãn thì quá trình cài
đặt không thể tiếp tục.
Ngoài ra hệ thống còn đưa ra những khuyến cáo vàề những tính năng
khácácủa máy chủ. Nếu có thắc mắc trong vàiệc các bạn có thể thông qua diễn
đàn http://nukevàiet.vàn để được giúp đỡ thêm. Khi các yêu cầu thỏa đáng các bạn
có thể nhấn vào nút “Bước kế tiếp” để chuyển qua bước 4: Kiểm tra
Hình 3.14: Kết thúc quá trinh cài đặt thành công.
Khi hoàn thành 6 bước trên vàà chuyển qua bước 7: Kết thúc – hệ thống sẽ
hiện ra thông báo chúc mừng bạn đã cài đặt thành công. Ngoài ra, hệ thống cũng
yêu cầu hãy CHMODụngay thư mục uploads trên webroot vàà các thư mụcácon
nằm trong nó ở chế độ 777. Sau khi xong các bước hệ thống yêu cầu bạn có 2 lựa
chọn: Xem trang chủ hoặc Đăng nhập trang quản trị.
Hình 3.15: Đăng nhập khu vàực quản trị
Copyright: Tài liệu đại học ©