Người dùng phải có password mới sử d ng được thành phần Plugin Browser. Password người dùng chỉ nhập lần đầu tiên trong quá trình sử d ng. Thành phần Coordinator có các chức năng chính bao gồm:
Nhận các thuộc tính định danh từ thành phần Coordinator. Đây l những thuộc tính định danh mà Coordinator nhận được từ MobileIdP trước đó. Điền thuộc tính định danh tự động vào các trang web có sẵn trên mạng như
Google Mail, Yahoo Mail... Hình 5.7 minh họa qu trình điền thông tin tự động vào trong Google Mail.
Hình 5.9 i n t động URI vào trang LiveJournal[29] 5.3 K t quả thử nghi m
Bảng 5.2 mô tả một số kết quả thử nghiệm hệ thống bao gồm các thuật toán mã hóa đối xứng và b t đối xứng có sử d ng trong hệ thống.
Bảng 5.2 Th ng kê thời gian ký và giải mã thuộc nh đ nh danh quan trọng Chức năng Thu t toán Thời gian
(mili giây) Tham s
Thời gian mã hóa b t đối xứng (MobileIdP)
RSA 1433 Chiều d i thông điệp
là chuỗi 10 ký tự Thời gian giải mã b t
đối xứng (MobileIdP)
RSA 31 Chiều d i thông điệp
là chuỗi 10 ký tự Thời gian mã hóa đối
xứng (MobileIdP)
Rijndael 256 bit
124 Chiều d i thông điệp
là chuỗi 528 ký tự Thời gian giải mã đối
xứng
Rijndael 256 bit
62 Chiều d i thông điệp
là chuỗi 528 ký tự
Trong các thông kê này, thời gian mã hóa b t đối xứng trên điện thoại tốn nhiều thời gian nh t. Do điện thoại di động hạn chế về tốc độ và khả năng xử lý. Các thời gian xử lý trên mạng cũng như m y tính bên ngo i kh nhanh. Vì vậy, có thể áp d ng hệ thống vào thực tế.
Trong chương này chúng tôi đã trình bày về mô hình triển khai của hệ thống đề nghị. Trong Chương 6 chúng tôi s trình bày về kết luận cũng như hướng phát triển của đề tài trong tương lai.
C ương 6
Kết luận v ướng p át triển
Nội dung của chương 6 trình bày về những kết quả đã đạt được trong luận văn và hướng phát triển của luận văn trong tương lai.
6.1 K t quả đạ được đ tài
Luận văn đã tìm hiểu, phân tích, đ nh gi về hệ thống quản lý định danh OpenID. Từ đó, chúng tôi đã tìm ra những ưu điểm và khuyết điểm của hệ thống OpenID. Dựa trên kết quả phân tích, chúng tôi đã tiến h nh đề xu t những mô hình cải tiến dựa trên hệ thống OpenID chuẩn. Mô hình cải tiến của hệ thống đã giải quyết hai v n đề chính:
Luận văn đã đề xu t phân loại thuộc tính định danh thành hai phần: Loại thứ nh t là các thuộc tính định danh thông thường được lưu trữ trên mạng. Loại thứ hai là các thuộc tính định danh đặc biệt quan trọng được lưu trữ trên thiết bị di động. Dưa trên việc phân loại thuộc tính định danh, luận văn đã đề xu t mô hình sử d ng hai loại thuộc tính định danh một cách hợp lý vừa đảm bảo tương thích với các hệ thống quản lý định danh sẵn có, vừa có thể bảo vệ an toàn những thông tin bảo mật.
Để tương thích với các Relying Party trên mạng, luận văn đã đề xu t giải ph p điền thông tin tự động lên các Relying Party. Cải tiến này nhằm mở rộng hệ thống không những tương thích với các hệ thống đã hỗ trợ sẵn OpenID, mà hệ thống còn có khả năng tương thích với các hệ thống không hỗ trợ OpenID.
Luận văn còn tiến hành phân tích những v n đề liên quan đến hệ thống đã đề xu t dựa trên những tiêu chí chuẩn khi xây dựng một hệ thống quản lý định danh. Qua đó đã đề xu t sử d ng cơ chế mã hóa b t đối xứng bằng c ch mã hóa thông điệp chứa thuộc tính định danh quan trọng bằng public key của Relying Party. Bên cạnh đó, luận văn cũng đề xu t các cơ chế truyền và nhận thông điệp giữa các thành phần để đảm bảo chỉ có đúng th nh phần Relying Party mới có thể giải mã được thông điệp bằng cách hiện lên thông tin về public key về Relying Party cho người dùng kiểm tra và xác nhận.
Luận văn không những là mô hình thử nghiệm v đã triển khai trên thực tế để kiểm tra tính tương thích với các hệ thống khác trong phân tích của hệ thống. Ngoài ra, trong phạm vi luận văn cũng đã tiến hành khảo s t v đưa ra những kết quả thống kê về thời gian mã hóa, giải mã của thuật toán b t đối xứng, đối xứng...
6.2 Hướng phát tri n
Mặc dù luận văn đã có nhiều thử nghiệm, tuy nhiên hệ thống vẫn chưa được áp d ng rộng rãi trên mạng. Hướng sắp tới sẽ hoàn thiện, bổ sung các chức năng giúp cho hệ thống trở nên hoàn thiện hơn như:
Sử d ng C để kiểm tra public key của Relying Party, đồng thời l y thông tin Relying Party từ C để hiện lên cho người dùng xác thực. Điều này nhằm đảm bảo kẻ t n công không thể cung c p thông tin giả để lừa người dùng l y được thông tin cá nhân.
Áp d ng mạng ngữ ngh a để điền vào các trang b t kỳ trên mạng chứ không dừng lại ở hỗ trợ cho c c trang đăng nhập đơn giản nhập username và password hay điền tự động thông tin đăng ký v o c c trang đã biết trước c u trúc như hiện nay để tăng phạm vi sử d ng của hệ thống.
Triển khai rộng rãi hệ thống ở trên mạng, để qua đó nhận được những sự phản hồi từ nhiều người dùng nhắm cải thiện hệ thống được tốt hơn.
P ụ lục A CÁC T ÔNG ĐIỆP CỦA OPENID
Để hoàn thành quá trình chứng thực, các thành phần trong OpenID sẽ phải trao đổi nhiều thông điệp khác nhau. Những thông điệp n y đều theo một định dạng chuẩn, Relying Party và Identity Provider phải tuân theo những định dạng n y để giao tiếp.
Mỗi thông điệp sẽ có một cặp (request và response). Request và response có thể có những tập tham số khác nhau. Tùy vào loại thông điệp, Relying Party và Identity Provider sẽ sử d ng phương ph p liên lạc trực tiếp hay gián tiếp (HTTP POST dùng cho liên lạc trực tiếp và HTTP GET dùng cho liên lạc gián tiếp).
Sau đây l một số c c thông điệp cơ bản được sử d ng trong hệ thống OpenID: Thông điệp associate.
Thông điệp checkid_immediate. Thông điệp checkid_setup.
Thông điệp check_authentication. Thông điệp associate request:
Thông điệp asscociate request được gửi từ Relying Party tới Identity Provider. M c đích chính của thông điệp associate request l để thiết lập một khóa chia sẻ bí mật giữa Relying Party v Identity Provider. Thông điệp này có thể được Relying Party gửi vào b t cứ lúc nào. Đây là một liên lạc trực tiếp giữa Relying Party và Identity Provider nên HTTP POST được sử d ng cho thông điệp associate. Relying Party sẽ gửi một số các tham số kèm với associate request. Sau đây l danh s ch c c tham số của associate request:
openid.ns: đây là một tham số tùy chọn. Tham số n y dùng để khai báo phiên bản OpenID. Nếu tham số openid.ns không được khai báo, hệ thống sẽ tự hiểu phiên bản của OpenID là OpenID Authentication Compatibility Mode.
openid.mode: tham số n y dùng để phân biệt loại thông điệp. C thể ở đây
openid.assoc_type: tham số n y được dùng để chỉ ra thuật toán sử d ng để
ký lên thông điệp. Ở đây có hai giá trị có thể có l : “HM C-SH 1” v “HM C-SH 256”.
openid.session_type: được dùng để khai báo loại mã hóa được sử d ng trong thông điệp để mã hóa khóa MAC (Message Authentication Code). Thuật toán sẽ dùng một khóa cá nhân cùng với một thông điệp như đầu vào và cho ra một đoạn mã. Trong OpenID hỗ trợ hai thuật to n “DH-SH 1“ v “DH-SH 256”. Nếu giá trị của tham số n y l “no-encryption”, MAC sẽ không được mã hóa. Điều này chỉ nên sử d ng khi sử d ng một kết nối SSL giữa Relying Party và Identity Provider.
openid.dh_modulus: tham số đi kèm với DH-SHA1 hoặc DH-SHA256.
openid.dh_gen: tham số đi kèm với DH-SHA1 hoặc DH-SHA256.
openid.dh_consumer_public: tham số đi kèm với DH-SHA1 hoặc DH- SHA256.
Ba tham số trên là các thông số cho thuật toán DH-SHA1 và DH-SHA256, chi tiết về việc sinh ra giá trị cho các tham số n y được nêu chi tiết trong RFC-2631 (Diffie- Hellman Key Agreement Method)[39]. Bảng A.1 là một ví d về thông điệp associate request.
Bảng A.1 Ví dụ v mộ h ng đi p associate request
openid.mode=associate&openid.assoc_type=HMAC-SHA1 &openid.session_type=DH-SHA1 &openid.dh_consumer_public=KC6IpA00A6SlCikafFSlrTGql9H8+de6GFi5YLK z4pyDxUMS5Z8pMOm/Ptr1gFmCcgAXjFbuxS73ZutDTFJYpADoIntFVrah9eaezMcw6 SDR24cnFjNc14xq0zGt3QcRLXaNTRVKfMW8evDAmLCrvEhU5c7B3eqmk+bMMrbQpcE =&openid.dh_modulus=ANz5OguIOXLsDhmYmsWizjEOHTdxfo2Vcbt2I3MYZuYe91 ouJ4mLBX+YkcLiemOcPym2CBRYHNOyyjmG0mg3BVd9RcLn5S3IHHoXGHblzqdLFEi/ 368Ygo79JRnxTkXjgmY0rxlJ5bU1zIKaSDuKdiI+XUkKJX8Fvf8W8vsixYOr&openi d.dh_gen=Ag==
Thông điệp associate response:
Thông điệp associate response được gởi từ Identity Provider đến Relying Party. Đây l một thông điệp HTTP 200 được định ngh a trong Hypertext Transfer Protocol [RFC 2616][15]. Thông điệp này chỉ ra sự kết hợp giữa Identity Provider và Relying Party thành công hay th t bại. Trong trường hợp kết hợp th nh công, thông điệp sẽ bao gồm một xử lý thông điệp và thời gian sống của xử lý đó tính bằng giây. Ngược lại, một lỗi sẽ được trả về. Danh sách các tham số của associate response:
openid.ns: đã được giải thích ở trên.
openid.assoc_handle: tham số này chỉ ra một chuỗi ASCII với chiều dài tối
đa 255 ký tự được dùng để quyết định khóa nào sẽ được sử d ng lại cho quá trình mã hóa và giải mã.
openid.session_type: tham số này giống như trong trường hợp request nếu
kết hợp thành công. Ngược lại, tham số này sẽ l “unsuccessful response”. Có nhiều lý do khác nhau cho việc kết hợp không thành công. Ví d , Relying Party yêu cầu sử d ng SH 256 nhưng Identity Provider chỉ hỗ trợ SHA1.
openid.assoc_type: tham số này giống như trong trường hợp request nếu
kết hợp th nh công. Ngược lại, tham số này sẽ l “unsuccessful response”. openid.expires_in: tham số này chỉ ra thời gian (tính bằng giây) sự kết hợp
này sẽ không còn hiệu lực nữa và relying party nên yêu cầu một sự kết hợp mới.
openid.mac_key: tham số n y được sử d ng chỉ khi giá trị của
“openid.session_type” l “no-encryption”. Gi trị của tham số này là khóa MAC mã hóa dựa trên cơ số 64.
openid.dh_server_public: tham số này là khóa công cộng của Identity
Provider. Tham số n y được sử d ng nếu request yêu cầu sử d ng thuật toán Diffie-Hellman.
openid.enc_mac_key: tham số n y l khóa M C đã được mã hóa, được sử
d ng nếu request yêu cầu sử d ng thuật toán Diffie-Hellman. Bảng A.2 là một ví d về thông điệp associate response.
openid.assoc_handle: tham số này là tùy chọn. Tham số này chỉ ra một sự
kết hợp đã được khởi tạo giữa OpenID và Relying Party. Tham số n y đã được miêu tả trong phần associate request.
openid.return_to: tham số n y được sử d ng để khai báo cho máy chủ
OpenID vị trí của UR nơi sẽ chuyển tiếp cho trình duyệt sau khi xử lý yêu cầu. Máy chủ OpenID sẽ sử d ng địa chỉ UR n y để gởi response về cho Relying Party.
openid.realm: một tham số tùy chọn khác chỉ ra một URL máy chủ sử
d ng để định danh một Relying Party trong một cách duy nh t. Realm có thể bao gồm các ký tự wildcard như “*”. Ví d , realm có thể là
http://*.conformix.com.
Bảng A.3 là một ví d về thông điệp checkid_setup request.
Bảng A.3 Ví dụ v một h ng đi p checkid_setup request
GET /index.php/serve?openid.assoc_handle={HMAC- SHA1}{46071e25}{Tt8MwQ==} &openid.identity=http://idp.conformix.com/?user= openidbook &openid.mode=checkid_setup&openid.return_to=http://consumer.con formix.com:80/finish_auth.php?nonce=nC5sKquX&openid.sreg.optional= email&o penid.trust_root=http://consumer.conformix.com:80/ HTTP/1.1
Thông điệp checkid_setup và checkid_immediate response:
Mỗi lần máy chủ OpenID nhận thông điệp checkid_setup, OpenID sẽ xử lý và gởi phản hồi về cho Relying Party thông qua trình duyệt. Trong thông điệp phản hồi, OpenID sẽ gởi nhiều tham số về cho Relying Party. Danh sách các tham số của checkid_setup response:
openid.ns: đã được giải thích ở trên.
openid.mode: có giá trị “id_res” khi kết hợp th nh công. Ngược lại sẽ
mang giá trị:
“setup_needed” khi request l checkid_immediate. “cancel” khi request l checkid_setup.
openid.op_endpoint: chỉ ra URL máy chủ OpenID.
openid.identity: đã được giải thích ở trên.
openid.return_to: tham số này là bản sao chép của URL Relying Party đã
gởi với thông điệp request.
openid.response_nonce: tham số n y được sử d ng để tránh các t n công
replay v được dùng đơn nh t cho mỗi thông điệp, có chiều dài tối đa 255 ký tự, bao gồm một nhãn thời gian và các ký tự SCII thêm v o để trở th nh đơn nh t. Relying Party có thể từ chối kết hợp nếu nhãn thời gian quá xa so với thời điểm hiện tại. Ngày và giờ được định dạng trong phần 5.6 của [RFC3339] (Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps”)[27] với c c quy ước sau:
- Nằm trong múi giờ của UTC được nhận biết với ký tự “Z”. - Không được phép có phân số.
- Ví d : 2005-05-15T17:11:51ZUNIQUE.
openid.invalidate_handle: được sử d ng khi xử lý (handle) gắn với request
có đúng hay không. Nếu không đúng, tham số này là tùy chọn. Mặt khác, các xử lý sai nên được gắn với tham số này sẽ giúp cho Relying Party loại bỏ các xử lý sai từ các record của Relying Party.
openid.assoc_handle: handle được dùng để ký thông điệp. Handle này có
thể khác với handle gốc được Relying Party gởi với request nếu OpenID không nhận ra handle gốc. Trong trường hợp này, máy chủ sẽ giữ một bản sao chép của handle mới để Relying Party có thể sử d ng cho m c đích kiểm tra.
openid.signed: bao gồm danh sách các tham số được ký. Các tham số cách
nhau bởi d u phẩy.
openid.sig: bao gồm chữ ký được mã hóa dựa trên cơ số 64.
Bảng A.5 Ví dụ v một h ng đi p check_authentication request openid.assoc_handle={HMAC-SHA1}{460730e1}{zr1gKg==} &openid.identity=http://idp.conformix.com/?user= openidbook &openid.invalidate_handle={HMAC- SHA1}{46071e25}{Tt8MwQ==} &openid.mode=check_authentication&openid.return_to=http://consumer.c onformix.com:80/finish_auth.php?nonce=mAotRbGM&openid.sig=4hwwyWbPt SAmP2dYxEC+dq605Os=&openid.signed=mode,identity,return_to,sreg.ema il&openid.sreg.email=rr@conformix.com
Thông điệp check_authentication response:
Danh sách các tham số của check_authentication response: openid.ns: đã được giải thích ở trên.
is_valid: tham số có giá trị “true” hoặc “false” để x c định chữ ký của việc
xác thực tính hợp lệ của request.
invalidate_handle: tham số tùy chọn được sử d ng trong trường hợp tham
số is_valid mang giá trị “true”, Relying Party sẽ loại bỏ handle từ danh sách c c handle đã lưu trữ.
Bảng A.6 Ví dụ v một h ng đi p check_authentication response
invalidate_handle:{HMAC-SHA1}{46071e25}{Tt8MwQ==} is_valid:true
Để tăng tính linh hoạt v tương thích, một số mở rộng (extension) của OpenID đã được đề xu t. Một số mở rộng đã ho n thiện trong khi một số kh c còn đang trong giai đoạn phác thảo, thử nghiệm. Những thông tin mới nh t về các mở rộng có thể xem tại đây http://openid.net/developers/specs .
Những mở rộng đã v đang ph t triển có chức năng giải quyết các công việc sau: Đăng ký người dùng (User Registration): cho phép Relying Party đăng ký
người dùng mới khi họ đăng nhập lần đầu tiên vào một website.
Tra cứu khóa dịch v (OpenID Service Key Discovery) sử d ng Yadis. Thông điệp DTP (DTP Message), được mã hóa MIME.
Trao đổi thuộc tính (Attribute Exchange). Độ tin cậy của xác thực (Assertion Quality).
Quản lý chính sách chứng thực của Identity Provider (Provider Authentication Policy Extension – P PE), dùng để chống giả mạo (anti- phishing) và những m c đích kh c.
Bảng A.7 Một h ng đi p checkid_setup request với Simple Registration Extension http://idp.conformix.com/index.php/serve?openid.assoc_handle={HMA C-SHA1}{46071e25}{Tt8MwQ==}&openid.identity=http://idp.conformix. com/?user=openidbook&openid.mode=checkid_setup&openid.return_to=h ttp://consumer.conformix.com:80/finish_auth.php?nonce=nC5sKquX&op enid.sreg.optional=email&openid.trust_root=http://consumer.confor mix.com:80/
Bảng A.7 đưa ra một ví d về việc sử d ng một checkid_setup request kèm với mở rộng Simple Registration (phần in đậm) để Relying Party yêu cầu Identity Provider chứng thực URL Identity này kèm với việc cung c p email của URL Identity này.
P ụ lục B DAN SÁC CÁC Ệ T ỐNG LỚN CÓ Ỗ TRỢ OPENID
Bảng B.1 Th ng kê một s Relying Party
TỔ CHỨC NH DANH URL Google https://www.google.com/accounts/o8/id Yahoo! me.yahoo.com Microsoft accountservices.passport.net LiveJournal username.livejournal.com MySpace myspace.com/username WordPress username.wordpress.com
Blogger username.blogger.com blogid.blogspot.com
Verisign username.pip.verisignlabs.com Typepad blogname.typepad.com
MyOpenID username.myopenid.com Google Profile Google.com/profiles/username
claimID claimid.com/username
Google Profile Google.com/profiles/username Steam steamcommunity.com/openid/ Orange openid.orange.fr/username orange.fr/
Tonido OpenID http://username.tonidoid.com/app/openid Lanchpad launchpad.net/~username
seznam.cz username.id.seznam.cz username.id.email.cz xlogon.net http://xlogon.net/username
Clavid username.clavid.com
P ụ lục C