28                                C ương 3                      Tổng quan về ệ t ống OpenID     Nội dung của Chương 3 ...
29                     Relying Party                   Identity Provider                                       BrowserHình...
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 ...
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 p...
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...
333.2.3 Quy trình ki m tra thuộc tính đ nh danh                  3.1                                      3.2             ...
343.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...
35      -   Relying Party và Identity Provider nên dùng NTP (Network Time          Protocol) để giữ cho đồng hồ luôn được ...
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 để g...
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...
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ý offlin...
Upcoming SlideShare
Loading in …5
×

Open id

815 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
815
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
32
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Open id

  1. 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àys đượ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 SixApart[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âydựng thành phần Identity Provider như Google, Yahoo, Microsoft, Facebook… Danhsá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 cB. Đ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 bathà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ủahệ thống định danh. OpenID cung c p cho người dùng URI[6] duy nh t để đăng nhập vào nhữngRelying Party khác nhau. URI đóng vai trò l Managed Card (đã trình b y ở phần2.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ủaIdentity Provider. Tuy nhiên, URI không nh t thiết phải l địa chỉ Identity Provider. Ví d , URI thậtcủa Identity Provider có thể lưu ở một m y kh c như trong Hình 3.2. Trong trườnghợ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. 2. 29 Relying Party Identity Provider BrowserHì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 URIHì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 Partycó 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ệnthê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 3quy trình con sau:
  3. 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 trongHì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. 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. 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. 6. 333.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ọatrong 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 trathuộ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ànvới Identity Provider để kiểm tra thuộc tính định danh. C c bước khác ở chế độ Dumbmode hoàn toàn giống với chế độ Smart mode. Hình 3.7 minh họa quá trình kiểm trathuộc tính định danh ở chế độ Dumb mode khác so với chế độ Smart mode ở bước3.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. 7. 343.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ênnhững tiêu chí đ nh gi một hệ thống quản lý định danh đã được trình bày trong phần2.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 , IdentityProvider 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 websitengườ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ể ảnhhưở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 racá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ànhphầ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ácphươ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ộtsố 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. 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. 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ẫnphải nhớ URL của Identity Provider tương ứng dùng để chứng thực. Nếu người dùngsử d ng nhiều Identity Provider, thì việc phải nhớ t t cả các thông tin về từng IdentityProvider 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 chohệ 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 WindowCardspace là xây dựng plugin trên trình duyệt cho phép người dùng chọn thành phầnIdentity 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òngtrá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ềmSeatbelt[13] là một plugin trên firefox. Khi người dùng chọn vào một ô có điền URLcủa OpenID. Nếu chưa đăng nhập Identity Provider, Seatbelt sẽ hiện lên màn hình hỏingườ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. Tuynhiê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ứckhá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ínhriê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. 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ênmạng. Muốn áp d ng được OpenID thì các hệ thống này phải tự chỉnh sửa trang webcủ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 webcó 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ựatrên mạng ngữ ngh a sẽ tự động tìm ra những control phù hợp trên web để điền cácthuộc tính định danh thích hợp. C thể, hệ thống sẽ tự động tìm những textbox nàodạng password, từ đó x c định textbox ngay trước đó l username để điền thuộc tínhtương ứng. Hiện nay, nhiều chương trình đã hỗ trợ điền thuộc tính tự động trên mạngnhư 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ữngthuộc tính định danh (như username, password, địa chỉ, điện thoại, giới tính, …). Hình3.9 minh hoạ quá trình Sxipper đền username v password v o trong đăng nhập củaGoogle.
  11. 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êncó 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ínhsau 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ànhduy 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 đượcchúng tôi trình bày trong chương 4.

×