Các thông số mật mã của trạng thái phiên được tạo ra bởi giao thức bắt tay TLS, hoạt động trên đầu trang của TLS Layer. Khi một khách hàng TLS và máy
Nghiên cứu thử nghiệm các cơ chế xác thực sử dụng OpenID và ứng dụng
---
chủ đầu tiên bắt đầu giao tiếp, họ đồng ý trên một phiên giao thức, chọn thuật toán mã hóa, tùy chọn xác thực lẫn nhau, và sử dụng kỹ thuật mã hóa khóa công khai để
thực hiện truyền thông.
Hình 2.15. Cấu trúc giao thức bắt tay 2.6. Những vấn đề phát sinh với OpenID
2.6.1. Tính nặc danh và độ an toàn thông tin
! Tính nặc danh
Nếu sử dụng Identity Provider của một 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 đã đề xuất ra các giải pháp đề khắc phục được vấn đề này là:
Nghiên cứu thử nghiệm các cơ chế xác thực sử dụng OpenID và ứng dụng
---
• 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.
! Độ 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. 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.
Hình 2.16. Ví dụ về giá trị ngẫu nhiên nonce trong 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 là rất cao. Năm 2009, Recordon và các đồng nghiệp đã đưa ra giải pháp nâng cao khả năng
Nghiên cứu thử nghiệm các cơ chế xác thực sử dụng OpenID và ứng dụ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.
• Vấn đề bảo mật đường truyền: Sử dụng SSL 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à đượ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. SSL đượ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.
2.6.2. Khả năng phòng tránh lỗi và tương thích với các chức năng vốn có của hệ thống vốn có của hệ thố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 dung 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.
! 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
Nghiên cứu thử nghiệm các cơ chế xác thực sử dụng OpenID và ứng dụng
---
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.
2.7. OpenID kết hợp với OAuth
Như ta đã biết OpenID luôn tập trung vào cách thức xác thực (authentication) người dùng với trình duyệt. Còn OAuth được phát triển để cho phép uỷ quyền (authorization) từ web, ứng dụng desktop hay các ứng dụng di động. Rõ ràng đã có sự quan tâm đặc biệt trong việc sử dụng kết hợp OpenID và OAuth cho phép người sử dụng chia sẻ định danh hay cấp quyền cho một Relying Party truy cập tới một tài nguyên được bảo vệ bởi OAuth chỉ qua một bước.
a, OpenID OAuth extensions
Một nhóm các nhà nghiên cứu đang làm việc để phát triển một chuẩn mở
rộng đối với OpenID nhằm tạo ra một giao thức xác thực có nhúng phê duyệt yêu cầu OAuth vào một yêu cầu xác thực từ OpenID. Để làm được điều này trước tiên ta phải xây dựng hai web service.
- Một Consumer kết hơp: Là một web service đồng thời đóng vai trò như một OpenID Relying Party (RP) và một OAuth Consumer.
- Một Provider kết hợp: Là một web service đồng thời đóng vai trò như một OpenID Identity Provider (OP) và một OAuth Service Provider (SP).
Thêm vào đó cần có sự kết hợp giữa các thông điệp của OpenID với việc sử dụng request token và access token trong OAuth authorization. Sau đây là một vài ví dụ
Nghiên cứu thử nghiệm các cơ chế xác thực sử dụng OpenID và ứng dụng
---
Hình 2.17. Luồng lai OpenID/OAuth2 với Spark API.
Nghiên cứu thử nghiệm các cơ chế xác thực sử dụng OpenID và ứng dụng
---
1: WebApp: Yêu cầu đăng nhập.
2: End-User: Lựa chọn đăng nhập với một OpenID Provider. 3: WebApp: Xác nhận sự tồn tại của provider.
4: Provider: Tồn tại, cho phép thực hiện tiếp.
5: WebApp: Tạo một phiên giao dịch, Yêu cầu được xác nhận cho end-user được gửi đến provider.
6: Provider: Chuyển người dùng đến trang đăng nhập của Provider. 7: End-user: Đăng nhập bằng tài khoản đã tạo tại Provider.
8: Provider: Báo cho WebApp người dùng tồn tại (Kèm theo thông tin phiên giao dịch).
9: WebApp: Xác nhận đăng nhập thành công, tiếp tục các tác vụ trước.
b, OpenID Connect
OpenID Connect chính là thế hệ tiếp theo của OpenID 2.0. Điểm khác biệt giữa OpenID Connect vẫn giữ nhiều tác vụ giống như OpenID 2.0 nhưng với giao diện lập trình thân thiện hơn. OpenID Connect định nghĩa các cơ chế tuỳ mạnh mạnh mẽ dành cho ký và mã hoá. Khác với sự kết hợp OAuth 1.0a và OpenID 2.0 như là một sự mở rộng ở mô hình trên. OpenID Connect đã được tích hợp OAuth 2.0 vào trong chính giao thức của mình.
Nghiên cứu thử nghiệm các cơ chế xác thực sử dụng OpenID và ứng dụng
---
Hình 2.19. OpenID Connect protocol 2.8. Kết luận chương
Như vậy trong chương này đã giới thiệu chi tiết về OpenID, bao gồm các thành phần chính và các thức hoạt động. Chương tiếp theo sẽđề xuất mô hình đăng nhập một lần sử dụng chuẩn OpenID áp dụng cho hệ thống y tế trên cơ sởđám mây.
Nghiên cứu thử nghiệm các cơ chế xác thực sử dụng OpenID và ứng dụng
---
CHƯƠNG 3 – ĐỀ XUẤT MÔ HÌNH ĐĂNG NHẬP MỘT LẦN TRONG HỆ THỐNG QUẢN LÝ THÔNG TIN Y TẾ
TRÊN CƠ SỞ ĐÁM MÂY VÀ THỬ NGHIỆM MÔ ĐUN ĐĂNG NHẬP MỘT LẦN SỬ DỤNG OPENID
Chương này trình bày về những vấn đề phát sinh với quá trình xác thực của một hệ thống thông tin y tế trên cở sởđám mây, qua đó đề xuất mô hình đăng nhập một lần, phân tích thiết kế và đánh giá tính khả thi của mô hình. Cuối chương luận văn sẽ đưa ra những thử nghiệm và đánh giá về hoạt động của mô đun đăng nhập một lần sử dụng OpenID trong quá trình xác thực trên các miền phụ khác nhau.
3.1. Giới thiệu mô hình
3.1.1. Hệ thống y tế trên cơ sở đám mây.
Nghiên cứu thử nghiệm các cơ chế xác thực sử dụng OpenID và ứng dụng
---
Khi nói đến các xu hướng công nghệ trên toàn cầu, điện toán đám mây luôn là một trong những chủ đề được quan tâm nhất. Những lợi ích mà điện toán đám mây đem lại cho hệ thống thông tin y tế có thể kểđến:
- Bảo mật thông tin bệnh nhân: Bảo mật thông tin bệnh nhân là điều tối quan trọng trong hệ thống y tế. Đáp ứng an toàn dữ liệu thật tốt với lưu trữ trên đám mây sẽ giúp giảm thiểu những rủi ro về hồ sơ lưu trữ giấy.
- Giảm thiểu chi phí: Lưu trữ dữ liệu trên đám mây có giá trung bình rẻ hơn 10 lần so với việc mua thêm không gian máy chủ cùng với chi phí đào tạo chuyên gia tại chỗđể quản lý, vận hành chúng.
- Dễ dàng chia sẻ: Việc truy cập vào hệ thống bệnh viện là một hành động bị
cấm, trừ khi được phép của bác sĩ hay người phụ trách quản lý do có rất nhiều thông tin bí mật và nhạy cảm. Tuy vậy, tính minh bạch trong hệ thống thông tin y tế cũng
đang ngày càng trở nên quan trọng và điện toán đám mây cho phép những người dùng khác nhau truy cập thông tin tại những địa điểm khác nhau. Đám mây có thể
giúp bác sỹ tiếp cận nhanh với dữ liệu về hồ sơ sức khỏe của bệnh nhân hay một bác sĩ dù đang công tác ở nước ngoài vẫn có thể cho bệnh nhân tiếp cận thông tin mà không nhất thiết phải có mặt tại phòng khám. Ngược lại, bệnh nhân có thể ngay