1.6 1.2 Relying Party 1.5 1.1 Người dùng 1.4 Browser
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.
- 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.3 2.1 ước tùy chọn ước bắt buộc Relying Party 2.4 2.9 2.10 Identity Provider Người dùng 2.6 2.7 2.5 2.8 Trình duyệt 2.2
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:
- 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
3.2.3 Quy trình ki m tra thuộc tính đ nh danh
3.2 3.1
Relying Party Trình duyệt Người dùng
3.3
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 Relying Party Identity Provider 3.3 Trình duyệt Người dùng
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 ngồ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 tồn thơng tin
Độ an tồ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à:
- 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
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 tồ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.
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 ngồ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.
C ương 4 Đề xuất mô ìn
Nội dung của chương 4 trình bày về c c ơ hình đề uất và c c quy trình chính trong ơ hình à chúng tơi đề uất.
4.1.1 M h nh đ xu t
Internet
Máy tính bên ngồi
MobileIdP Website khác
Relying Party Identity Provider
Application Browser
Plugin Browser
Coordinator
Hình 4.1 M h nh đ xu t
Mơ hình đề xu t gồm các thành phần Website khác, Relying Party, Identity Provider, Browser, Controller, Plugin Browser, Application, MobileIdP được minh họa trong Hình 4.1. C c mũi tên mơ tả sự liên lạc giữa các thành phần. Mô tả chức năng về các thành phần của hệ thống được thể hiện trong Bảng 4.1.
Coordinator
Coordinator là thành phần điều phối có khả năng giao tiếp với MobileIdP để l y thuộc tính định danh của người dùng sau đó sẽ truyền thuộc tính n y đến các thành phần Plugin Browser để điền thông tin vào các website. Hơn nữa, Coordinator có thể điền thuộc tính trực tiếp đến các ứng d ng trên máy tính cá nhân. Cuối cùng, Coordinator có thể giao tiếp với Identity Provider để truyền các thuộc tính định danh quan trọng.
Plugin Browser
Plugin Browser là một plugin trên Browser có nhiệm v nhận thuộc tính định danh từ thành phần Coordinator. Sau đó sẽ điền thuộc tính tự động vào Relying Party hay các trang web khác.
Browser
Browser là trình duyệt của người dùng. Người dùng có thể sử d ng nhiều trình duyệt kh c nhau như Firefox, Internet Explorer, Chrome…
Application
Thành phần Application là những ứng d ng trên desktop không hỗ trợ OpenID như Yahoo Messenger, Skype, Google Talk... Hệ thống có khả năng điền thuộc tính định dnah tự động vào các ứng d ng này.
Website khác
Thành phần này bao gồm các trang web trên mạng không hỗ trợ OpenID như c c trang đăng nhập và các trang đăng ký người dùng của Google Mail, Yahoo Mail... Hệ thống có khả năng điền tự động các thuộc tính định danh vào vị trí thích hợp trên các website này.
4.2 Q nh đ nh danh sử dụng MobileIdP
4.2.1 V n đ
Thành phần Identity Provider là thành phần quản lý các thuộc tính định danh của người dùng. Nếu Identity Provider là thành phần khơng tin cậy, thì thuộc tính của người dùng r t dễ bị lộ ra các tổ chức bên ngoài. Trường hợp thứ nh t là thành phần Identity Provider cố ý sử d ng trực tiếp hay chuyển những thuộc tính này cho các tổ chức bên ngo i. Trường hợp thứ hai là hệ thống bảo mật ở Identity Provider không an tồn. Từ đó, tổ chức bên ngồi t n cơng để l y thuộc tính định danh người dùng.
4.2.2 Hướng giải quy t
Để giải quyết v n đề n y, chúng tôi đã tiến hành chia các thuộc tính định danh thành hai loại:
Các thuộc tính định danh quan trọng (mã tài khoản credit card, mật khẩu
TM…) sẽ được lưu trữ và quản lý bởi MobileIdP. Thuộc tính được lưu trữ trên MobileIdP trở nên an to n hơn do điện thoại di động là thiết bị quản lý trực tiếp bởi người dùng bằng mã PIN. Hơn nữa, hệ thống cải tiến cịn có thêm một password để bảo vệ thơng tin.
Các thuộc tính định danh thông thường (tên đăng nhập, ngày sinh, giới