1. 28
C ương 3
Tổng quan về ệ t ống OpenID
 Nội dung của Chương 3 trình bày tổng quan về hệ thống OpenID. Hệ thống này
s được chúng tôi sử dụng làm nền tảng để cải tiến trong luận văn.
3.1 Giới hi
Th ng 5/2005, rad Fitzpatrick, người sáng lập trang web nổi tiếng LiveJournal,
đã ph t triển giao thức xác thực OpenID đầu tiên trong khi đang l m việc tại Six
Apart[7].
Đến cuối năm 2009 đã có trên 1 tỉ tài khoản OpenID, và x p xỉ 9 triệu websites có
hỗ trợ thành phần Relying Party[26]. Ngoài ra, có nhiều websites nổi tiếng đã xây
dựng thành phần Identity Provider như Google, Yahoo, Microsoft, Facebook… Danh
sách các tổ chức lớn có hỗ trợ hệ thống OpenID sẽ được trình bày trong phần Ph l c
B. Điều này cho th y, hệ thống OpenID đã sử d ng r t phổ biến hiện nay.
Một hệ thống OpenID gồm ba thành phần là Identity Provider, Relying Party, và
Identity Selector. Thành phần Identity Selector ở đây chính l Browser. Vai trò của ba
thành phần n y đã được trình bày chi tiết trong phần 2.2.2 C c th nh phần chính của
hệ thống định danh.
OpenID cung c p cho người dùng URI[6] duy nh t để đăng nhập vào những
Relying Party khác nhau. URI đóng vai trò l Managed Card (đã trình b y ở phần
2.2.2) ngh a l thuộc tính định danh được quản lý tại Identity Provider. Hình 3.1 thể
hiện 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.
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 3.2. Trong trường
hợp này, hệ thống phải sử d ng hệ thống Web Server ocation of Identifier URI để có
thể x c định được địa chỉ URI thật sự của Identity Provider.

2. 29
Relying Party Identity Provider
Browser
Hình 3.1 S giao ti p giữa các thành phần trong h th ng OpenID với URI đa
chỉ của Identity Provider[38]
Relying Party Identity Provider
Trình duyệt
Web server location of
Identifier URI
Hình 3.2 S giao ti p giữa các thành phần chính trong h th ng OpenID với URI
không phải đ a chỉ của Identity Provider[38]
3.2 Quy trình giao ti p giữa các thành phần
OpenID có hai cơ chế giao tiếp l Smart mode và Dumb mode[38]. 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.
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:

3. 30
 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
Phần tiếp theo chúng tôi sẽ trình bày chi tiết của ba quy trình này:
3.2.1 Quy trình c đ nh thành phần Identity Provider
1.2 1.1
1.3 1.4
1.6 Browser 1.5 Người dùng
Relying Party
Hình 3.3 Quy trình c đ nh thành phần Identity Provider
Quy trình x c định thành phần Identity Provider gồm 3 bước được minh họa trong
Hình 3.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 UR người dùng nhập vào, Browser sẽ giao tiếp với
thành phần Relying Party.
 Bước 1.3: Relying Party sẽ trả về Browser trang đăng nhập có hỗ trợ
OpenID trong đó có textbox yêu cầu người dùng nhập vào URI của Identity
Provider.
 Bước 1.4: Browser hiển thị trang đăng nhập cho người dùng.
 Bước 1.4: Người dùng sẽ điền URI của Identity Provider vào Browser. Sau
khi điền vào URI, người dùng nh n nút “Đăng nhập”.
 Bước 1.5: Browser sẽ chuyển thông tin về URI người dùng nhập v o đến
Relying Party. Relying Party sẽ l y thông tin về URI người dùng nhập vào
để x c định được thành phần Identity Provider tương ứng. URI người dùng
nhập vào sẽ có hai loại:
- Loại 1: URI đó chính l địa chỉ của Identity Provider. Trong trường
hợp n y, Relying Party đã có được địa chỉ của Identity Provider
chính l URI người dùng nhập cung c p.

4. 31
- Loại 2: URI này không phải l địa chỉ của Identity Provider. Trong
trường hợp này, thành phần Relying Party phải dùng Yadis[21] để
l y địa chỉ của Identity Provider. Dịch v Yadis có vai trò nhận vào
một URI và sẽ trả về địa chỉ và thông tin về Identity Provider tương
ứng. Qu trình x c định địa chỉ Identity Proivder dựa trên Yadis
được minh họa trong Hình 3.4.
OpenID URI Yadis Service box XML Document
Hình 3.4 Sử dụng Y is đ c đ nh đ a chỉ của Identity Provider[38]
3.2.2 Quy trình gởi thuộc tính đ nh danh
2.1
2.2
Relying Party
Identity Provider
2.10
ước bắt buộc
ước tùy chọn 2.3 2.6 2.7
2.4
2.5
2.8
2.9 Trình duyệt
Người dùng
Hình 3.5 Quy trình gởi thuộc tính đ nh danh
Quy trình gởi thuộc tính định danh lên Relying Party gồm 10 bước trong Hình 3.5:
 Bước 2.1: Relying Party sau khi x c định được thành phần Identity Provider
ở quy trình x c định thành phần Identity Provider (xem phần 3.2.1). ước
2.1 l bước tùy chọn bao gồm hai trường hợp xảy ra như sau:

5. 32
- Trường hợp 1: Relying Party v Identity Provider chưa có khóa chia sẻ bí mật ở
những lần định danh trước đây, hoặc khóa chia sẻ bí mật đã hết thời gian sử d ng.
Trong trường hợp này, Relying Party sẽ kết nối bằng một kênh truyền an toàn với
Identity Provider để chia sẻ khóa bí mật. Khóa bí mật sẽ được sử d ng để kiểm tra
các thuộc tính định danh ở quy trình kiểm tra thuộc tính định danh sau này ở bước
3.1 hay những lần định danh 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.

6. 33
3.2.3 Quy trình ki m tra thuộc tính đ nh danh
3.1
3.2 3.3
Relying Party Trình duyệt Người dùng
Hình 3.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 3.6.
 Bước 3.1: Dựa trên thuộc tính định danh nhận được từ thành phần Identity
Provider ở quy trình gởi thuộc tính định danh (xem phần 3.2.2) cùng với
khóa chia sẻ bí mật được tạo ra ở bước 2.1. Relying Party sẽ kiểm tra xem
thuộc tính định danh có hợp lệ hay không.
 Bước 3.2: Relying Party trả về kết quả định danh về Browser.
 Bước 3.3: Browser sẽ hiển thị kết quả định danh đến người dùng.
Chế độ Dumb mode cũng tương tự nhưng chế độ Smart mode. Nhưng ở chế độ
Dumb mode, Relying Party không có khả năng lưu trữ các thông tin trước đó. Do đó
thành phần Identity Provider và Relying Party sẽ chưa có khóa chia sẻ để kiểm tra
thuộc tính định danh. Vì vậy, ở bước 3.1 trong quy trình kiểm tra thuộc tính định danh
(xem phần 3.2.3) trong chế độ Dumb mode, Relying Party cần phải tạo kết nối an toàn
với Identity Provider để kiểm tra thuộc tính định danh. C c bước khác ở chế độ Dumb
mode hoàn toàn giống với chế độ Smart mode. Hình 3.7 minh họa quá trình kiểm tra
thuộc tính định danh ở chế độ Dumb mode khác so với chế độ Smart mode ở bước
3.1.
3.1 3.2 3.3
Identity Provider Relying Party Trình duyệt Người dùng
Hình 3.7 Quy trình ki m tra thuộc tính đ nh danh ở ch độ Dumb mode

7. 34
3.3 Những v n đ h sinh đ i với OpenID
Hiện nay, hệ thống OpenID đang được sử d ng r t rộng rãi. Tuy nhiên, dựa trên
những tiêu chí đ nh gi một hệ thống quản lý định danh đã được trình bày trong phần
2.3, hệ thống OpenID còn một số tồn tại. Nhóm chúng tôi sẽ phân tích những v n đề
này từ đó để cải tiến hệ thống OpenID phù hợp với những nhu cầu định danh hiện tại.
3.3.1 V n đ v nh i ng ư
 Tính nặc danh
Nếu sử d ng Identity Provider l tổ chức không đ ng tin cậy, Identity Provider có
thể có được r t nhiều thông tin người dùng về c c website đã truy cập. Ví d , Identity
Provider có thể lưu vết những hoạt động của người dùng bằng c ch lưu những website
người dùng sử d ng, thời gian sử d ng... Đây l những thông tin nhạy cảm có thể ảnh
hưởng đến người dùng nếu thuộc tính này bị lộ ra bên ngoài. Hansen[17] đã đề xu t ra
các giải ph p đề khắc ph c được v n đề này là:
 Người dùng phải chọn thành phần Identity Provider đ ng tin cậy.
 Người dùng phải đọc kỹ các chính sách của Identity Provider để cung c p
hợp lý các thuộc tính định danh của mình.
 Nên xem xét tự xây dựng Identity Provider riêng cho các công ty lớn.
Nhận xét: Để giải quyết v n đề n y, chúng tôi đã đề xu t giải pháp xây dựng thành
phần Identity Provider trên thiết bị di động là một thiết bị tin cậy của người dùng.
 Độ an toàn thông tin
Độ an toàn thông tin thể hiện thông qua khả năng của hệ thống có thể chống lại các
phương ph p t n công để l y thuộc tính định danh của người dùng. Dưới đây l một
số phương ph p t n công ảnh hưởng đến hệ thống OpenID:
 Tấn công replay: Trong một số trường hợp, OpenID dễ d ng bị t n công
replay[8]. Xác su t bị t n công được hạn chế bởi sự có mặt của gi trị ngẫu
nhiên ph t sinh (nonce) kèm một nhãn thời gian (timestamp) trong c c
thông điệp của OpenID. Tuy nhiên, nếu Relying Party không lưu trữ nonce
hoặc nonce chứa một nhãn thời gian qu d i thì x c su t bị t n công replay
r t cao. Để tránh bị t n công replay, các giải ph p để khắc ph c là:

8. 35
- Relying Party và Identity Provider nên dùng NTP (Network Time
Protocol) để giữ cho đồng hồ luôn được đồng bộ theo một đồng hồ
chuẩn.
- Relying Party nên từ chối những thông điệp với timestamp qu lớn
so với thời gian hiện hành tại Relying Party.
 Tấn công phishing: Khả năng OpenID bị t n công phishing[30] l r t cao.
Năm 2009, Recordon v c c đồng nghiệp[37] đã đưa ra giải pháp nâng cao
khả năng quản lý của Identity Provider. Đây l phương ph p hiệu quả nhằm
hạn chế t n công phishing. Để nâng cao khả năng quản lý của Identity
Provider, nhóm chúng tôi đã xây dựng thành phần Identity Provider trên
thiết bị di động, là thiết bị được quản lý trực tiếp bởi người dùng với độ an
toàn bảo mật thông tin cao nhằm ngăn chặn phương ph p t n công
phishing.
 Vấn đề bảo mật đường truyền: Sử d ng SSL[25] r t quan trọng đối với hệ
thống OpenID, SSL mã hóa t t cả dữ liệu tại tầng vận chuyển và r t được
sử d ng r t phổ biến như một phương thức bảo mật khi truyền dữ liệu trên
mạng. SS được đề nghị cho mọi giao tiếp giữa Relying Party, Identity
Provider và Browser.
 Vấn đề về lịch sử trình duyệt: Do một số thông điệp OpenID được chuyển
bằng HTTP GET, vì vậy có khả năng những thông điệp n y được lưu trữ tại
lịch sử trình duyệt (Browser History). Nếu một người t n công truy cập
được vào máy, lịch sử trình duyệt có thể chứa r t nhiều thông tin quan trọng
liên quan đến người dùng. V n đề n y thường xảy ra khi người dùng sử
d ng m y tính công cộng, l m y có nhiều người sử d ng. Giải pháp cho
v n đề n y l nâng cao nhận thức và hiểu biết của người dùng. Người dùng
nên xóa t t cả to n bộ lịch sử trình duyệt sau khi sử d ng xong. Việc đề
xu t xây dựng Identity Provider trên thiết bị di động có thể khắc ph c được
v n đề này. T t cả các thuộc tính định danh chỉ được lưu trữ ở trên thiết bị
di động v được mã hóa khi lưu trữ. Thuộc tính định danh quan trọng của
người dùng trong mô hình đề xu t được mã hóa bằng public key của

9. 36
Relying Party v được truyền ra bên ngoài. Tuy nhiên, chỉ có Relying Party
mới có khóa bí mật để giải mã thông điệp này nên thuộc tính định danh
quan trọng vẫn được an toàn. Các thuộc tính định danh kh c lưu trữ ở máy
tính bên ngo i được mã hóa bằng password của người dùng, vì vậy chỉ có
người dùng mới có thể sử d ng được thuộc tính.
3.3.2 Các v n đ v tính ti n dụng
 Khả năng phòng tránh lỗi
Khó khăn lớn nh t của hệ thống OpenID đối với người dùng l người dùng vẫn
phải nhớ URL của Identity Provider tương ứng dùng để chứng thực. Nếu người dùng
sử d ng nhiều Identity Provider, thì việc phải nhớ t t cả các thông tin về từng Identity
Provider sẽ trở nên khó khăn. Qu trình điền URL không chính xác sẽ gây ra lỗi cho
hệ thống.
Nhận xét: Giải pháp mà chúng tôi đề xu t dựa trên ý tưởng của Window
Cardspace là xây dựng plugin trên trình duyệt cho phép người dùng chọn thành phần
Identity Provider một cách trực quan. Plugin này sẽ tự động điền UR tương ứng mà
người dùng chọn. Chức năng điền tự động URL mang lại tính thân thiện và tính phòng
tránh lỗi cho người dùng. Chức năng n y cũng đã được thể hiện thông qua phần mềm
Seatbelt[13] là một plugin trên firefox. Khi người dùng chọn vào một ô có điền URL
của OpenID. Nếu chưa đăng nhập Identity Provider, Seatbelt sẽ hiện lên màn hình hỏi
người dùng có muốn đăng nhập không (xem Hình 3.8). Ngược lại, nếu người dùng đã
đăng nhập Identity Provider rồi, Seatbelt sẽ tự động điền UR v o ô tương ứng. Tuy
nhiên, thông tin ở Seatbelt chỉ được lưu trữ trên máy tính cá nhân gây b t tiện cho quá
trình định danh của người dùng trên các máy khác nhau. Hơn nữa, khi một tổ chức
khác biết được danh sách các Relying Party người dùng sử d ng sẽ làm vi phạm tính
riêng tư của người dùng. Những thông tin về URI được chúng tôi đề xu t lưu trữ trên
điện thoại để giải quyết các v n đề trên.

10. 37
Hình 3.8 Plugin quản đ nh danh Seatbelt cho trang Get Satisfaction[19]
 Khả năng tương thích với các chức năng vốn có của hệ thống
Hiện nay, hệ thống OpenID chưa thể áp d ng tự động cho các hệ thống sẵn có trên
mạng. Muốn áp d ng được OpenID thì các hệ thống này phải tự chỉnh sửa trang web
của mình cho phù hợp với hệ thống. Điều này làm giới hạn phạm vi sử d ng của hệ
thống OpenID.
Nhận xét: Giải ph p chúng tôi đề xu t l điền thuộc tính tự động vào các trang web
có sẵn với các thuộc tính định danh được truyền từ điện thoại di động. Chức năng n y
được thực hiện bằng cách xây dựng một plugin trên trình duyệt. Thành phần này dựa
trên mạng ngữ ngh a sẽ tự động tìm ra những control phù hợp trên web để điền các
thuộc tính định danh thích hợp. C thể, hệ thống sẽ tự động tìm những textbox nào
dạng password, từ đó x c định textbox ngay trước đó l username để điền thuộc tính
tương ứng. Hiện nay, nhiều chương trình đã hỗ trợ điền thuộc tính tự động trên mạng
như phần mềm Sxipper[42], Passpack[22] là một plugin trên firefox. Khi một trang
đăng nhập hoặc đăng ký hiện lên, Sxipper sẽ tự động tìm những control chứa những
thuộc tính định danh (như username, password, địa chỉ, điện thoại, giới tính, …). Hình
3.9 minh hoạ quá trình Sxipper đền username v password v o trong đăng nhập của
Google.

11. 38
Hình 3.9 ăng nh p t động trang Google bằng plugin Sxipper
Tuy nhiên, thuộc tính định danh được quản lý offline trong phần mềm Sxipper nên
có một số v n đề sau:
 Các máy khác nhau trên mạng không thể sử d ng chung các dữ liệu để thực
hiện định danh được.
 Thuộc tính được lưu trên m y tính bên ngo i sẽ làm rò rỉ các thuộc tính
định danh ra bên ngoài.
Trong hệ thống cải tiến lưu trữ thuộc tính định danh trên điện thoại di động và chỉ
truyền thuộc tính khi cần thiết. Bên cạnh đó có cơ chế xóa tự động t t cả thuộc tính
sau khi sử d ng xong sẽ nhằm giải quyết hai v n đề mà plugin Sxipper gặp phải.
 Trong chương 3 chúng tôi đã trình bày chi tiết về hệ thống OpenID. Qua đó
ph n tích đ nh gi những điểm mạnh, điểm còn hạn chế của hệ thống để tiến hành
duy trì và khắc phục. Mô hình hệ thống cải tiến dựa trên hệ thống OpenID s được
chúng tôi trình bày trong chương 4.