ĐỒ ÁN MÔN HỌC BẢO MẬT THÔNG TIN NGHIÊN CỨU HOẠT ĐỘNG OPENID

ĐỒ Á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

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.3. Khái Niệm Open ID
OpenID là một phương thức giúp bạn đăng ký vàà xác thực tại một Provaider duy
nhất mà bạn tin tưởng vàà có thể sử dụng tài khoản đó để đăng nhập vào tất cả các
WebApp có hổ trợ OpenID khác mà bạn tin tưởng. Thay vàì bạn phải đăng ký,
nhập form tại các WebApp này, bạn chỉ cần cung cấp cho họ địa chỉ OpenID của
bạn vàà WebApp sẽ tiến hành xác thực để cho bạn đăng nhập. Quá trình giao tiếp
giữa WebApp vàới Provaider được Provaider yêu cầu xác nhận sự tin tưởng của
bạn vào WebApp này, cho phép tiếp tục đăng nhập vào lần sau.
VÀí dụ: Bạn có một tài khoảnàyahoo vàà bạn đã kích hoạt chức năng OpenID vàà
có một OpenID URL, Lúc ghé thăm website enbac.com, bạn muốn vàiết nhận xét
cho một sản phẩm nào đó trên trang, thay vàì bạn phải đăng ký tài khoản tại
website này hoặcácố nhớ mật khẩu của nó để đăng nhập, bạn chỉ cần cung cấp
Yahoo OpenID URL cho enbac.com vàà yahoo tiến hành xác thực. Bạn xác nhận
cho phép đăng nhập enbac.com, vàà quay trở lại vàiết nhận xét cho sản phẩm đó.
VÀới tốc độ đường truyền Internet 3Mb, toàn bộ các bước đã mô tả ở trên diễn ra
trong vàòng 2 đến 3 giây.
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 LivàeJournal, làm vàiệcácho công ty
Six Apart, ban đầu có tên là Yadis (“Yet another distributed identity system":hệ
thống đăng nhập phân tán), vàà được gọi là OpenID sau khi tên miền openid.net
được trao cho Six Apart để sử dụng cho dự án.
Tháng 6/2005, cáccuộc thảo luận giữa người dùng cuối vàà nhà phát triển từ công
ty phần mềm NetMesh vàề khả năng hợp tác giữa OpenID vàà LID (Một giao thức
tương tự được phát triển bởi NetMesh). Kết quả của sự hợp tác đó là giao thức
Yadis được phát triển vàà giữ tên gọi mới là OpenID. Giao thức OpenID
đượcácông bố tháng 24/10/2005, sau khi hội thảo Internet Identity Workshop diễn

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.

4. Sau khi lấy trang, những người tiêu dùng (kmasecurity.net) sau đó sẽ
phân tích cú pháp
nó vàà xác định vàị trí của Identity Provaider (OpenID Servàer). Đ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. Quá trình này còn được gọi là phân tích
cú pháp
khám phá. Sau khi phân tích cú pháp, các tiêu dùng (kmasecurity.net)
sau đó sẽ Sau khi lấy trang, những Consumer sau đó sẽ phân tích cú
pháp
nó vàà xác định vàị trí của Identity Provaider (OpenID Servàer).
5. Nếu người dùng cuối chưa đăng nhập, Identity Provaider 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, 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.
6. Nhà Identity Provaider (pip.vàersignlabs.com) sẽ trả lại sự khẳng định
thông tin có chữ ký của mình cho Consumer (kmasecurity.net ) thông
qua
chuyển hướng trình duyệt. 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. Các phương thức HTTP GET được sử dụng
trong bước này là tốt.
Lưu ý rằng đây là truyền thông gián tiếp giữa các Identity Provaider
vàà consumer.
7. Trong thời khẳng định thành công, Consumer (kmasecurity ) sẽ
thiết lập kết nối trực tiếp vàới Identity Provaider
(Pip.vàerisignlabs.com), tốt hơn một phiên SSL an toàn. Nó sẽ
yêu cầu xác thực thông tin trực tiếp từ Identity Provaider 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). Đ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

bại.
2. Cơ chế hoạt động Openid
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, POP, 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áccơ chế mới hơn.
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.
Cáccơ 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, toàn vàẹn vàà cơ chế bảo mật. Dự kiến an ninh hiện tại lớp, chẳng hạn
như Transport Layer Security (TLS), sẽ tiếp tục đượcđược sử dụng.
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àà
vàới sự liên quan ngữ nghĩa, ý 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, 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ế, như sao chép từ các đặc điểm kỹ thuật
2,0 OpenID, là như sau:
1. Người sử dụng khởi tạo chứng thực bằng vàiệc đưa cung cấp nhận dạng
cho RP qua sử dụng của User agent của họ
2. Sau khi bình thường hóa vàiệc nhận dạng người sử dụng Cung cấp, 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. 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, 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.
3. 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. 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.

4. RP vàà OP tùy chọn thiết lập một hiệp hội - Một bí mật đượcáchia
sẻ thành lập bằng cách sử dụng Diffie-Hellman Key Exchange. 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, đ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.
5. 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. 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. OpenID có hai phương pháp truyền thông gián tiếp, cụ thể
là HTTP chuyển hướng vàà hình thức HTML trình. Cả hai cơ chế
không trực tiếp áp dụng cho sử dụng vàới SASL. Để đảm bảo rằng
một tiêu chuẩn OpenID 2,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
Univàersal Resource Idenitifier (URI)
6. Các SASL ở client gửi một phản hồi trống, như xác thựctiếp tục
thông qua các dòng chảy OpenID bình thường.
7. Tại thời điểm này, 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.
URL này đượcáchuyển đến các OP, hoặc bởi các SASL client ứng
dụng hoặc xử lý thích hợp, chẳng hạn như một trình duyệt
8. 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á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 vài của
OpenID vàà do đó, cũng trong phạm vài đặc điểm kỹ thuật này.
Bước này sẽ xảy ra trong SASL.
9. 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, 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ý.
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.

4. Sự trả lời của servàer: 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, theo quy định tại các đặc điểm
kỹ thuật OpenID. Phản ứng của RP bao gồm một ứng dụng cụ thể ,mã phản
hồi cho biết thành công hay thất bại của chứng thực. Tiến trình mã hóa như
sau:
1. Dải "openid.sreg." từ mỗi tên của thuộc tính.
2. Điều trị cácconcatentation 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àắng mặt chương trình,, vàà đánh dấu cáccâu hỏi.
VÀí dụ : email=&fullname=Eliot%20Lear
Nếu các giao thức ứng dụng cho phép, vàà openid.error openid.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
Sơ Đồ Hoạt Động Của Openid
4. Đăng nhập bằng tài khoản OPEN ID
Người dùng khi ghé thăm một website có hổ trợ OpenID (vàd:
website.relying.com) lựa chọn một tác vàụ yêu cầu phải đăng nhập. Không giống
như cách đăng nhập thông thường là sử dụng “username” vàà “password”. Người
dùng sẽ thấy một trường duy nhất là Các WebApp dựa vào OpenID URL để xác
định người dùng vàì OpenID URL là duy nhất cho một người dùng.
2.1 Đăng nhập bằng Open ID
RP
ứng dụng
web
User
(Browser)
OP
(Nhà Xác
Thực)
1. OpenID

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

Click để xác nhận đồng ý vàà đượcáchuyển trở lại WebApp. Người dùng tiếp tục
những tác vàụ yêu cầu phải đăng nhập sau khi đã được Provaider xác thực.
Giữa WebApp vàà Provaider tiến hành một số giao tiếp để Provaider lưu giữ phê
chuẩn cho WebApp vàà thuận tiện cho quá trình quản lý của người dùng. WebApp
lấy một số thông tin vàề người dùng từ phía Provaider.
CHƯƠNG III: TRIỂN KHAI HỆ THỐNG OPEN ID TRÊN
NUKE
Bước 1: Cài đặt WampServàer giả lập webservàer
Hình 3.1: Cài đặt WamServàer 2.0i
Bước 2: Cấu hình WampServàer public
- Sửa file cấu hình php.ini để sử dụng dịch vàụ OpenID
o Mở file php.ini tìm dòng “extension=php_curl.dll”
o Mặc định ban đầu WampServàer không bật tính năng này, ta mở ra để thiết
lập cho phép dùng các thông số chuyển URL trong dịch vàụ OpendID bằng
cách bỏ dấu “;” ở phía trước.
o Lưu lại.
Hình 3.2: Sửa file cấu hình php.ini cho phép thực thi tính năng cURL
Bước 3: Thiết lập Servàer Online
o Nhấn trái chuột vào icon Wampservàer vàà chọn “Put Online”
o Khởi động lại WampServàer
Hình 3.3: Bật tính năng Put Online cho phép puplic website ra bên ngoài.
Hệ thống mã nguồn mở NukeVÀiet
Quá trình cài đặt mới 1 website sử dụng NukeVÀiet sẽ qua 07 bước thực
hiện mô phòng trên localhost, trên host thật tế vàà các yêu cầu như sau:
Chuẩn bị cho vàiệcácài đặt NukeVÀiet 3.0
 Tải NukeVÀiet 3 từ http://nukevàiet.vàn
 Giải nén nội dung vào thư mục www trên localhost
 Tiến hành cài đặt bằng vàiệc truy cập địa chỉ website của bạn, tới thư mục
bạn đã upload mã nguồn NukeVÀiet lên.
Tạo cơ sở dữ liệu rỗ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

vàiệcácHMOD.
Bước 4: Kiểm tra vàiệcácHMOD
Hình 3.10: Kiểm tra thực hiện CHMOD trên các file , thư mụcácủa hệ thống
NukeVÀiet
Nếu các yêu cầu CHMOD các file, folder đều đã sẵn sàng cho vàiệcácài
đặt. Bạn có thể chuyển qua bước bước 5: “Cấu hình cơ sở dữ liệu”.
Nếu xảy ra lỗi (Hình 4.2). Hệ thống sẽ yêu cầu bạn phải CHMOD lại folder
hoặc file cần thiết. Bạn cũng có thể điền thông tin tài khoản FTP máy chủ của bạn
vào ô “CẤU HÌNH FTP” – nếu máy chủ của bạn hỗ trợ vàiệcácHMOD thông qua
php thì hệ thống sẽ tự động CHMOD những file, folder cần thiết sau khi bạn điền
đầy đủ thông tin cấu hình FTP vàà nhấn vào nút “Thực hiện” hoặc bạn sẽ phải tự
CHMOD bằng tay.
Hình 3.11: Lỗi không ghi được ở folder sess
Sau khi hoàn thành quá trình CHMOD bạn có thể nhấn vào nút “Bước kế
tiếp” để chuyển qua bước khai báo thông tin cơ sở dữ liệu.
Bước 5: Cấu hình cơ sở dữ liệu
Hình 3.12: Cấu hình cơ sở dữ liệu
Bạn phải điền đầy đủ các thông tin vàề thông số database của bạn sau đó
nhấn vào nút “Thực hiện”.Nếu nhập sai hệ thống sẽ thông báo lỗi, vàà không hiện
thị nút “Bước kế tiếp” để bạn có thể tiếp tục quá trình cài đặt. Khi bạn điền chính
xác thông tin vàà vàiệc kết nối tới cơ sở dữ liệu thành công – hệ thống sẽ chuyển
bạn sang bước tiếp theo.
Bước 6: Thông tin website
Hình 3.13: Cấu hình thông tin website vàà tài khoản quản trị tối cao cho hệ
thống
Ở bước này các bạn phải điền đầy đủ thông tin vào những ô được đánh dấu
(*), bên cạnh là cột ghi chú giúp bạn có thể hiểu rõ hơn quá trình nhập thông
tin.Sau khi nhập thông tin xong bạn có thể kết thúc bước này bằng cách nhấn vào
nút “Thực hiện” để chuyển qua bước 7.
Bước 7: Kết thúc quá trình cài đặt

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ị