Microsoft CardSpace là hệ thống thương mại đầu tiên được xây dựng[3], được tích hợp sẵn trong Windows Vista. Thành phần quan trọng của Window CardSpace là Identity Selector, có vai trò quản lý các yêu cầu v thông điệp truyền qua lại giữa các thành phần. Kiến trúc tổng quan của hệ thống Window CardSpace được minh họa trong Hình 2.8.
ISS
Self-issued IdP
ưu trữ bảo mật Kích hoạt trong IE Kích hoạt ứng
d ng windows InfoCardAPI Replying Party Identity Provider Hệ thống tập tin (c c tập tin đã được mã hóa) Những card được đưa v o hệ thống
Control Panel Applet WCF App
IE 7.0
Secure User Interface
Hình 2.8 Ki n trúc t ng quát Microsoft CardSpace[3]
Nhận xét: Microsoft CardSpace là sản phẩm mã nguồn đóng nên hạn chế khả năng
tùy biến và mở rộng. Vì vậy, chúng tôi đã không thể dựa trên hệ thống n y để phát triển được. Tuy nhiên, thành phần Identity Selector có nhiệm v liên lạc tự động với
các thành phần khác trong hệ thống quản lý định danh l m cho qu trình định danh của người dùng trở nên dễ dàng hơn; điều mà hệ thống OpenID chưa có. Vì vậy, trong hệ thống chúng tôi đề xu t dựa trên hệ thống OpenID đã xây dựng cải tiến thành phần Identity Selector giúp cho hệ thống trở nên tiện d ng hơn cho người dùng.
2.5.2 Ki n trúc Higgins
Higgins[43] là framework mã nguồn mở, cho phép tích hợp định danh, thông tin c nhân, thông tin quan hệ xã hội giữa các hệ thống riêng lẻ. Dựa trên Higgins, mỗi nhóm nghiên cứu/tổ chức có thể xây dựng PI chung để quản lý v thao t c trên định danh từ nhiều nguồn với c c định dạng và giao thức khác nhau. Các thành phần chính của Higgin được minh họa trong Hình 2.9.
Hình 2.9 Ki n trúc t ng quan Higgins[43]
2.5.3 Bandit
Bandit[34] là một dự án mã nguồn mở, độc lập môi trường. Các thành phần của Bandit xây dựng dựa trên kiến trúc Higgin. Bandit chủ yếu xây dựng Identity Selector
và cung c p c c phương thức để các thành phần khác có thể dễ dàng giao tiếp với thành phần Identity Selector này. Kiến trúc tổng quát của hệ thống andit được minh họa trong Hình 2.10.
Identity Selector Remote IdP
Self-Issued IdP
Card Store Provider Registry
File Store Bluetooth Store
Higgins Identity Attribute Service (IdAS) LDAP IdP OpenID IdP Other IdP Hình 2.10 Ki n trúc t ng quát Bandit[34] 2.5.4 OpenID
OpenID là một dịch v chia sẻ định danh cho phép người dùng đăng nhập vào nhiều trang web khác nhau chỉ cần sử d ng một định danh số duy nh t. 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. Hiện tại, có r t nhiều hệ thống quản lý định danh và OpenID là một trong những hệ thống quản lý định danh có được nhiều người sử d ng nh t. OpenID là một hệ thống mở nên có thể dễ dàng mở rộng để đ p ứng các nhu cầu định danh khác nhau của người dùng. OpenID được sử d ng bởi các hệ thống lớn như Yahoo, Google, Microsoft…
Nhận xét: Mặc dù trong năm 2008, andit v Higgin được đ nh gi l mã nguồn mở tốt nh t[28]. Nhưng phạm vi sử d ng của Bandit và Higgin khá hạn chế. Phần lớn
các hệ thống quản lý định danh dựa trên Bandit và Higgin trong các công trình[1][18] đều chỉ sử d ng trong phạm vi nghiên cứu hoặc trong phạm vi một tổ chức cố định. Hệ thống OpenID có phạm vi sử d ng phổ biến hơn trên môi trường mạng nhờ vào tính dễ sử d ng và dễ thiết lập của hệ thống. Tuy nhiên, OpenID vẫn còn một số hạn chế (sẽ được chúng tôi phân tích ở phần 3.3). Vì vậy, nhóm chúng tôi đã chọn hệ thống OpenID để cải tiến nhằm khắc ph c những hạn chế của hệ thống; đồng thời cũng tận d ng được sự sử d ng rộng rãi của hệ thống OpenID trên cộng động mạng.
Nội dung Chương 2 đã trình bày c c h i niệ cơ bản về hệ thống quản lý định danh, các thành phần chính có thể có trong một hệ thống quản lý định danh. Chi tiết về hệ thống quản lý định danh OpenID s được trình bày trong Chương 3. Tr n cơ sở này chúng tôi s trình bày ô hình chúng tôi đề xuất để cải tiến OpenID trong Chương 4.
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.
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.31.6 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 Relying Party.
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 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à:
- 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ị