Nghiên ứu thử nghiệm á ơ hế xá thự sử dụng openid và ứng dụng

Mục đích nghiên cứu của luận văn là tìm hiểu, thử nghiệm và đánh giá các cơ chế xác thực sử dụng OpenID và ứng dụng vào một hệ thống thông tin trên cơ sở đám mây, nơi mà các thực thể thư

TỔNG QUAN VỀ XÁC THỰC VÀ GIẢI PHÁP ĐĂNG NHẬP – MỘT LẦN (SINGLE SIGN - ON)

Xác thực t rong an toàn thông tin

Xác thực (Authentication là một hành động nhằm thiết lập hoặc chứng thực ) một cái gì đó (hoặc một người nào đó) đáng tin cậy, có nghĩa lànhững lời khai báo do người đó đưa ra hoặc về vật đó là sự thật

Xác thực một đối tượng còn có nghĩa là công nhận nguồn gốc của đối tượng, trong khi xác thực một người thường bao gồm việc thẩm tra nhận dạng của họ Việc xác thực thường phụ thuộc vào một hoặc nhiều nhân tố xác thực (authentication factors) để minh chứng cụ thể

Trong an toàn thông tin máy tính nói chung, xác thực là một quy trình nhằm xác minh nhận dạng số (digital identity) của bên gửi thông tin (sender) trong liên lạc trao đổi xử lý thông tin Ngược lại sự tin cậy mù quáng hoàn toàn không thiết lập sự đòi hỏi nhận dạng, song chỉ thiết lập giới hạn quyền của người dùng hoặc của chương trình ứng dụng mà thôi.

Trong một mạng lưới tín nhiệm, việc xác thực là một cách để đảm bảo rằng người dùng chính là người mà họ nói họ là, và người dùng hiện đang thi hành những chức năng trong một hệ thống, trên thực tế, chính là người đã được ủy quyền để làm những việc đó Việc xác thực thường phụ thuộc vào một hoặc nhiều yếu tố xác thực (authentication factor) để minh chứng cụ thể.

Nghiên cứu thử nghiệm các cơ chế xác thực sử dụng OpenID và ứng dụng

Xác thực có thể được phân loại theo a Xác thực thực thể (Entity Authentication): Xác thực thực thể là xác thực định danh của một đối tượng tham gia giao thức truyền tin Thực thể hay đối tượng có thể là người dùng, thiết bị đầu cuối Tức là một thực thể được xác thực bằng định danh của nó đối với thực thể thứ hai trong một giao thức, và bên thứ hai đã thực sự tham gia vào giao thức. b Xác thực dữ liệu (Data Authentication): Xác thực dữ liệu là một kiểu xác thực đảm bảo một thực thể được chứng thực là nguồn gốc thực sự tạo ra dữ liệu này ở một thời điểm nào đó, đảm bảo tính toàn vẹn dữ liệu.

Xác thực người dùng

Khi người sử dụng muốn truy nhập vào một hệ thống máy tính, thông thường, người sử dụng cần cung cấp các thông tin nhận dạng cho máy tính Khi nhận được các thông tin ấy, máy tính kiểm tra xem người sử dụng có quyền truy nhập vào hệ thống không Đây cũng là một nguyên tắc cơ bản được áp dụng cho một người khi muốn trao đổi thông tin với người khác: Trước tiên cần phải xác định người tham gia trao đổi thông tin có đúng là người muốn trao đổi không Do đó cần phải có một phương thức để cung cấp đặc điểm nhận dạng nhằm đảm bảo người trao đổi thông tin là hợp lệ Quá trình này được gọi là xác thực người sử dụng

Trên thế giới cũng như ở Việt Nam, vấn đề xác thực người dùng đang được quan tâm và đã có nhiều giải pháp được sử dụng và nghiên cứu Có rất nhiều cách để xác thực: người sử dụng có thể cung cấp các thông tin mà chỉ có người đó mới biết: ví dụ mật khẩu, mã số cá nhân,… hoặc người đó có thể cung cấp các thông tin riêng khác như số chứng minh thư, thẻ từ, thẻ thông minh… Trong đó, mỗi giải pháp lại có những ưu điểm và nhược điểm riêng khác nhau.

Xác thực người dùng là một quá trình qua đó hệ thống có thể xác minh rằng một ai đó thực sự là họ Quá trình xác thực sẽ xác định xem một người có phải là người được sử dụng hệ thống không Nó thường đi kèm với quá trình xác định quyền hạn của người đó trong hệ thống.

1.2.1 Các nhân tố xác thự c

Những nhân tố xác thực (authentication factors) dành cho con người (người sử dụng) nói chung có thể được phân loại nhưsau: a Những cái mà người sử dụng sở hữu bẩm sinh (Something the user is):

Chẳng hạn như dấu vân tay hoặc mẫu dạng võng mạc mắt, chuỗi DNA, mẫu dạng giọng nói, chữ ký, tín hiệu sinh điện đặc thù do cơ thể sống tạo sinh (unique bioelectric signals), hoặc những địnhdanh sinh trắc học (biometric identifier) b Những cái gì người sử dụng có (Something the user possesses): Chẳng hạn như chứng minh thư (ID card), chứng chỉ an ninh (security token), chứng chỉ phần mềm (software token) hoặc điện thoại di động (cell phone) c Những gì người sử dụngbiết (Something the user knows): Chẳng hạn như mật khẩu, mật ngữ (pass phrase) hoặc mã số định danh cá nhân (personal identification number - PIN)

1.2.2 Xác thực đa yếu tố

Trong thực tế, nhiều khi một tổ hợp của những yếu tố trên được sử dụng, lúc đó người ta nói đến xác thực đa yếu tố (Multi-factor authentication)

- Chẳng hạn trong giao dịch ATM, thẻ ngân hàng và mã sốđịnh danh cá nhân (PIN) được sử dụng - trong trường hợp này đó là một trong các dạng xác thực 2 yếu tố (two-factor authentication 2FA).–

- Cũng trong ví dụ trên nếu sử dụng thêm một yếu tố nữa như dấu vân tay chẳng hạn thì ta sẽ có xác thực ba yếu tố (three-factor authentication 3FA).-

- Tương tự như vậy cho xác thực n yếu tố (n ≥ 2): n-factor authentication nFA-

Với xác thực đa yếu tố ta có thể tăng mức độ an toàn bảo mật lên rất cao nhờ việc kiểm chứng nhiều yếu tố xác thực Hiển nhiên là mức độ an toàn bảo mật sẽ càng cao khi số yếu tố xác thực càng nhiều Tuy nhiên, khi số yếu tố xác thực lớn thì hệ thống càng phức tạp kéo theo chi phí đầu tư và duy trì vận hành tốn kém, đồng thời lại bất tiện cho người sử dụng Do vậy, trên thực tế để cân bằng giữa an

- toàn bảo mật và tính tiện dụng người ta thường áp dụng xác thực hai yếu tố và xác thực ba yếu tố Nên lưu ý rằng xác thực đa yếu tố dù có mang lại mức độ an toàn bảo mật cao hơn, nhưng về lý thuyết cũng không thể là tuyệt đối an toàn nên chúng ta không bao giờ được chủ quan trong lĩnh vực an toàn thông tin.

• Một ví dụ về xác thực đa yếu tố liên quan đến giao dịch ngân hàng điện tử là xác thực chủ thẻ trong giao dịch ATM (Yếu tố xác thực đầu tiên của bạn là thẻ ATM (cái bạn có), sau khi đưa thẻ vào máy đọc bạn sẽ phải đưa tiếp yếu tố xác thực thứ hai là PIN (cái bạn biết).

• Một ví dụ khác là xác thực người sử dụng dịch vụ giao dịch Internet Banking: Bạn đăng nhập với username + password sau đó còn phải đưa tiếp OTP (mật khẩu dùng một lần) được sinh ra trên token của riêng bạn.

1.2.3 Một số giải pháp xác thực phổ biến a Giải pháp dựa trên User Name (định danh người sử dụng) và Password(mật khẩu) Đây là phương pháp truyền thống hay được sử dụng nhất, là phương pháp sử dụng tài khoản của hệ thống Mỗi tài khoản bao gồm tên truy nhập (username) và mật khẩu (password) Tên truy nhập dùng để phân biệt những người sử dụng khác nhau (thường là duy nhất trong hệ thống), còn mật khẩu để xác thực lại người sử dụng tên đó có đúng là người dùng thật sự không Mật khẩu thường do người sở hữu tên truy nhập tương ứng đặt và được giữ bí mật chỉ có người đó biết.Khi người dùng muốn đăng nhập và sử dụng tài nguyên hệ thống thì phải đăng nhập bằng cách nhập tên và mật khẩu của mình Trước hết, hệ thống sẽ đối chiếu tên truy nhập của người dùng đưa vào với cơ sở dữ liệu tên người dùng, nếu tồn tại tên người dùng như vậy thì hệ thống tiếp tục đối chiếu mật khẩu được đưa vào tương ứng với tên truy nhập trong cơ sở dữ liệu Qua 2 lần đối chiếu nếu thỏa mãn thì người đăng nhập là người dùng hợp lệ của hệ thống.

Thiết kế và sử dụng đơn giản, tốn ít tài nguyên Hệ thống chỉ gồm một cơ sở dữ liệu người dùng với hai thông tin chủ yếu là tên truy nhập và mật khẩu Tương ứng với mỗi tên truy nhập là quyền sử dụng của người đó trong hệ thống Do đó các thông tin này không chiếm nhiều tài nguyên Người dùng dễ hiểu và dễ sử dụng Chi phí để thực hiện giải pháp này là rẻ so với các giải pháp khác Nó không phụ thuộc vào các thiết bị phần cứng mà chỉ dựa trên phần mềm Giải pháp này có khả năng làm việc trên mọi hệ điều hành Do đó, việc thực hiện giải pháp này khá dễ dàng và không tốn kém.

Giải pháp này có nhược điểm lớn nhất là không có được sự bảo mật cao Vì người dùng thường có tên đăng nhập mà nhiều người dùng có Mặt khác, người dùng thường chọn mật khẩu dễ nhớ hoặc không cẩn thận khi gõ mật khẩu, do vậy dễ bị tấn công Kẻ tấn công có nhiều phương pháp để đạt được mật khẩu như thâm nhập vào hệ thống đọc file mật khẩu, dự đoán mật khẩu, vét cạn các từ trong từ điển để tìm mật khẩu, hoặc có thể lừa người dùng để lộ mật khẩu.

Một số biện pháp để tăng thêm tính bảo mật cho giải pháp này:

Giải pháp đăng nhập một lần (Single sign - on)

1.3.1 Đăng nhập một lần là gì ?

Ngày nay, một người sử dụng có thể sở hữu hay truy cập rất nhiều tài nguyên thông tin khác nhau Vấn đề phức tạp nảy sinh khi mỗi hệ thống quản lý tài nguyên lại cung cấp một cơ chế xác thực người dùng riêng Việc đăng nhập để truy xuất vào tài nguyên của người dùng có thể phát sinh các vấn đề như quên thông tin xác thực do sử dụng nhiều tài khoản và mật khẩu trên các ứng dụng khác nhau hay việc dùng một tài khoản và mật khẩu cho nhiều hệ thống dẫn đến nguy cơ mất an toàn Đăng nhập một lần chính giải pháp để giải quyết các vấn đề trên. Đăng nhập một lần có thể được định nghĩa như là một trài nghiệm người dùng khi chỉ cần đăng nhập một lần và có thể điều hướng truy xuất nhiều ứng dụng liên tục mà không cần phải nhập thông tin cho từngứng dụng Điều này thực sự cần thiết với những tổ chức có nhiều ứng dụng đang hoạt động trên các nền dịch vụ khác nhau Đăng nhập một lần giúp người sử dụng dễ dàng trong việc đăng nhập

- một ứng dụng và truy xuất tất cả các ứng dụng khác, làm giảm nhu cầu người sử dụng phải nhớ rất nhiều thông tin đăng nhập và mật khẩu

Hình 1.5 Mô hình trước và sau khi áp dụng đăng nhập một lần

Ví dụ: Người dùng sử dụng nhiều dịch vụ: Email, forum, web…khi chưa có đăng nhập một lần thì với mỗi dịch vụ ta phải nhập thông tin để xác thực Khi một tổ chức đã thống nhất sử dụng đăng nhập một lần cho hệ thống của họ thì người dùng chỉ phải đăng nhập một lần vào bất kì ứng dụng nào trong hệ thống thì khi dùng các ứng dụng khác người dùng không phảiđăng nhập lại

Với hệ thống có nhiều website và ứng dụng thì việc sử dụng đăng nhập một lần là khá cần thiết nhằm đem lại nhiều thuận tiện cho người dùng và tăng tính năng bảo mật Đăng nhập một lần giúp xác thực tập trung trên một máy chủ duy nhất thông qua giao thức đã được mã hóa Trình duyệt sử dụng HTTP chuyển hướng trình duyệt của người dùng giữa các ứng dụng mà không cần đăng nhập tài khoản và mật khẩu. Đăng nhập một lần chỉ được triển khai sau khi đã xây dựng được hệ thống xác thực và phân quyền Đăng nhập một lần có nhiệm vụ cung cấp cho người dùng

- quyền truy cập nhiều tài nguyên Web, c ứng dụng trong phạm vi cho phép chỉ với cá một lần đăng nhập (xác thực) Về phân quyền (Access Control), có 2 luật (rules) chính:

- Authentication (xác thực): Là quá trình để định danh một người dùng có hợp lệ hay không (Thường thể hiện qua một khung đăng nhập)

- Authorization (uỷ quyền): Là quá trình kiểm chứng một người dùng đã được xác thực có đủ quyền truy cập vào tài nguyên (mà người dùng) yêu cầu hay không Tài nguyên yêu cầu có thể phụ thuộc vào Policy domain (cấp quyền theo domain) hoặc một policy đặc biệt nào đó (ví dụ cấp quyền theo cấp).

1.3.2 Phân loại đăng nhập một lần

Hầu hết các sản phẩm đăng nhập một lần có sẵn trên thị trường có thể được phân thành hai loại dựa trên kiến trúc:

- Dựa trên web (còn gọi là Enterprise SSO hay ESSO).

Trong khuôn khổ của luận văn, học viên chỉ tập trung vào tìm hiểu và phân tích đăng nhập một lần dựa trên web Một SSO dựa trên web được phân loại tiếp theo:

• Đơn miền (Single Domain): ví dụ Khi xác thực thành công vào tên miền: domain.com, người dùng đồng thời được xác thực vào các miền phụ : sub- domain.domain.com tồn tại.

• Đa miền (Multi Domain : ) ví dụ Khi xác thực thành công vào facebook.com, người dùng đồng thời được xác thực vào example.com

• Các ứng dụng và sản phẩm của bên thứ ba (Applications vs Third-Party Products): ví dụ SSO giữa Oracle Access Manager và IBM WebSphere Application Server Ở 2 dạng đầu tiên, SSO thường sử dụng Cookie để nhận diện, máy chủ web (webserver hay webgate) gửi cookie đã được mã hóa cho trình duyệt đã xác thực

- thành công, cookie này sẽ là chìa khóa sử dụng cho các xác thực tới các tài nguyên khác hoặc cho các xác thực có cùng cấp.

Phần Cookie được mã hóa có thể bao gồm các thông tin: session, distinguished name của người dùng đã xác thực thành công, IP của client đã yêu cầu, thời điểm khởi tạo cookie, thời điểm sửa đổi cookie các thành phần không mã hóa của cookie có thể bao gồm: thời gian hết hạn (expired time), domain hoạt động, SSL/ Httponly…

Thuật toán mã hóa được kiến nghị hiện nay là AES, bên cạnh là các thuật toán kém bền vững hơn nhưng thông dụng như MD5-salt, RC4, RC6 vẫn được sử dụng phổ biến trong các mã hóa cookie/ session

Cookie Path được cấu hình để dùng chung cho mọi miền phụ: domain.com (bao gồm dấu ở đầu)

Hình 1.6 Mô hình Single Domain SSO

Sử dụng một miền chính và các miền phụ trợ, người dùng sẽ được xác thực chung nhưng sẽ chỉ truy cập được đến tài nguyên mà các miền ấn định chính sách

- riêng cho từng người dùng, nhóm người dùng cụ thể Nếu người dùng truy cập vào các dữ liệu không được phép thì sẽ diễn ra theo các bước:

• Bước 1: Người dùng sử dụng trình duyệt của mình để truy cập vào một nguồntài nguyên được bảo vệ bởi một chính sách truy cập trong các miền phụ.

• Bước 2: Miền phụ gửi một phản ứng để người dùng trình duyệt để chuyển hướng đến miền chính để xác thực.

• Bước 3: Truy cập miền chính qua thành phần xác thực người dùng,quyền truy cập để kiểm tra và cấp phép.

• Bước 4:Gửi thông tin xác thực và ủy quyền trở lại trình duyệt của người sử dụng, sau khi nhận được thông tin từ các công cụ truy cập, cookie được thiết lập trên trình duyệt của người dùng cho các tên miền chính.

Khi người dùng nhấp vào nút đăng xuất trên một trang web trong miền phụ các máy chủ web trong miền phụ sẽ hủy các cookie đặt cho người sửdụng và chuyển hướng người dùng đến miền chính với các thông hủy cookie người dùng.Các máy chủ web trong tên miền chính hủy các cookiecủa nó lưu cho người sử dụng và người sử dụng thoát khỏi ứng dụng.

Multi Domain SSO cho phép người dùng truy cập vào nhiều domains/hosts sau 1 lần đăng nhập Một ứng dụng xác thực chính sẽ cung cấp các cookie hợp lệ cho mỗi domain Chẳng hạn người dùng truy cập vào gmail.com, khi đó toàn bộ services của Google, như Google.com, Picasa, Blogspot… đều nhận diện tính xác thực cho người dùng đó.

Kết luận chương

Như vậy, trong chương này đã trình bày một cách ngắn gọn và chi tiết về các giải pháp xác thực người dùng cũng như cơ chế đăng nhập một lần Tác giả luận văn đã tập trung đi sâu phân tích các đặc điểm, nguyên lý hoạt động cũng như những vấn đề an toàn đặt ra đối với mô hình đăng nhập một lần dựa trên web trước khi trình bày chi tiết về một mô hình đăng nhập một lầndựa trên web phổ biến đó là OpenID ở chương sau

TỔNG QUAN VỀ OPENID –

OpenID là gì

OpenID là một dịch vụ chia sẻ định danh, một hệ thống đăng nhập một lần không có tính tập trung, cho phép người sử dụng đăng nhập nhiều website khác nhau chỉ bằng một định danh số, tránh việc sử dụng các tài khoản và mật khẩu khác nhau cho mỗi website OpenID là chuẩn mở, miễn phí và phân quyền cho phép người dùng điều khiển được các thông tin cá nhân của mình công khai trên Internet

Một OpenID là dạng liên kết URL, URL này có thể là tên miền của website hoặc URL của nhà cung cấp định danh OpenID Khi đăng nhập với tài khoản OpenID, bạn phải đăng nhập vào Nhà cung cấp dịch vụ định danh để kiểm tra tính hợp lệ của tài khoản OpenID là một phương thức giúp bạn xác thực tài khoản đăng ký tại một nhà cung cấp duy nhất mà bạn tin tưởng và cho phép người dùng thực hiện việc đăng nhập vào các lần sau.

Lịch sử phát triển

Phiên bản đầu tiên của OpenID được phát triển vào tháng 5 năm 2005 bởi Brad Fitzpatrick, tác giả của trang web cộng đồng LiveJournal, làm việc cho công ty Six Apart, ban đầu có tên là Yadis (“Yet another distributed identity system": hệ thống đăng nhập phân tán), và được gọi là OpenID sau khi tên miền www.openid.net được trao cho Six Apart để sử dụng cho dự án.

Tháng 6/2005, các cuộc thảo luận giữa người dùng cuối và nhà phát triển từ công ty phần mềm NetMesh về khả năng hợp tác giữa OpenID và LID (Một giao thức tương tự được phát triển bởi NetMesh) Kết quả của sự hợp tác đó là giao thức Yadis được phát triển và giữ tên gọi mới là OpenID Giao thức OpenID được công bố tháng 24/10/2005, sau khi hội thảo Internet Identity Workshop diễn ra vài ngày

Tháng 12, các nhà phát triển SXIP (Simple Extensible Identity Protocol) và XRI (Một chuẩn nhận dạng mới trên Internet) và bắt đầu tích hợp vào OpenID, thay vì nhận dạng bằng URL ban đầu, OpenID đã phát triển thành một chuẩn nhận dạng đầy đủ cho danh tính người sử dụng Phiên bản OpenID 2.0 xuất hiện.

Ngày 31/1/2007, Symantec công bố hổ trợ OpenID trong trang dịch vụ và sản phẩm Một tuần sau, ngày 6/2/2007, Microsoft kết hợp với JanRain, Sxip, và VeriSign (Những tổ chức tham gia phát triển OpenID) tuyên bố hỗ trợ OpenID và xem xét khả năng tương tác giữa OpenID và MS CardSpace (Một phương thức nhận dạng của Microsoft), cùng với đó là việc xem xét các vấn đề bảo mật cho sự phát triển của OpenID Giữa tháng 2, AOL hổ trợ thử nghiệm OpenID

OpenID sau đó được các đại gia như Yahoo, Google quan tâm, kéo theo đó là các mạng xã hội và các website có lượng người sử dụng lớn cũng bắt đầu hổ trợ OpenID (Trở thành Provider hoặc WebApp hỗ trợ OpenID).

Ngày 26/02/2014, OpenID Connect (thế hệ thứ ba)chính thức được công bố, đó là sự kết hợp giữa định danh, xác thực với OAuth 2.0 làm giao thức cơ sở.

Ứng dụng

– Giúp người dùng dễ dàng đăng ký và đăng nhập, thao tác xử lý nhanh và đơn giản Hoàn toàn phụ thuộc vào việc lựa chọn nhà cung cấp dịch vụ từ phía người dùng tin cậy.

– Khả năng tích hợp, triển khai, cơ chế quản lý bảo mật thông tin người dùng cao. – Giải quyết được bài toán lập trình nhanh (kết nối và chứng thực qua các nhà dịch vụ cho việc xử lý đăng nhập) mà không cần xây dựng chức năng xử lý đăng nhập cục bộ.

– Giúp người dùng dễ dàng sử dụng nhiều ứng dụng khác nhau chỉ với cùng một tài khoản duy nhất.

– Cho phép hệ thống có thể sử dụng các tài khoản đã có trước từ bên ngoài hoặc dùng các tài khoản tạo bên trong hệ thống:

• Chứng thực qua email: Đòi hỏi người dùng sau khi đăng kí tài khoản tại site sẽ phải kích hoạt tài khoản thông qua email

• Chứng thực bằng tay: Tất cả các tài khoản chỉ có thể tạo bởi người quản trị

• Không chứng thực: Người dùng chỉ cần đăng kí tài khoản là xong, không cần xác nhận qua email

Với mô hình đăng nhập một lần, OpenID giúp người dùng và website xác thực quyền truy cập, cho phép người dùng đăng nhập vào những ứng dụng web khác nhau chỉ bằng một định danh số (Digital Indentity) Giúp thay thế các thủ tục đăng ký, xác thực, đăng nhập truyền thống chỉ bằng một bước đăng nhập duy nhất.

Hệ thống quản lý định danh

2.4.1 Các thành phần của một hệ thống quản lý định danh

Các hệ thống quản lý định danh rất đa dạng và phong phú Mỗi hệ thống có thể bao gồmcác thành phần, cách hoạt động và cách giao tiếp khác nhau

Tuy nhiên, trong hệ thống quản lý định danh thông thường gồm có các thành phần sau:

Hình 2.2 Các thành phần chính của hệ thống định danh

- Relying Party (Bên tin cậy): là dịch vụ sử dụng cơ chế định danh để chứng thực

Ví dụ, một số trang web sử dụng cơ chế đăng nhập người dùng như trang zing, trang eplay Hiện nay đã có rất nhiều thành phần Relying Party trên mạng Phần lớn trong số đó đã hỗ trợ định danh bằng hệ thống khác như tài khoản email của Yahoo hay Gmail

Hình 2.3 Ví dụ về thành phần Relying Party

- Identity Provider (IdP – Nhà cung cấp định danh): là thành phần có nhiệm vụ quản lý các thuộc tính định danh của người dùng hệ thống IdP có chức năng truyền những thông tin cần thiết để thực hiện chứng thực đến Relying Party sau khi xác định đúng là người dùng đang sử dụng dịch vụ Hiện nay đã có rất nhiều hệ thống nổi tiếng đã xây dựng thành phần Identity Provider cho riêng mình dựa trên cơ chế của hệ thống OpenID như Google, Yahoo…

- Identity Selector (IS): là thành phần trung gian của hệ thống, là cầu nối giữa người dùng, Relying Party, Identity Provider Mọi hoạt động của thành phần này được điều khiển trực tiếp bởi người dùng.

2.4.2 Quy trình hoạt động chính của hệ thống quản lý định danh

Hình 2.4 Quy trình hoạt động chính của hệ thống quản lý định danh

Quy trình của một hệ thống quản lý định danh được minh họa trong Hình 2.4 bao gồm các bước chính sau để thực hiện quá trình chứng thực:

– Bước 1: Người dùng sẽ cung cấp thông tin về Identity Provider cho thành phần

– Bước 2: Thành phần Identity Selector sẽ tự động giao tiếp với thành phần Relying

Party Sau đó, Identity Selector sẽ truyền các thông tin về Identity Provider do người dùng cung cấp ở bước 1 đến thành phần Relying Party.

– Bước 3: Giữa Replying Party và Identity Provider đã có một sự tin tưởng nhất định Thành phần Relying Party sẽ sử dụng thông tin người dùng cung cấp để kết nối với thành phần Identity Provider (thông qua một kênh truyền an toàn) Sau đó, Relying Party sẽ gửi danh sách tên các thuộc tính cần thiết để thực hiện định danh đến thành phần Identity Provider thông qua kênh truyền an toàn đã được thiết lập

– Bước 4: Thành phần Identity Provider sẽ tạo các thuộc tính cần định danh mà thành phần Relying Party yêu cầu ở bước 3 Sau đó, Identity Provider sẽ ký xác nhận các thông tin mình tạo ra bằng chữ ký của mình Cuối cùng, Identity Provider sẽ truyền thông điệp đã ký về Identity Selector

– Bước 5: Identity Selector sẽ hiện lên các thông tin định danh tương ứng Sau đó, người dùng sẽ kiểm tra các thông tin này và xác nhận có truyền những thuộc tính định danh đến Relying Party hay không

– Bước 6: Các thuộc tính định danh sẽ được truyền đến Relying Party nếu người dùng đã xác nhận ở bước 5.

– Bước 7: Relying Party sẽ kiểm tra những thuộc tính định danh và trả về kết quả cho người dùng.

Phương thức hoạt động của OpenID

2.5.1 Giao tiếp giữa các thành phần trong hệ thống OpenID

OpenID cung cấp cho người dùng URI duy nhất để đăng nhập vào những Relying Party khác nhau URI đóng vai trò là thuộc tính định danh được quản lý tại Identity Provider 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 được thể hiện như hình 2.5

Hình 2.5 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 2.6 Trong trường hợp này, hệ thống phải sử dụng Web Server Location of Identifier URI để có thể xác định được địa chỉ URI thật sự của Identity Provider.

Hình 6 2 URI không phải là địa chỉ ủ c a Identity Provider

OpenID có hai cơ chế giao tiếp là Smart mode và Dumb mode Hai cơ chế này được dựa trên khả năng của Relying Party Trong chế độ Smart mode, Relying Party có 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ện thê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 3 quy trình con sau:

– Quy trình xác định thành phần Identity Provider

– Quy trình gửithuộc tính định danh

– Quy trình kiểm tra thuộc tính định danh

 Quy trình xác định thành phần Identity Provider

Hình 2.7 Quy trình xác định thành phần Identity Provider

Quy trình xác định thành phần Identity Provider gồm 6 bước như hình 2.7:

– 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 URL 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.5: 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.6: 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 để 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 Quy trình xác định địa chỉ Identity Provider dựa trên Yadis được minh họa trong hình 2.8

Hìn 8h 2 Sử dụng Yadis để xác định địa chỉ của Identity Provider

 Quy trình gửithuộc tính định danh

Hình 2.9 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 2.9: – 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 Bướ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ề trình duyệttrang đăng nhập.

– Bước 2.4: Trình duyệtsẽ 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 tên đăng nhậpvà mật khẩu để đăng nhập) Sau đó, người dùng sẽ nhấn nút “đăng nhập”.

– Bước 2.6: Trình duyệt 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: Trình duyệt 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: Trình duyệt sẽ truyền các thông tin định danh của người dùng đến Relying Party

 Quy trình kiểm tra thuộc tính định danh

Hình 2.10 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 2.10:

– 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 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ư 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 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 2 11minh 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.

Hình 2.11 Quy trình kiểm tra thuộc tính định danh ở chế độ Dumb mode

2.5.3 Cơ chế xác thực của OpenID

OpenID sử dụng cơ chế xác thực SASL (Simple Authentication and Security Layer), sử dụng các giao thức lớp ứng dụng như IMAP, POP, XMPP với mục tiêu mô đun hóa và bảo mật lớp

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

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à:

• Người dùng phải chọnthà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

- quản lý của Identity Provider Đây l phương pháp hiệu quả nhằmhạ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 SS được đề nghị cho mọi giao tiếp giữa Relying Party, IdentityL 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

 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

- 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.

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 OpenIDRelying Party (RP) và một OAuthConsumer.

- 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ụ với các mô hình

Hình 2.17 Luồng lai OpenID/OAuth2 với Spark API.

Hình 2.18 Luồng đăng nhập với OpenID/OAuthdành cho Google Apps

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

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

ĐỀ 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

Giới thiệu mô hình

3.1.1 H ệ thống y tế trên cơ sở đám mây

Hình 3.1 Điện toán đám mây với hệ thống y tế

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 tiny 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 ay một h 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 lập tức chia sẻ với bác sĩ về các triệu chứng, giúp việc chẩn đoán trở nên nhanh hơn và hiệu quả hơn Các đồng nghiệp trong ngành cũng dễ dàng chia sẻ thông tin cùng nhau khi có điện toán đám mây

- Bảo mật dữ liệu: Với bất kỳ hình thức công nghệ và lưu trữ nào thì việc sao lưu, lưu trữ và cập nhật là điều không thể thiếu được Ứng dụng điện toán đám mây để thực hiện các công việc trên sẽ giúp cắt giảm thời gian chết hay rủi ro về việc mất dữ liệu trong thời gian xử lý Điều này rất phù hợp với yêu cầu của các bệnh viện và trung tâm y tế về việc đảm bảo hệ thống mạng và hệ thống thông tin luôn hoạt động 24/7.

- Mobile Health: Không giống như hệ thống mạng nội bộ thường được sử dụng trong các bệnh viện, chủ yếu phụ thuộc vào máy tính để bàn, hệ thống điện toán đám mây cung cấp sự thuận tiện và tính di động cho người sử dụng nó Cấu trúc

- điện toán đám mây có thể cho phép cả chuyên gia y tế lẫn bệnh nhân truy cập vào hồ sơ và dữ liệu ngay trên máy tính bảng, điện thoại thông minh mà không cần tới các thiết lập đặc biệt. Điện toán đám mây đang thay đổi cách làm việc hằng ngày của chuyên gia y tế và chăm sóc sức khỏe, giúp họ tiếp cận thông tin một cách nhanh chóng, an toàn và hiệu quả Và quan trọng hơn, điện toán đám mây cho phép các chuyên gia y tế chia sẻ thông tin với đồng nghiệp Điện toán đám mây giúp đẩy nhanh công suất, cắt giảm chi phí và là chất xúc tác thúc đẩy nghiên cứu và triển khai một cách nhanh chóng trên toàn cầu Ứng dụng điện toán đám mây trong hệ thống thông tin y tế chính là xu hướng tất yếu trong việc nâng cao khả năng của ngành ở thời đại thông tin

3.1.2 Vấn đề chia sẻ thông tin giữa các bệnh viện trên cơ sở đám mây

Hình 3.2 Mô hình nhiều bệnh viện cùng tham gia đám mây

Như đã trình bày ở trên, một hệ thống y tế trên cơ sở đám mây sẽ giúp chia sẻ thông tin giữa bác sỹ với bệnh nhân, giữa các bác sỹ với nhau trở nên dễ dàng hơn, quy trình truy cập dịch vụ của hệ thống sẽ được đơn giản hoá, thuận tiện mà không mất đi tính bảo mật Có thể thấy lợi tích mà điện toán đám mây đem lại là rất lớn, tuy nhiên khi áp dụng vào thực tế, câu hỏi đặt ra là cần phải lựa chọn mô hình nào để có thể thực hiện được điều này, phân tích và thiết kế hệ thống ra sao cũng như lựa chọn triển khai phương án hợp lý là điều cần được nghiên cứu và đánh giá Ở đây tác giả luận văn lựa chọn áp dụng vào một bài toán thực tế về quản lý hồ sơ bệnh án của các bệnh viện khi tham gia đám mây và được mô tả như sau:

• Có n bệnh viện trong một hệ thống thông tin y tế nằm trên các vùng địa lý khác nhau Mỗi bệnh viện có một cơ sở dữ liệu riêng để quản lý hồ sơ bệnh án của mình

• Một bệnh nhân X đến khám và điều trị ở bệnh viện A, hồ sơ bệnh án được lưu trên cơ sở dữ liệu của bệnh viện A Với các thông tin cá nhân của mình (họ tên, ngày sinh, số bảo hiểm xã hội…) bệnh nhân X sẽ được ghi danh là một người dùng với hệ thống quản lý định danh theo bnID (định danh bệnh nhân)

Hình 3.3 Cở sở dữ liệu riêng của bệnh viện lưu trữ hồ sơ bệnh án

• Ứng với mỗi bệnh nhân tham gia hệ thống, sẽ lưu trữ các thông tin cá nhân, kèm theo lịch sử thăm khám và triệu trị ở các bệnh viện.

• Bệnh nhân X có sự di chuyển địa lý đến bệnh viện Bđể thăm khám và điều trị Tại bệnh viện B, để phục vụ cho quá trình chuẩn đoán và đánh giá y tế đối với bệnh nhân Các bác sỹ của bệnh viện B sẽ muốn biết thêm thông tin hồ sơ bệnh án của bệnh nhân X tại các bệnh viện khác trong hệ thống

• Bác sỹ của bệnh viện B tiến hành đăng nhậpvào hệ thống quản lý định danh theo bsID (định danh bác sỹ) và truy cập các dịch vụ của bệnh viện khác tham gia hệ thống để tìm kiếm thông tin hồ sơ bệnh án của bệnh nhân X Qua các bước mô tả về hệ thống như trên, tác giả luận văn nhận thấy có nhiều vấn đề cần phải xem xét như sự lựa chọn xây dựng hệ thống quản lý định danh với hai tác nhân (bệnh nhân, bác sỹ), quá trình xác thực người dùng (bác sỹ của bệnh viện B) với hệ thống và kiểm soát truy cập khi bác sỹ của bệnh viện B muốn truy vấn thông tin hồ sơ bệnh án địa phương của bệnh viện A

Tại mỗi bệnh viện, thông thường việc truy xuất vào cơ sở dữ liệu địa phương sẽ thông qua hệ thống xác thực của riêng bệnh viện đó Do đó để giải quyết vấn đề xác thực người dùng với cả hệ thống và kiểm soát truy cập tới dịch vụ (service) của các bệnh viện trên cơ sở đám mây, ta cần phải xây dựng một hệ thống quản lý định danh chung cho cả hệ thống

Chúng ta đã lựa chọn một hệ thống quản lý định danh chung, tuy nhiên có vấn đề phát sinh khi các dịch vụ của các bệnh viện khác nhau sẽ yêu cầu thực hiện tương ứng từng đó số lần đăng nhập để truy xuất dịch vụ.Như vậy cần thiết phải có một cơ chế giúp xác thực chỉ một lần và truy xuất được nhiều dịch vụ Giải pháp đưa ra chính là đăng nhập một lần (single sign- on)

Chúng ta sẽ xem xét vai trò và phạm vi cả hai tác nhân chính tham gia vào hệ thống đó là bệnh nhân và bác sỹ

- Bệnh nhân: Là người đến thăm khám vàđiều trị tại các bệnh viện và cũng là chủ thể được lưu trữ vào hồ sơ bệnh án Tác nhân này có thể được truy cậpvào hệ thống thông tin để tìm hiểu quá trình điều trị tại các bệnh viện cũng như kết quả đánh giá

Giải pháp thực thi

Những phân tích yêu cầu đã được nêu ra, ở phần này tác giả luận văn sẽ tập trung vào việc đánh giá và đề xuất mô hìnhphù hợp cho hệ thống quản lý định danh trên cơ sở đám mây Nội dung lý thuyết từ các chương trước sẽ làm nền tảng cho sự lựa chọn giải pháp cơ sở của mô hình.

Trong các mô hình điện toán đám mây phổ biến, iện toán đám mây cộng đồng đ(Pubic cloud computing) là mô hình chia sẻ cơ sở hạ tầng giữa các tổ chức từ một cộng đồng cụ thể với các mối quan tâm chung (bảo mật, an ninh, kỉ luật, pháp lý, vv) và mô hình này được xem là phù hợp để áp dụng cho hệ thống quản lý định danh trên cơ sở đám mây của chúng ta

Hình 3.5 Điện toán đám mây công cộng

Muốn xây dựng một hệ thống quản lý định danh trên cơ sở đám mây, nơi mà mọi thứ đều được định nghĩa là dịch vụ (service) thì giải pháp định-danh-như-là- một-dịch-vụ (Indentity As A Service - IDaaS) được đề xuất lựa chọn.

IDaaS là một hạ tầng xác thực, có thể coi IDaaS như SSO dành cho đám mây IDaaS cung cấp cơ chế quản lý định danh như là một thực thể số (digital entity) và định danh này có thể được sử dụng trong các giao dịch điện tử (electronic transactions) Trong mô hình IDaaS, SSO sẽ có một máy chủ xác thực quản lý truy cập tới nhiều máy chủ dịch vụ của các bệnh viện

Hình 3 IDaaS SSO.7 Để đảm bảo khả năng truy cập đa dạng vào hệ thống thông tin từ các thiết bị khác nhau (máy tính, di động …) hay từ các vùng địa lý khác nhau chỉ với kết nối internet, cần thiết phải xây dựng một hệ thống có thể hoạt động đa nền tảng Nếu thực hiện giải pháp trên từng nền tảng (platform) riêng biệt thì chi phí sẽ rất lớn cũng như những vấn đề phát sinh như lỗi, bảo mật, khả năng cập nhật… của từng nền tảng Do đó cần có một giải pháp liên nền tảng (cross platform) đáp ứng hoạt động đồng nhất trên nhiều nền tảng Sự bùng nổ của Web 2.0 nơi mà một hệ thống với các dịch vụ đều được xây dựng trên web sẽ đáp ứng được yêu cầu đưa ra

Như vậy các dịch vụ của các bệnh viện sẽ được xây dựng trên web, nơi mà mỗi dịch vụ sẽ được cấp phát một miền (domain), do đó bài toán đăng nhập một lần của hệ thống chính là việc đơn giản hoá quá trình truy cập liên miền của người dùng Người dùng chỉ cần xác thực tại một miền thông qua một nhà cung cấp định danh chung là có thể truy cập thông tin của các miền khác mà không phải nhập lại thông tin Chuẩn mở OpenID dành cho Web SSO là sự lựa chọn phù hợp với yêu cầu Tại đây, các miền của các dịch vụ chính là các bên tin cậy trong hệ thống quản lý định danh OpenID

Phân tích và thiết kế hệ thống thông tin

Như giải pháp thực thi đã nêu ra, hệ thống thông tin của chúng ta sẽ xây dựng trên web, tất cả yêu cầu đăng nhập hay truy xuất thông tin của người dung sẽ được tương tác qua một cổng thông tin (portal site), tại đây hệ thống xử lý sẽ bao gồm các thành phần đăng nhập một lần, xác thực và các thành phần bảo mật liên quan

Hình 3.8 Mô hình khái quát hệ thống

Biểu đồ luồng logic đăng nhập một lần

Hình 3.9 Biểu đồ luồng logic đăng nhập một lần

Hoạt động của các thành phần đăng nhập một lần trong hệ thống được mô tả qua 5 bước như sau:

Hình 3.10 Hoạt động của SSO

1, Người dùng đăng nhập tới máy chủ xác thực sử dụng tên đăng nhập và mật khẩu

2, Máy chủ xác thực sẽ trả lại một ticket cho người dùng.

3, Người dùng gửi ticket này tới máy chủ mạng nội bộ (intranet server) của bệnh viện.

4, Máy chủ mạng nội bộ sẽ gửi ticket này tới máy chủ xác thực.

5, Máy chủ xác thực sẽ gửi các thông tin bảo mật của người dùng lại cho máy chủ mạng nội bộ.

Với mô hình đăng nhập một lần trên, nếu một bác sỹ nghỉ việc chúng ta chỉ cần vô hiệu hóa người dùng tại máy chủ xác thực, khi đó sẽ vô hiệu hóa truy cập của người dùng cho tất cả các hệ thống.

 Luồng thông tin đăng ký người dùng

Người dùng cần đăng ký thông tin với IDaaS qua cơ chế OpenID để lấy OpenID URL làm khoá chính chođịnh danh người dùng trên cơ sở dữ liệucủa từng bệnh viện

Hình 3.11 Đăng ký người dùng

- Với bệnh nhân, quá trình ghi danh sẽ cần: OpenID URL và thông tin cá nhân Sau khi hoàn tất quá trình ghi danh, mỗi bệnh nhân sẽ có một định danh bnID

- Với bác sỹ, quá trình ghi danh sẽ cần OpenID URL, thông tin bác sỹ và bệnh viện công tác Sau khi hoàn tất quá trình ghi danh, mỗi bác sỹ sẽ có một định danh bsID.

 Luồng thông tin xác thực người dùng

Khi người dùng xác thực tới cổng thông tin IDaaS và chứng thực là người dùng hợp lệ, họ sẽ được cấp quyền truy cập tới đám mây dịch vụ của hệ thống thông tin y tế

Hình 3.12 Xác thực người dùng

Với luồng xác thực của người dung như trên, việc áp dụng OpenID có thể thực hiện theo hai cách: a, Phần trước (front-end) xác thực của IDaaS sử dụng OpenID, sau khi thành công người dùng được phép truy xuất một cách hợp lệ các dịch vụ trên đám mây. b, Từ cổng thông tin IDaaS, áp dụng đăng nhập một lần đến các dịch vụ được bảo vệ bởi OpenID.

Biểu đồ tuần tự khi người dùng (bác sỹ) xác thực với SSO OpenID, trong đó bên tin cậy sẽ là dịch vụ của bệnh viện mà bác sỹ muốn truy xuất.

Hình 3.13 Biểu đồ tuần tự OpenID

 Cơ chế gán quyền truy cập

Sau khi quá trình xác thực người dùng với hệ thốnghoàn tất, hệ thống cần có một cơ chế kiểm soát truy cập đối với từng người dùng Có thể áp dụng cấp quyền theo domain (policy domain) hoặc cấp quyền theo cấp (các bác sỹ có chức vụ khác nhau trong một bệnh viện có quyền kiểm soát truy cập khác nhau)

Cơ chế gán quyền khi người dùng (bác sỹ) truy cập domain mới (dịch vụ của bệnh viện khác) có thể được mô tả như sau:

- Trong quá trình ghi danh một bác sỹ, hệ thống có yêu cầu thêm cảthông tin bệnh viện công tác Do đó khi bác sỹ của bệnh viện B xác thực với nhà cung cấp định

- danh thì nhà cung cấp sẽ chuyển thông tin định danh bác sỹ kèm bệnh viện công tác cho bên tin cậy(dịch vụ của bệnh viện A)

- Bệnh viện A xác nhận người dùng (bác sỹ của bệnh viện B) là hợp lệ, nhưng là một bác sỹ ngoài hệ thống bệnh viện Nên chỉ cấp quyền đọc thông tin hồ sơ bệnh án mà không thể thêm, sửa hồ sơ bệnh án như một bác sỹ tại chính bệnh viện A.

Môi trường thử nghiệm

Mô đun đăng nhập một lần được xây dựng nhằm mục đích:

• Minh hoạ cách thức thực hiện đăng nhập một lầnvới OpenID.

• Xác thực người dùng và kiểm soát truy cập với mộtnhà cung cấp định danh được lựa chọn (Google, Yahoo).

• Thực hiện chia sẻ thông tin session giữa hai miền phụ giúp cho quá trình xác thực được thuận tiện.

Do đó mô đunđược thử nghiệm trên môi trường mạng internet sử dụng một máy chủ khởi động ứng dụng web và lắng nghe 127.0.0.1(localhost) cổng 3000 b Kịch bản thử nghiệm:

• Đầu tiên chúng ta khởi động ứng dụng webtrên máy chủ và tạo hai máy chủ ảo là hai miền phụ: sub1.app.localhostvà sub2.app.localhost

• Người dùngsẽ mở trình duyệt web và tiến hành truy cập vào miền phụ sub1.app.localhost Tại đây, ứng dụng websẽ thông báo người dùng này chưa đăng nhập, yêu cầu tiến hành xác thực sử dụng OpenID URL hoặc lựa chọn các nhà cung cấp dịch vụ được khuyến nghị

• Sau khi tiến hành đăng nhập thông qua các nhà cung cấpnày Ứng dụng web thông báo người dùng đã đăng nhập thành côngvà hiển thị các thông tin chi tiết về tài khoản.

• Người dùng tiếp tục truy cập tới miền phụ thứ hai: sub2.app.localhost Lúc này ứng dụng web không yêu cầu người dùng tiến hành truy vấn xác thực với nhà cung cấpnữa do mô đun có thực hiện cơ chế chia sẻ session giữa hai miền phụ

• Ứng dụng web hiển thị trên miền phụ thứ hai thông báo người dùng này đã đăng nhập bằng tài khoản miền phụ thứ nhất và hiển thị thông tin chi tiết ở về tài khoản

Hình 3.14 Kịch bản thử nghiệm.

Hoạt động của mô đun

a Triển khai Ứng dụng webđược triển khai gồm 3 tầng, được mô tả dưới đây:

Hình 3 15 Kiến trúc 3 tầng của ứng dụng web

• Tầng dữliệu: Ứng dụng web sẽ ực hiện giao tiếp vớ th i cơ sở ữ ệ d li u Redis (in memory database- , lưu trữ ạ d ng key-value) để đọc và ghi thông tin session của người dùng khi họtruy xuất vào hệthống.

• Tầng Logic: Tầng này thực hiện cơ ch đăng nhậế p một lần theo chuẩn OpenID s dử ụng NodeJS/Express framework và các thư viện Passport tương tác v i các ớ nhà cung cấp Google, Yahoo…

Hình 3.16 Single sign-on với OpenID

• Tầng trình diễn:Tầng này thực thi giao diện web của hệthống, hiển thị các chức năng đăng nh p / đăng xuậ ất / hiển thị thông tin tài khoản người dùng Giao diện được phát triển v i ớ NodeJS/Express framework và thư viện ejs. b Hoạt động

Kếtquả thử nghiệm của mô đun được trình bày qua các bước:

• Bước 1:Giao diện web khi người dùng truy cập tới miền phụ thứ nhất.

Hình 3.17 Giao diện web khi chưa đăng nhập

• Bước 2:Giao diện web của miền phụ thứ hai cũng thông báo người dùng chưa thực hiện đăng nhập

• Bước 3:Trên miền phụ thứ nhất, người dùng tiến hành xác thực với Google.

• Bước 4: Sau khi điền đúng thông tin id/password.Goolge sẽ yêu cầu xác nhận của người dùng cho phép miền phụsub1.app.localhost truy xuất một số thông tin từ tài khoản Google của người dùng

Hình 3.18 Google hỏi người dùng có đồng ý cho miền phụtruy cập thông tin

• Bước 5: Người dùng đồng ý với việc truy xuất thông tin, Google sẽ chuyển hướng người dùng trở lại miền phụ sub1.app.localhost, lúc nàyhệ thống thông báo bạn đã đăng nhập thành công.

Và thông tin về tài khoản

Hình 3.19 Giao diện web khi đăng nhập

• Bước 6: Người dùng truy cập miền phụ thứ hai: sub2.app.localhost Hệ thống thông báo người dung đã đăng nhập với cùng tài khoản trên miền phụ thứ nhất.

Đánh giá hoạt động của mô đun

Hệ thống đã hoạt động đúng với mục tiêu đề ra.

- Về phía client : Thông tin phiêncủa hai miền phụ được lưu chung trên cùng một cookie theo tên mà người phát triển lựa chọn “myappname.sid”.

Thông tin chi tiết của phiên bao gồm: tên cookie, nội dung, tên miền, đường dẫn, ngày hết hạn…

Hình 3.20 Thông tin phiên được lưu ở cookie trình duyệt

- Về phíaserver: Hệ thống cũng lưu thông tin phiêncủa hai miền phụvào cở sở dữ liệu theo một key duy nhất. với trạng thái chưa đăng nhập, chi tiết phiên như trong hình vẽ và với trạng thái đã đăng nhập, thông tin người dùng được lưu trữ đầy đủ:

Hình 3.21 Thông tin phiên được lưu trên server

Khi thực hiện xoá cookie trên trình duyệt web hoặc xoá bản ghi của session trên server Hệ thống sẽ khởi tạo lại phiên ở cả trình duyệt của client và cơ sở dữ liệu của server về trạng thái chưa đăng nhập Đây là cách thức bảo mật của hệ thống đăng nhập trên web khi thông tin phiên đăng nhập được xoá ở một trong hai nơi client hoặc server thì người dùng được coi như chưa đăng nhập.

Như vậy, chương này đã trình bày về các vấn đề đặt ra với quá trình xác thực và kiểm soát truy cập với một hệ thống thông tin trên cơ sở đám mây, qua đó đề xuất mô hình, giải pháp thực thi và phân tích thiết kế hệ thống thông tin áp dụng cho hệ thống quản lý hồ sơ bệnh án của nhiều bệnh viện khi tham gia đám mây.

Luận văn đã tiến hành thử nghiệm và đánh giá hoạt động của mô đun đăng nhập một lần sử dụng OpenID với cơ chế cho phép chia sẻ phiên giữa các miền phụ trong cùng một hệ thống giúp cho việc xác thực định danh giữa các miền phụđược thuận tiện mà không phải truy vấn lại đăng nhập với nhà cung cấp định danh

Từ thực nghiệm, tác giả luận văn đã hiểu thêm về mô hình hoạt động cũng như ưu điểm của một hệ thống đăng nhập một lần với phạm vi nghiên cứu chính ở đây là chuẩn mởOpenID.

Do tính chất là môi trường thử nghiệm nên việc triển khai của luận văn vẫn còn những mặt hạn chế nhất định như việc sử dụng cơ sở dữ liệu Redis là dạng in- memory cho kết quả hồi đáp nhanh nhưng khi triển khai ngoài thực tế với một lượng lớn truy cập ứng dụng web có thể gây ra hiện tượng tràn bộ nhớ (out-of- memory) với máy chủ Hay như các vấn đề về bảo mật phiênkhi chia sẻ cũng chưa được tìm hiểu sâu sắc

Với những hạn chế trên , hướng phát triển của ứng dụng trong tương lai có thể lựa chọn và thay thế một cơ sở dữ liệu có tính chịu tải tốt (cluster redis - redis 3.x hay sử dụng cơ sở dữ liệu địa phương mysql, postgresql) cũng như cần quan tâm và nghiên cứu sâu hơn các vấn đề bảo mật session Từ đó tạo ra một mô đun ổn định và mạnh mẽ để có thể triển khai toàn bộ hệ thống quản lý định danh trên cơ sở đám mây.

Tiêu đề	Nghiên Cứu Thử Nghiệm Các Cơ Chế Xác Thực Sử Dụng OpenID Và Ứng Dụng
Tác giả	Võ Huy Hưng
Trường học	Trường Đại Học Bách Khoa Hà Nội
Chuyên ngành	Công Nghệ Thông Tin
Thể loại	Luận Văn Thạc Sỹ
Năm xuất bản	2014
Thành phố	Hà Nội

Định dạng
Số trang	99
Dung lượng	9,93 MB