Xác thực và thẩm định trong các hệ thống đăng nhập một lần

Đặ t v ấn đề

Cách mạng công nghiệp 4.0 đang tác động mạnh mẽ đến nhiều ngành nghề tại Việt Nam, đặc biệt là ngành Y tế Hiện nay, các cơ quan quản lý và doanh nghiệp đang nỗ lực tìm kiếm giải pháp công nghệ để phát triển mô hình “Bệnh viện thông minh”.

Bệnh viện thông minh là những cơ sở y tế sở hữu đội ngũ bác sĩ chuyên môn cao, trang thiết bị hiện đại và ứng dụng công nghệ thông tin nhằm tối ưu hóa và tự động hóa các quy trình, hoạt động trong bệnh viện.

Bệnh viện thông minh được hình thành từ nhiều yếu tố quan trọng, bao gồm hạ tầng công nghệ thông tin hiện đại, phần mềm hỗ trợ khám chữa bệnh và quản lý điều hành, cùng với việc số hóa dữ liệu Ngoài ra, việc tích hợp các công nghệ nhận dạng mới như giọng nói, vị trí và sinh trắc học, cũng như ứng dụng trí tuệ nhân tạo (AI) là rất cần thiết để nâng cao hiệu quả quản lý bệnh viện Cuối cùng, việc đảm bảo an toàn thông tin và bảo mật cũng đóng vai trò quan trọng trong việc vận hành bệnh viện thông minh.

Trong thời đại phát triển hiện nay, việc sử dụng nhiều ứng dụng và tài khoản khác nhau trở nên phổ biến, kéo theo nhu cầu ghi nhớ mật khẩu cho từng tài khoản Trước khi có giải pháp SSO (Single Sign-On), người dùng phải nhập tài khoản và mật khẩu cho từng ứng dụng trong cùng một phiên, gây tốn thời gian đáng kể Điều này đặc biệt quan trọng trong môi trường y tế, nơi mỗi phút giây đều quý giá.

Trong môi trường y tế, các thủ tục hành chính thường rườm rà và tốn thời gian, từ việc xếp hàng chờ đến đăng ký khám và kiểm tra giấy tờ Để giảm thiểu thời gian chờ đợi, bệnh nhân có thể đăng ký hẹn khám trước và tìm hiểu các giấy tờ cần chuẩn bị, giúp quy trình khám bệnh trở nên thuận tiện hơn Điều này không chỉ giảm áp lực cho người nhà bệnh nhân mà còn tăng cơ hội chữa trị hiệu quả Bệnh nhân cũng có thể truy cập thông tin y tế chính xác và đáng tin cậy để hỗ trợ cho quá trình khám chữa bệnh của mình.

Bệnh viện thông minh với giải pháp SSO cho phép người dùng dễ dàng hỏi đáp khám bệnh và nhận phản hồi từ các chuyên gia đầu ngành qua một tài khoản duy nhất Trong bối cảnh thông tin không chính thống tràn lan trên mạng xã hội, việc xây dựng một hệ thống thông tin chính xác và uy tín là cần thiết để đảm bảo quyền lợi của mọi người được minh bạch và công bằng.

Phương pháp đề xu ấ t

Hiện nay, có nhiều giải pháp kỹ thuật để xây dựng hệ thống SSO, mỗi giải pháp đều có ưu điểm và nhược điểm riêng Việc lựa chọn một giải pháp phù hợp với đơn vị là rất quan trọng, đặc biệt là trong việc đảm bảo an toàn và bảo mật thông tin.

Mục đích nghiên cứu của luận văn là xây dựng hệ thống SSO dựa trên giao thức OAuth2 tại Bệnh viện, nhằm thực hiện các nhiệm vụ xác thực và ủy quyền, cung cấp quyền truy cập tài nguyên người dùng Giải pháp này kết hợp với mô hình hạ tầng phần cứng để tăng cường tính bảo mật cho hệ thống Người dùng sẽ chỉ cần đăng nhập một lần để tự động truy cập vào tất cả các hệ thống khác trong phiên đăng nhập, tạo nền tảng cơ sở vững chắc cho việc quản lý và bảo vệ thông tin.

Bệnh viện có thể xây dựng nghiệp vụ quản lý tập trung nhằm nâng cao trải nghiệm người dùng với tính thân thiện, dễ sử dụng và bảo mật thông tin Việc tăng cường ứng dụng Công nghệ thông tin (CNTT) trong quản lý hành chính sẽ góp phần hiện đại hóa và hướng tới mục tiêu xây dựng Bệnh viện thông minh Đối tượng nghiên cứu của luận văn bao gồm cơ chế đăng nhập một lần (SSO), giao thức OAuth2 và mô hình trang thiết bị hạ tầng.

Phạm vi nghiên cứu của luận văn tập trung vào hệ thống công nghệ thông tin tại Bệnh viện Y học cổ truyền Trung ương Để đạt được mục đích nghiên cứu, tác giả áp dụng phương pháp nghiên cứu lý thuyết kết hợp với phương pháp triển khai thử nghiệm Việc thực hiện nghiên cứu này yêu cầu tác giả thu thập dữ liệu và thông tin liên quan.

3 tài liệu từ nhiều nguồn thông tin khác nhau bao gồm: Internet, sách báo và những người có kinh nghiệm

Trong các chương tiếp theo của luận văn, tôi sẽ tóm tắt các khái niệm về hệ thống đăng nhập một lần (SSO) và giao thức OAuth2 Dựa trên thực tế tại đơn vị công tác của mình, tôi sẽ đề xuất giải pháp xây dựng hệ thống đăng nhập một lần và mô hình hạ tầng thiết bị phù hợp Cuối cùng, tôi sẽ tổng kết các kết quả đạt được, đưa ra các kết luận mới và đề xuất hướng phát triển tiếp theo.

B ố c ụ c lu ận văn

Bố cục luận văn nội dung chính gồm 4 chương:

Chương 1: Cơ chế đăng nhập một lần (SSO) là một phương thức cho phép người dùng truy cập nhiều ứng dụng với chỉ một lần đăng nhập Bài viết sẽ giới thiệu về SSO, các giao thức xác thực phổ biến như SAML, OAuth, và OpenID Connect, cùng với một số giải pháp triển khai SSO Ngoài ra, sẽ phân tích ưu điểm như tiết kiệm thời gian và nâng cao trải nghiệm người dùng, nhược điểm như rủi ro bảo mật và phụ thuộc vào một điểm xác thực, cũng như những rủi ro tiềm ẩn khi triển khai hệ thống SSO.

Chương 2: Giao thức OAuth2 trình bày những vấn đề quan trọng liên quan đến giao thức này, bao gồm giới thiệu tổng quan, nguyên lý hoạt động cơ bản, các cấp độ ủy quyền khác nhau, cũng như các hoạt động liên quan Bên cạnh đó, chương cũng phân tích ưu điểm và nhược điểm của OAuth2, giúp người đọc hiểu rõ hơn về ứng dụng và hạn chế của giao thức trong việc quản lý quyền truy cập.

Chương 3 trình bày đề xuất giải pháp xây dựng hệ thống SSO sử dụng giao thức OAuth2 tại Bệnh viện YHCTTW Nội dung bao gồm các vấn đề thực tế liên quan đến việc triển khai giải pháp, mục tiêu cụ thể mà giải pháp hướng tới, cùng với những ưu điểm và nhược điểm của nó Bên cạnh đó, bài viết cũng phân tích thiết kế tổng quan hệ thống và các vấn đề liên quan đến thử nghiệm, nhằm đảm bảo tính khả thi và hiệu quả của giải pháp được đề xuất.

Chương 4: Kết luận và đề xuất hướng phát triển tập trung vào việc tổng kết các kết quả đã đạt được, nêu rõ những đóng góp mới và kết luận chính Đồng thời, chương này cũng đưa ra các đề xuất hướng phát triển tiếp theo cho giải pháp nhằm nâng cao hiệu quả và ứng dụng trong thực tiễn.

Phụ lục tài liệu tham khảo

Cơ chế đăng nhậ p m ộ t l ầ n (SSO)

Gi ớ i thi ệ u v ề SSO

1.1.1 Khái niệm Đăng nhập một lần (SSO) là dịch vụ xác thực phiên và người dùng cho phép người dùng cuối nhập một bộ thông tin đăng nhập (có thể gồm tên và mật khẩu) để có quyền truy cập vào nhiều ứng dụng Trong dịch vụ web SSO cơ bản, module agent trên máy chủ ứng dụng sẽ truy xuất thông tin xác thực cho từng người dùng từ máy chủ SSO chuyên dụng, đồng thời xác thực chéo người dùng qua kho lưu trữ người dùng dưới dạng thư mục LDAP [15] Dịch vụ xác thực người dùng cuối cho tất cả các ứng dụng mà người dùng đã được cấp quyền và loại bỏ lời nhắc nhập mật khẩu tiếp theo cho các ứng dụng riêng lẻ trong cùng một phiên [10]

Hình 1: Giới thiệu về SSO [10]

Trước khi triển khai SSO, người dùng phải đối mặt với việc quản lý nhiều tài khoản và mật khẩu khác nhau để truy cập vào các ứng dụng, website và hệ thống khác nhau.

Hệ thống SSO (Single Sign-On) giúp người dùng quản lý tài khoản hiệu quả hơn bằng cách chỉ cần nhớ một tài khoản duy nhất thay vì nhiều tài khoản khác nhau Tuy nhiên, việc tập trung vào một tài khoản cũng tiềm ẩn rủi ro bảo mật cao, vì nếu tài khoản chính bị xâm phạm, thông tin cá nhân của người dùng sẽ bị truy cập trái phép Để giảm thiểu rủi ro này, việc kết hợp nhiều hình thức xác thực khác nhau là rất quan trọng Quá trình đăng nhập thường yêu cầu người dùng cung cấp định danh và thông tin bảo mật như ID và mật khẩu, bao gồm hai bước chính: xác thực và thẩm định (ủy quyền).

Xác thực (Authentication) là quá trình kiểm tra tính hợp lệ của người dùng thông qua các phương thức xác thực của hệ thống Phương pháp phổ biến nhất là sử dụng tên đăng nhập và mật khẩu, bên cạnh đó còn có nhiều phương pháp xác thực khác để đảm bảo an toàn cho hệ thống.

Thẩm định (ủy quyền) là quá trình kiểm tra sau khi người dùng đã được xác thực, nhằm xác định liệu họ có đồng ý cho ứng dụng bên thứ ba truy cập vào tài nguyên và thông tin cá nhân của mình hay không.

1.1.2 Các phương pháp xác thực

Xác thực (Authentication) là quá trình chứng thực danh tính của một cá nhân hoặc đối tượng, nhằm xác định ai đang sử dụng dịch vụ tại thời điểm hiện tại Đơn giản mà nói, xác thực trả lời cho câu hỏi “Bạn là ai?” và có thể được phân loại thành ba loại phương pháp khác nhau dựa trên các đặc điểm của chúng.

Hình 2: Phân loại các phương thức xác thực [12]

Xác thực theo tri thức là phương thức phổ biến nhất hiện nay, sử dụng mật khẩu, chuỗi ký tự, hình ảnh, nhận dạng khuôn mặt và mã số cá nhân (PINs) Trong môi trường Internet không an toàn, xác thực thường dựa vào chứng chỉ số và chữ ký số, được cung cấp bởi hạ tầng khóa công khai (PKI) với cặp khóa mật mã công khai và riêng tư.

Xác thực theo sự sở hữu dựa vào những vật dụng mà người dùng sở hữu, như thẻ từ, nhưng có nhược điểm là thẻ cá nhân có thể bị chiếm đoạt hoặc đánh cắp Để tăng cường bảo mật, phương thức này cần kết hợp thẻ với mã PIN, giúp người dùng đảm bảo an toàn hơn khi sử dụng.

Xác thực sinh trắc học là phương thức xác thực dựa trên các đặc điểm sinh lý và hành vi của người dùng, như vân tay, võng mạc, khuôn mặt và giọng nói Phương thức này mang lại hiệu quả bảo mật cao vì khó bị đánh cắp Tuy nhiên, nó chủ yếu được áp dụng trong các hệ thống quan trọng yêu cầu độ bảo mật cao do chi phí triển khai lớn.

Bảng 1: Xếp hạng các loại xác thực từ 1 (thấp) đến 3 (cao) [12]

Loại xác thực Hiệu quả bảo mật Dễ thực hiện Dễ sữ dụng

Thái độ và sự chấp nhận của người dùng Knowledge- based 1 3 3 3

Mô hình nguyên lý hoạt động của Single sign-on điển hình [4]

Hình 3: Cách thức hoạt động của Single sign-on [4]

SSO hoạt động theo các bước tuần tự như sau:

1 Người dùng lần đầu truy cập domain1

2 Domain1 sẽ chuyển hướng vềtrang login AuthServer để xác thực người dùng

3 AuthServer thực hiện xác thực với thông tin nhận được từ trang đăng nhập

4 AuthServer thực hiện lưu ‘cookie’ với thông tin xác thực của domain1

5 AuthServer gửi ‘token’ và chuyển hướng về domain1

6 Domain1 xác thực với ‘token’ nhận được cho phép người dùng truy cập hệ thống

7 Domain1 thực hiện lưu trữ ‘cookie’ với thông tin ‘token’ xác thực nhận được

8 Người dùng lần đầu truy cập domain2

9 Domain2 chuyển hướng về trang login AuthServer để xác thực người dùng

10 AuthServer nhận thông tin từ ‘cookie’ ởbước 4 để kiểm tra xác thực

11 AuthServer gửi ‘token’ và chuyển hướng về domain2

12 Domain2 xác thực với ‘token’ nhận được cho phép người dùng truy cập hệ thống

13 Domain2 thực hiện lưu trữ ‘cookie’ với thông tin ‘token’ xác thực nhận được.

Các giao th ứ c xác th ự c SSO ph ổ bi ế n

Giao thức xác thực là một loại giao thức mã hóa nhằm chứng thực các đối tượng Hiện nay, có nhiều loại giao thức xác thực khác nhau được sử dụng, như PAP, giúp tăng cường bảo mật và đảm bảo tính toàn vẹn trong quá trình xác thực.

Hiện nay, các giao thức xác thực phổ biến nhất bao gồm OAuth2, Open Id và Saml2, nhờ vào việc tuân theo các tiêu chuẩn chung và mang lại nhiều ưu điểm Bên cạnh đó, giao thức Kerberos cũng đang được sử dụng ngày càng nhiều trong những năm gần đây.

OpenID là một chuẩn mở cho xác thực, được phát triển bởi tổ chức phi lợi nhuận OpenID Foundation Chuẩn này cho phép người dùng được xác thực qua nhiều website khác nhau, sử dụng dịch vụ của bên thứ ba.

Người dùng có thể đăng nhập vào nhiều website khác nhau mà không cần sử dụng tên đăng nhập và mật khẩu riêng cho từng trang Phiên bản mới nhất của OpenID, OpenID Connect, hỗ trợ tính năng này.

 Cách thức hoạt động của OpenID Connect

Hình 4: Cách thức hoạt động của OpenID Connect [16]

Quy trình hoạt động diễn ra theo các bước như sau [16] :

(A) Người dùng sẽ truy cập bên thứ ba và yêu cầu truy cập;

(B) Bên thứ 3 gửi ‘Authentication_request’ cho OpenID provider, mô tả

‘scope’ sẽđược yêu cầu và ‘Response_type’ muốn nhận được;

(C) OpenID provider yêu cầu user xác nhận danh tính sau đó sẽ cho phép bên thứ 3 các quyền trong ‘scope’;

(D) OpenID provider gửi lại bên thứ 3 ‘Authentication_Response’ chứa thông tin muốn ởbước (A) thường sẽ là ‘ID_Token’ và ‘Access_token’;

(E, F) Bên thứ 3 sẽ dùng ‘Access_token’ để trao đổi thông tin mà mình mong muốn

SAML (Security Assertion Markup Language) là một giao thức mở cho phép nhà cung cấp nhận dạng xác thực người dùng và ủy quyền cho họ sử dụng dịch vụ của nhà cung cấp dịch vụ mà không cần tạo tài khoản đăng nhập.

- Identity Provider (IdP): Nhà cung cấp nhận dạng

- Service Provider (SP): Nhà cung cấp dịch vụ

- SP Private Key: Được thống nhất, trao đổi trước giữa SP và IdP bằng cách nào đó

Hình 5: Cách thức hoạt động của SAML [5]

Quy trình hoạt động diễn ra theo các bước như sau [5] :

Bước 1: Người dùng thực hiện 1 yêu cầu đăng nhập tới SP

Bước 2: Phía SP sẽ tạo ra một ‘SAML_Request’ để gửi tới IdP,

‘SAML_Request’ này sẽđược chính ‘SP’ ký điện tử (sign) bằng chữ ký của SP

(chữ ký của SP ở đây chính là khóa bí mật của SP)

Bước 3: Khi IdP nhận được yêu cầu 'SAML_Request' từ SP, cần xác thực chữ ký để đảm bảo rằng nó thực sự thuộc về SP, sử dụng khóa riêng (private key) của SP cho quá trình xác thực.

Bước 4: Vẫn đang ở IdP, sau khi xác thực được chữ ký của SP rồi, IdP sẽ làm những thứ sau:

Để chuyển hướng thông tin người dùng về cho nhà cung cấp dịch vụ (SP), IdP sẽ lấy thông tin từ trình duyệt của người dùng Nếu người dùng chưa đăng nhập, hệ thống sẽ yêu cầu họ đăng nhập trước Sau khi có thông tin, IdP sẽ thực hiện một yêu cầu HTTP POST và gửi kết quả, được gọi là ‘SAML_Response’, đến SP Trước khi gửi, IdP sẽ ký điện tử vào ‘SAML_Response’ bằng khóa bí mật của mình.

IdP không chỉ ký vào 'SAML_Response' mà còn mã hóa các dữ liệu (SAML_Assertions) bên trong 'SAML_Response' bằng khóa công khai của SP.

Bước 5: Khi SP nhận được ‘SAML_Response’, nó sẽ thực hiện những việc sau:

Sử dụng khóa công khai của IdP để xác thực tính chính xác của kết quả gửi từ IdP, điều này là một phần quan trọng mà OAuth và OAuth2 không cung cấp Khóa công khai này có thể được lấy thông qua metadata URL của IdP hoặc được trao đổi trước giữa các bên liên quan.

- Nếu xác thực đúng chữ ký, SP sẽ tiếp tục dùng khóa công khai của chính mình để giải mã ‘SAML_Assertions’ đã được mã hóa từ phía IdP

Lấy thông tin từ 'SAML_Assertions' để đăng nhập người dùng vào hệ thống và thông báo thành công cho họ.

OAuth2 là giao thức chuẩn mở cho việc ủy quyền (Authorization) và là nền tảng của OpenID Connect, cung cấp xác thực (Authentication) trên nền tảng OAuth2 Điều này tạo ra một giải pháp bảo mật toàn diện hơn.

Chủ sở hữu tài nguyên là một thực thể có khả năng cấp quyền truy cập vào tài nguyên được bảo vệ Khi chủ sở hữu tài nguyên là một cá nhân, thuật ngữ này được gọi là người dùng cuối.

- Resource Server: Máy chủ lưu trữ các tài nguyên được bảo vệ, có khả năng chấp nhận và đáp ứng các yêu cầu tài nguyên được bảo vệ bằng

- Client (Application): Một ứng dụng yêu cầu tài nguyên được bảo vệ thay mặt cho resource owner và với sự chứng thực của tài nguyên đó.

- Authorization Server : Máy chủ phát hành ‘Access_token’ cho client sau khi xác thực thành công resource owner và nhận được ủy quyền

Hình 6: Cách thức hoạt động của OAuth2 [1]

Quy trình hoạt động diễn ra theo các bước như sau [1] :

A Client yêu cầu ủy quyền để truy cập vào Resource Server thông qua

B Nếu Resource Owner ủy quyền cho yêu cầu trên, Client sẽ nhận được giấy ủy quyền từ phía Resource Owner (dưới dạng một ‘token’ string nào đó chẳng hạn)

C Client gửi thông tin định danh (ID) của mình kèm theo giấy ủy quyền của Resource Owner tới Authorization Server

D Nếu thông tin định danh được xác thực và giấy ủy quyền hợp lệ, Authorization Server sẽ trả về cho Client ‘Access_token’ Đến đây quá trình ủy quyền hoàn tất

E Để truy cập vào tài nguyên (resource) từ Resource Server và lấy thông tin, Client sẽ phải đưa ra ‘Access_token’ để xác thực

F Nếu ‘Access_token’ hợp lệ, Resource Server sẽ trả về dữ liệu của tài nguyên đã được yêu cầu cho Client

Kerberos [13] là một giao thức mật mã dùng để xác thực trong các mạng máy tính hoạt động trên những đường truyền không an toàn Giao thức Kerberos có

Giao thức này được thiết kế nhằm chống lại việc nghe lén và gửi lại các gói tin cũ, đồng thời đảm bảo tính toàn vẹn của dữ liệu Mục tiêu chính là áp dụng cho mô hình client-server với xác thực hai chiều Giao thức sử dụng mã hóa đối xứng và yêu cầu sự tham gia của một bên thứ ba mà cả hai bên giao dịch đều tin tưởng.

Hình 7: Cách thức hoạt động của Kerberos [13]

Kerberos không xây dựng các giao thức chứng thực phức tạp cho mỗi máy chủ mà hoạt động dựa trên một máy chủ chứng thực tập trung KDC (Key

Distribution Centre) KDC cung cấp vé cho việc chứng thực người dùng và bảo mật truyền thông bởi khoá phiên trong vé gồm 3 pha và 6 bước trao đổi

- Pha 1: Client chứng thực AS (Authentication Server) biết khoá mật của tất cảngười dùng được lưu giữ trên một cơ sở dữ liệu tập trung)

AS_REQ là yêu cầu xác thực ban đầu của người dùng để khởi tạo dịch vụ, và yêu cầu này được gửi trực tiếp đến các thành phần gọi là KDC.

M ộ t s ố s ả n ph ẩ m SSO đã đượ c tri ể n khai b ở i các công ty l ớ n

Bảng 2: Danh sách một số sản phẩm SSO đã được triển khai bởi các công ty lớn theo Wiki [11]

Nền tảng quản lý định danh

Client-side implementation with plugins for various services/protocols

Claims-based system and application federation

Sign-on Broadcom Propriet ary web access management system that enables user authentication and secure Internet SSO (single sign- on), policy-driven authorization, federation of identities (SAML and OIDC)

C, and complete auditing of all access to the web applications it protects

Facebook connect Facebook Propriet ary

Facebook SSO to third parties enabled by Facebook

Propriet ary Yes Cloud-based Identity &

Nền tảng quản lý định danh

Mô tả solution with single sign-on (SSO), Multi Factor Authentication and Active Directory integration

Web and Federated Single Sign-On Solution

The integration of Kerberos and other authentication mechanisms enables seamless single sign-on across all IBM server platforms, including Windows, Linux, PowerLinux, IBM i, i5/OS, OS/400, and AIX, regardless of differing usernames.

Web, enterprise & Federated SSO solution IBM Tivoli Identity Manager provides Identity management platform

Red Hat Open source Yes

Federated SSO (LDAP and Active Directory), standard protocols (OpenID Connect, OAuth 2.0 and SAML 2.0) for Web, clustering

Nền tảng quản lý định danh

Mô tả and single sign on Red Hat Single Sign-On is version of Keycloak for which RedHat provides commercial support

Yes, used in conjunction with OpenD

Access management, entitlements and federation server platform

Identity and Access Management Suite of products from Oracle

SecureLogin NetIQ Propriet ary Enterprise Single-Sign-On

SAML-based open source access control

OpenID-based SSO for Launchpad and Ubuntu services

SAML 2.0, OpenID, OpenID Connect, OAuth 2.0, SCIM, XACML, Passive Federation

Nền tảng quản lý định danh

Security Transmit Propriet ary Yes

SAML 2.0, OpenID, OpenID Connect, OAuth

Software Yes Reference Implementation of

Ideal Identity Management Suite of products from Data

Ưu điểm, nhược điể m và r ủ i ro khi tri ể n khai SSO

Hệ thống SSO (Single Sign-On) là giải pháp lý tưởng cho sự phát triển trong kỷ nguyên công nghiệp 4.0, khi thương mại điện tử đang bùng nổ Trong thời đại mà thời gian được coi là tiền bạc, SSO mang lại sự tiện lợi, linh hoạt và thông minh cho người dùng Nó tạo nền tảng vững chắc cho các tổ chức trong việc xây dựng và quản lý nghiệp vụ một cách tập trung, nâng cao hiệu quả hoạt động.

Hệ thống SSO (Single Sign-On) mang lại lợi ích lớn cho người dùng bằng cách đơn giản hóa việc quản lý tài khoản, cho phép họ ghi nhớ và sử dụng một tài khoản duy nhất thay vì nhiều tài khoản khác nhau Điều này không chỉ nâng cao trải nghiệm người dùng mà còn tăng tính thân thiện và dễ sử dụng Tuy nhiên, việc tập trung vào một tài khoản cũng tiềm ẩn rủi ro về bảo mật, đòi hỏi người dùng cần chú ý hơn trong việc bảo vệ thông tin cá nhân.

- Đối với người quản trị hệ thống:

Người quản trị chỉ cần bảo mật và quản lý thông tin đăng ký của người dùng một lần, giúp giảm dung lượng cơ sở dữ liệu và ngăn ngừa các rủi ro liên quan đến bảo mật.

19 xung đột nảy sinh do phải xử lý mật khẩu của các hệ thống khác nhau, tăng khả năng mở rộng và triển khai các chiến lược bảo mật

Quản trị viên có khả năng dễ dàng thay đổi và cập nhật thông tin bảo mật của người dùng, thay vì phải thực hiện từng thay đổi trên từng hệ thống riêng lẻ mà người dùng có quyền truy cập Điều này đặc biệt hữu ích khi người dùng thay đổi vị trí và cần điều chỉnh các cấp độ bảo mật tương ứng.

Để triển khai một hệ thống SSO hiệu quả và nâng cao tính bảo mật, cần đầu tư đáng kể về nhân lực, nguồn lực và kinh phí.

Do vậy cần có kế hoạch rõ ràng trước và trong quá trình triển khai

Việc tích hợp giải pháp SSO cho nhiều hệ thống con không hề đơn giản, do mỗi hệ thống có thể sử dụng phần cứng và phần mềm khác nhau Do đó, trong quá trình cài đặt, cần phải giải quyết nhiều vấn đề liên quan đến tính tương thích và đồng bộ giữa các hệ thống.

Các kỹ thuật mở được áp dụng cho hệ thống chưa được chuẩn hóa hoặc chưa được cung cấp có thể dẫn đến mâu thuẫn và sự không tương thích với các sản phẩm khác.

Đăng nhập một lần (SSO) mang lại sự tiện lợi cho người dùng, nhưng cũng tiềm ẩn nhiều rủi ro bảo mật Khi kẻ tấn công chiếm đoạt thông tin đăng nhập SSO, họ có thể truy cập vào tất cả các ứng dụng mà người dùng sử dụng, dẫn đến những thiệt hại nghiêm trọng.

Để ngăn chặn truy cập trái phép, việc triển khai SSO cần phải kết hợp với quản trị định danh chặt chẽ và các hình thức xác thực phù hợp nhằm nâng cao tính bảo mật của hệ thống Điều này cũng liên quan đến những nhược điểm của SSO.

Giao th ứ c Oauth2

Gi ớ i thi ệ u v ề OAuth2

OAuth2 là một tiêu chuẩn mở cho phép xác thực và ủy quyền, giúp các ứng dụng bên thứ ba truy cập tài nguyên của người dùng trong một dịch vụ cụ thể.

OAuth2 = Open + Auth (Authentication: xác thực người dùng thông qua việc đăng nhập, Authorization: cấp quyền truy cập vào các Resource).

Nguyên lý ho ạt độ ng

2.2.1 Các đối tượng trong OAuth2

Oauth2 bao gồm 4thành phần chính:

Chủ sở hữu tài nguyên là một thực thể có quyền cấp quyền truy cập vào tài nguyên được bảo vệ Khi chủ sở hữu tài nguyên là cá nhân, thuật ngữ này được gọi là người dùng cuối.

- Resource Server: Máy chủ lưu trữ các tài nguyên được bảo vệ, có khả năng chấp nhận và đáp ứng các yêu cầu tài nguyên được bảo vệ bằng

- Client (Application): Một ứng dụng yêu cầu tài nguyên được bảo vệ thay mặt cho resource owner và với sự chứng thực của tài nguyên đó.

- Authorization Server : Máy chủ phát hành ‘Access_token’ cho client sau khi xác thực thành công resource owner và nhận được ủy quyền

2.2.2 Sơ đồ luồng hoạt động

Sơ đồ luồng hoạt động của OAuth2 mô tả tương tác giữa 4 đối tượng bao gồm các bước sau [3] :

Hình 8: Sơ đồ luồng hoạt động OAuth2 [3]

Sơ đồ luồng hoạt động OAuth2 theo tuần tự sau:

Bước 1: Application yêu cầu ủy quyền để truy cập vào Resource Server thông qua User

Bước 2: Nếu User ủy quyền cho yêu cầu trên, Application sẽ nhận được giấy ủy quyền (Authorization_code) từ phía User

Bước 3: Application gửi thông tin định danh (ID) của mình kèm theo

‘Authorization_code’ của User tới Authorization Server

Step 4: Once the identification information is verified and the 'Authorization_code' is valid, the Authorization Server will return an 'Access_token' to the Application, completing the authorization process.

Bước 5: Để truy cập vào tài nguyên từ Resource Server và lấy thông tin,

Application sẽ phải đưa ra ‘Access_token’ để xác thực

Bước 6: Nếu ‘Access_token’ hợp lệ, Resource Server sẽ trả về dữ liệu của tài nguyên đã được yêu cầu cho Application

2.2.3 Đăng ký thông tin ứng dụng [3]

Trước khi tích hợp OAuth2 từ các dịch vụ như Facebook, Github hay Google vào ứng dụng, bạn cần đăng ký ứng dụng với dịch vụ tương ứng, cung cấp các thông tin quan trọng.

Application name: Tên ứng dụng

Applcation website: Trang web ứng dụng

Chuyển hướng URL, hay còn gọi là Callback URL, là đường dẫn mà ứng dụng sử dụng để nhận kết quả sau khi quá trình ủy quyền hoàn tất, bao gồm các thông tin quan trọng như mã ủy quyền.

Sau khi đăng ký ứng dụng với dịch vụ, ClientID và Client Secret sẽ được tạo ra bởi dịch vụ

Client Id là chuỗi ký tự dùng để nhận diện ứng dụng trong dịch vụ, trong khi Client Secret là mã bí mật giúp xác thực Client ID của ứng dụng.

2.2.5.1 Sử dụng ‘Access_token’ để lấy dữ liệu [3]

Sau khi nhận được 'Access_token', ứng dụng có khả năng truy cập tài nguyên của người dùng thông qua các yêu cầu POST, với giới hạn quyền truy cập cho đến khi mã thông báo hết hạn hoặc bị thu hồi.

Yêu cầu có dạng như sau: https://API_SERVER.DOMAIN/v2/$OBJECT

Nếu mã thông báo truy cập hợp lệ, API sẽ xử lý yêu cầu theo các thông số đã định Ngược lại, nếu mã thông báo đã hết hạn hoặc không hợp lệ, API sẽ trả về lỗi không hợp lệ.

2.2.5.2 Yêu cầu gửi ‘Access_token’ mới [3]

Mỗi ‘Access_token’ thường có thời gian sống nhất định Khi truy cập tài nguyên nếu ‘Access_token’ hết hạn Appplication sẽ nhận được mã lỗi “Invalid

When encountering a 'token' error, the application must send a POST request to the Auth Server to obtain a new 'Access_token' This request is made to the URL: https://OAUTH_SERVER.DOMAIN/oauth/token?grant_type=refresh_token.

&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&refresh_’token’=REFRESH_’TOKEN’

Các c ấ p ủ y quy ề n

Trong sơ đồ luồng hoạt động của OAuth2, ủy quyền (Authorization Grant) cho phép ứng dụng nhận được 'Access_token' Với 'Access_token' này, ứng dụng có quyền truy cập vào tài nguyên của người dùng.

Các dạng ủy quyền phụ thuộc vào cách thức ứng dụng yêu cầu xác thực và dạng ủy quyền được hỗ trợ bởi máy chủủy quyền (Authorization server).

2.3.1 Cấp ủy quyền sử dụng mã ủy quyền (Authorization Code) [3] Đây là hình thức ủy quyền phổ biến nhất hay được sử dụng hiện nay

Hình 9: Sơ đồ hoạt động Authorization Code [3]

 Sơ đồ hoạt động Authorization Codetuần tựnhư sau:

Người dùng truy cập ứng dụng

Application gửi User link đến nơi để bắt đầu quá trình nhận

Authorization_code https://OAUTH_SERVER.DOMAIN/oauth/authorize?response_type=‘token’&cl ient_id=CLIENT_ID&chuyển hướng_uriLBACK_URL&scope=read

2 User ủy quyền cho Application

Khi người dùng truy cập vào liên kết, họ cần nhập thông tin xác thực Sau khi quá trình xác thực hoàn tất, người dùng sẽ được hỏi liệu có cho phép hoặc từ chối ứng dụng truy cập vào thông tin cá nhân của mình hay không.

Khi người dùng cho phép ứng dụng truy cập thông tin cá nhân, máy chủ xác thực sẽ chuyển hướng đến URL đã đăng ký của ứng dụng Tại đây, ứng dụng sẽ lưu trữ mã ủy quyền từ đường dẫn https://APPLICATION.DOMAIN/callback?code=AUTHORIZATION_CODE.

4 Application yêu cầu ‘Access_token’

After receiving the Authorization Code, it is necessary to make a request to the Auth Server to obtain the Access Token The request should be formatted as follows: `https://OAUTH_SERVER.DOMAIN/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=BACK_URL`.

Nếu quá trình ủy quyền (authorization) thành công Auth Server sẽ chuyển hướng người dùng về chuyển hướngURL kèm theo ‘Access_token’ https://APPLICATION.DOMAIN/callback#’token’=‘ACCESS_TOKEN’

Khi người dùng ủy quyền truy cập, ứng dụng sẽ nhận được 'Access_token' để truy cập các tài nguyên của dịch vụ mà người dùng đã cho phép, cho đến khi 'Access_token' hết hạn.

2.3.2 Cấp ủy quyền ngầm định (Implicit) [3]

Loại ủy quyền này thường được áp dụng cho các ứng dụng di động và ứng dụng chạy trên trình duyệt, chẳng hạn như tiện ích mở rộng FireFox Do không thể bảo mật thông tin Authorization_code tại Client, loại ủy quyền này không yêu cầu xác thực ID của ứng dụng và không cần phải trao đổi Authorization_code.

Implicit không hỗ trợ ‘refesh_token’

Hình 10: Sơ đồ hoạt động Implicit [3]

 Sơ đồ hoạt động Implicittuần tựnhư sau:

Tương tự Authorization Code, User được đưa tới một link để yêu cầu

‘Access_token’ từ Auth Server (với response_type là ‘token’) https://OAUTH_SERVER.DOMAIN/authorize?response_type=‘token’&client_i d=CLIENT_ID&chuyển hướng_uriLBACK_URL&scope=read

2 User ủy quyền cho Application

Khi người dùng truy cập vào liên kết, họ cần nhập thông tin xác thực Sau khi quá trình xác thực hoàn tất, người dùng sẽ được hỏi liệu có cho phép hay từ chối ứng dụng truy cập vào thông tin cá nhân của mình hay không.

3 Browser nhận ‘Access_token’ thông qua chuyển hướng URI

Sau khi User cấp phép cho Application Auth Server sẽ chuyển hướng về chuyển hướng URI (đã đăng ký ởbước trước đó) https://APPLICATION.DOMAIN/callback#’token’=‘ACCESS_TOKEN’

4 Browser duy trì ‘Access_token’

Sau khi Browser được chuyển hướng về chuyển hướng URI, nhiệm vụ của broser là duy trì ‘Access_token’ và điều hướng quay trở lại ứng dụng

5 Application trích xuất ‘Access_token’

Sau khi điều hướng, ‘Access_token’ được trích xuất kèm các thông tin khác từ chuyển hướng URI

6 ‘Access_token’ được gửi đến Application

Thông tin ‘Access_token’ trích xuất ở bước 5 được đính kèm khi điều hướng quay trở lại Application

Lúc này quá trình quá trình xác thực, ủy quyền hoàn tất

2.3.3 Cấp ủy quyền bằng password (Password) [3]

Loại ủy quyền này được sử dụng cho những ứng dụng được tin tưởng bởi

To obtain an access token, the user must directly provide their username and password to the application This process is straightforward and efficient, as it involves sending a request to the OAuth server with the specified parameters: `https://OAUTH_SERVER.DOMAIN/token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID`.

2.3.4 Cấp ủy quyền bằng thông tin ứng dụng (Client Credentials) [3]

Loại ủy quyền này cho phép truy cập vào thông tin tài khoản của ứng dụng, giúp lấy hoặc cập nhật thông tin như mô tả và chuyển hướng URI mà không cần sự tham gia của người dùng Để thực hiện, bạn có thể sử dụng đường dẫn: https://OAUTH_SERVER.DOMAIN/’token’?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET.

Ưu điểm và nhược điể m c ủ a OAUTH2

OAuth 2.0 mang đến tính đa dạng và khả năng kết nối với nhiều nền tảng khác nhau, cho phép bạn truy cập dữ liệu người dùng từ ứng dụng khác Nó cung cấp quy trình ủy quyền cho web, ứng dụng máy tính để bàn và thiết bị di động, hoạt động như một ứng dụng web phía máy chủ sử dụng mã ủy quyền mà không yêu cầu tương tác với thông tin đăng nhập của người dùng.

- Tính bảo mật, tính an toàn: OAuth 2.0 là một giao thức dựa trên SSL

SSL (Secure Sockets Layer) đảm bảo tính riêng tư cho dữ liệu giữa máy chủ web và trình duyệt, bảo vệ token truy cập của người dùng OAuth 2.0 dựa trên SSL, giúp đảm bảo các giao thức bảo mật và bảo vệ an toàn cho dữ liệu.

Tính riêng tư của hệ thống cho phép kiểm soát truy cập hạn chế vào dữ liệu người dùng, đồng thời đảm bảo rằng chỉ những người có quyền mới có thể truy cập thông tin khi mã xác thực (authorization token) hết hạn Hệ thống cũng hỗ trợ khả năng chia sẻ dữ liệu một cách an toàn và hiệu quả.

27 liệu cho người dùng mà không phải tiết lộ thông tin cá nhân Nó dễdàng hơn để thực hiện và cung cấp xác thực mạnh mẽhơn.

OAuth2 yêu cầu phải xây dựng cả hai phía server và client, đồng thời việc tách biệt authorization server và resource server cũng làm tăng độ phức tạp trong quá trình phát triển.

Nếu tài khoản trung tâm của bạn bị hack và các trang web yêu thích của bạn kết nối với máy chủ trung tâm đó, hậu quả sẽ nghiêm trọng và ảnh hưởng đến nhiều trang web liên kết chứ không chỉ một.

Đề xu ấ t gi ả i pháp xây d ự ng h ệ th ố ng SSO s ử d ụ ng giao th ứ c

Gi ớ i thi ệ u v ề ứ ng d ụ ng CNTT t ạ i B ệ nh vi ệ n Y H ọ c c ổ truy ề n TW

3.1.1 Giới thiệu chung về Bệnh viện

Bệnh viện Y học cổ truyền Trung ương là bệnh viện đầu ngành về YHCT tại Việt Nam và là trung tâm hợp tác của Tổ chức Y tế thế giới trong lĩnh vực này Với 34 khoa phòng và trung tâm, bệnh viện được chia thành 4 khối: lâm sàng, cận lâm sàng, trung tâm và các phòng ban chức năng, phục vụ cho 500 cán bộ và 630 giường bệnh Bệnh viện cung cấp các dịch vụ lâm sàng đa dạng như Nội, Ngoại, Phụ, Nội Nhi, Châm cứu dưỡng sinh, Lão, Hồi sức cấp cứu, Da liễu, Kiểm soát và Điều trị Ung bướu, cùng các khoa chuyên sâu khác Được trang bị hiện đại, bệnh viện không chỉ phục vụ cho chẩn đoán và điều trị mà còn cho nghiên cứu khoa học, nhằm kế thừa và phát triển y học cổ truyền.

YHCT, kết hợp YHCT với YHHĐ trong điều trị và dự phòng, bệnh viện đã đạt được rất nhiều thành tựu trong phát triển YHCT

3.1.2 Hạ tầng trang thiết bị, ứng dụng CNTT tại Bệnh viện

Bệnh viện hiện có 5 tòa nhà với hệ thống mạng được triển khai, bao gồm khoảng 200 máy tính, trong đó có máy bàn và laptop Khoảng một nửa số máy tính được kết nối Internet, trong khi nửa còn lại chỉ kết nối mạng LAN Hệ thống bao gồm 7 máy chủ phục vụ cho các ứng dụng CNTT, chủ yếu chạy trên hệ điều hành Windows Server 2012 R2 Các máy trạm sử dụng nhiều hệ điều hành khác nhau, chủ yếu là Windows 7 và Windows 10, với một số máy cài Windows XP, và hầu hết đều được trang bị phần mềm diệt virus Kaspersky bản quyền Bên cạnh đó, bệnh viện cũng sử dụng các thiết bị mạng như Core Switch, Switch, Router, và Firewall Fortigate, cùng với nguồn điện dự phòng UPS và 2 đường truyền mạng tốc độ cao.

Gi ả i pháp xây d ự ng h ệ th ố ng SSO s ử d ụ ng giao th ứ c OAuth 2.0

3.2.1 Các thuận lợi và khó khăn tại Bệnh viện

- Bệnh viện đã có nền tảng cơ sở về hạ tầng trang thiết bị, phòng máy chủ trang bị tương đối đầy đủ

- Sự ủng hộ của lãnh đạo Bệnh viện cho việc phát triển ứng dụng CNTT trong quản lý hành chính

- Hằng năm có ngân sách trong việc phát triển ứng dụng CNTT nhưng không nhiều

- Không có nhiều kinh phí cho việc phát triển ứng dụng CNTT tại đơn vị

- Thiếu thốn nhân lực trong việc phát triển, quản lý và duy trì hệ thống CNTT

Hệ thống phòng máy chủ của Bệnh viện hiện chưa có nhân viên chuyên trách, dẫn đến việc nhiều dịch vụ hạ tầng phải thuê bên thứ ba để hỗ trợ cài đặt, bảo trì và nâng cấp hệ thống.

- Hệ thống còn rời rạc, thiếu sự liên kết, tính năng an toàn bảo mật thông tin chưa cao, thỉnh thoảng vẫn bị lỗi hệ thống

3.2.2 Bài toán thực tếđặt ra

 Bài toán th ứ nh ấ t: Xây d ự ng nghi ệ p v ụ qu ả n lý t ậ p trung

Quản lý tập trung nghĩa là mọi vấn đề sẽ được xử lý tại một điểm duy nhất, nơi một cá nhân hoặc tổ chức có trách nhiệm đưa ra quyết định Giải pháp cho vấn đề này là xây dựng một hệ thống độc lập, cụ thể là ‘Auth Server’, nhằm quản lý tất cả các vấn đề liên quan đến tài khoản người dùng trong một hệ sinh thái chung Hệ thống này sẽ tạo điều kiện cho việc nghiên cứu và triển khai nhiều phương án bảo mật khác nhau.

 Bài toán th ứ hai: Nâng cao tính tr ả i nghi ệ m, tính thân thi ệ n, d ễ s ử d ụ ng, tính b ả o m ậ t thông tin cho ngườ i dùng khi s ử d ụ ng h ệ th ố ng các Website Y t ế c ủ a B ệ nh vi ệ n

Bệnh viện hiện đang vận hành hai trang web chính: một trang tin tức nghiên cứu khoa học và một trang phần mềm quản lý khám chữa bệnh (HIS) Bên cạnh đó, bệnh viện cũng đang phát triển thêm nhiều trang web khác như trang mua bán thuốc, trang khám bệnh trực tuyến và trang chăm sóc dinh dưỡng.

Trang tin tức và nghiên cứu khoa học của Bệnh viện sẽ cung cấp các chức năng như đăng tải tin tức y tế, công bố nghiên cứu khoa học, tạo không gian cho hỏi đáp và bình luận, cũng như hỗ trợ đăng ký học và đào tạo về Y học cổ truyền.

Trang phần mềm quản lý khám chữa bệnh (HIS) hiện nay bao gồm các nghiệp vụ chính như xây dựng hồ sơ bệnh án, thanh toán chi phí khám chữa bệnh, lưu trữ hồ sơ để trao đổi với hệ thống HL7 Core, gửi thanh quyết toán hồ sơ bệnh án điện tử lên cổng thanh toán của Bảo hiểm, cùng các loại báo cáo tài chính, dược, vật tư, hóa chất Giải pháp để cải thiện hệ thống là áp dụng SSO theo giao thức OAuth2, cho phép quản lý tài khoản đăng ký tập trung trên một hệ thống duy nhất, được gọi là 'Auth Server' mới.

Người dùng đăng nhập vào hệ thống 'Auth Server' sẽ được tự động đăng nhập vào tất cả các hệ thống liên quan, bao gồm cả hai trang tin tức nghiên cứu khoa học và trang phần mềm quản lý khám chữa bệnh Cụ thể, khi người dùng đăng nhập vào 'Auth Server', họ cũng sẽ tự động truy cập vào trang đăng ký hẹn khám tích hợp trên phần mềm quản lý khám chữa bệnh HIS của Bệnh viện Tuy nhiên, trang backend vẫn hoạt động độc lập và không liên quan đến tài khoản của Auth Server do tính chất riêng tư của hệ thống này.

Bệnh viện đang phát triển một hệ sinh thái các trang Y tế, cho phép người dùng truy cập toàn bộ dịch vụ chỉ với một tài khoản và một lần đăng nhập Hai trang hiện tại sẽ đóng vai trò là nền tảng để xây dựng và thử nghiệm các chức năng của hệ thống SSO cơ bản Điều này mang lại lợi ích lớn cho người dùng, khi họ có thể trải nghiệm toàn bộ nghiệp vụ chỉ với một lần đăng ký duy nhất.

Bệnh viện nhanh chóng, không mất thơi gian cho việc đăng ký mới tài khoản

Vấn đề 2 không cần phải đăng nhập tài khoản với mật khẩu nhiều lần, giảm nguy cơ bị hack tài khoản, tăng sự an toàn thông tin cá nhân

 Bài toán th ứ ba: T ăng cườ ng tính an toàn, tính b ả o m ậ t, tính khôi ph ục, sao lưu khôi phụ c d ữ li ệ u cho h ệ th ố ng

Trong thực tế, luôn xuất hiện những tình huống bất ngờ mà chúng ta không thể dự đoán trước Vì vậy, mỗi quản trị viên hệ thống cần phải chuẩn bị sẵn sàng cho những tình huống này.

Trong thiết kế hệ thống, việc chuẩn bị 31 phương án dự phòng cho các tình huống xấu là rất quan trọng Điều này đảm bảo rằng hệ thống có kế hoạch sao lưu và khôi phục hiệu quả khi gặp sự cố.

Để giảm thiểu rủi ro, việc tăng cường an toàn và bảo mật cho hệ thống là rất quan trọng, phù hợp với quan điểm "Phòng bệnh hơn chữa bệnh" trong Y học Giải pháp cho vấn đề này là nghiên cứu đặc tính và phân tích ưu nhược điểm của các thiết bị phần cứng, đặc biệt là thiết bị Firewall UTM để nâng cao tính an toàn và bảo mật, cùng với thiết bị Tape backup nhằm cải thiện khả năng khôi phục và sao lưu dữ liệu.

 Bài toán th ứ tư: Tối ưu chi phí, thờ i gian, nhân l ự c tri ể n khai

Để triển khai một hệ thống SSO hiệu quả, cần đảm bảo có hạ tầng thiết bị mạnh mẽ, đồng thời đầu tư đáng kể về nhân lực, nguồn lực và kinh phí để phát triển hệ thống phần mềm.

- Việc tích hợp các hệ thống con vào hệ thống SSO không hề đơn giản, chưa có kỹ thuật chuẩn hóa cho các hệ thống khác nhau

Việc xác thực người dùng trở nên phức tạp do nhiều domain chia sẻ chung cơ sở dữ liệu, đòi hỏi sự đầu tư công sức và tài chính để xây dựng cơ chế xác thực hiệu quả Điều này đảm bảo rằng thông tin định danh người dùng được truyền tải an toàn giữa các hệ thống khác nhau.

Bảo mật trong SSO là một vấn đề cốt lõi, đòi hỏi chi phí cao cho việc mua sắm thiết bị bảo mật, xây dựng lớp bảo mật phần mềm và xử lý sự cố Giải pháp tối ưu chi phí hạ tầng là tận dụng tài nguyên hiện có, lựa chọn công nghệ có khả năng mở rộng, mã nguồn mở miễn phí, dễ dàng tích hợp và sử dụng, đồng thời nhận được sự hỗ trợ từ cộng đồng Thời gian triển khai nhanh chóng cũng là một yếu tố quan trọng trong việc giải quyết vấn đề này.

 Dựa trên những thuận lợi và khó khăn và bài toán thực tế đặt ra nêu trên, tôi đề xuất giải pháp như sau:

Để giải quyết hai bài toán chính là xây dựng nghiệp vụ quản lý tập trung và nâng cao trải nghiệm người dùng, cần tập trung vào việc cải thiện tính thân thiện, dễ sử dụng và bảo mật thông tin cho người dùng khi sử dụng hệ thống các website y tế.

Bệnh viện’ tác giả lựa chọn giải pháp:

Xây dựng một hệ thống SSO chuẩn OAUTH2, đặc biệt là Auth Server, với hai chức năng chính: xác thực tài khoản người dùng và thẩm định quyền truy cập Hệ thống này sẽ chịu trách nhiệm cấp phép truy cập vào các tài nguyên của người dùng, đảm bảo an toàn và hiệu quả trong việc quản lý quyền truy cập.

1 nghiệp vụ tích hợp kèm là trang quản lý tin tức nghiên cứu khoa học, bởi tại

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

3.3.1 Đề xuất mô hình hạ tầng thiết bị tại Bệnh viện

Hình 11: Mô hình kiến trúc vật lý hiện tại

The management information system consists of a high-speed local area network connected to the Internet, featuring a management server, a database server, and a backup server Typically, the web-based system includes an application server and a web server The storage system comprises a backup server and a SAN storage system.

Hình 12: Mô hình hạ tầng thiết bị đề xuất

 Hệ thống đề xuất nhằm đảm bảo hiệu năng hoạt động của hệ thống trong các mặt:

- Tính dễ dàng mở rộng hệ thống khi nhu cầu kết nối tăng lên;

- Tính an toàn, bảo mật thông tin;

- Tính đầy đủ, đáp ứng lượng dữ liệu lưu trữ trong nhiều năm

- Máy chủ quản lý (Management Server/Domain Controller)

- Hệ thống máy chủ Application Server, máy chủ Web Server, máy chủ Database Server

Để nâng cao tính sẵn sàng và ổn định của hệ thống, cần bổ sung một máy chủ Auth Server để thực hiện xác thực và ủy quyền Đề xuất cấu hình hệ thống theo cơ chế Real Application Cluster (RAC) hoặc thiết lập cơ chế Standby nhằm đáp ứng nhu cầu lớn và đảm bảo tính sẵn sàng cao Việc này sẽ giúp tăng cường hiệu suất và độ tin cậy cho toàn bộ hệ thống.

- Thiết bị Firewall phần cứng (Fortigate) có chức năng bảo vệ người dùng từ trong nội mạng truy xuất ra và người dùng bên ngoài truy cập VPN vào

- Phần mềm diệt virus Kaspersky bản quyền cài đặt trên các máy chủ và máy trạm

- Bổ sung thêm thiết bị Firewall UTM bao gồm các tính năng (firewall, IPS, antivirus, antispyware, antispam, web filtering và VPN)

 Hệ thống lưu trữvà sao lưu:

- B ổ sung thêm thi ế t b ị Tape s ử d ụng để backup d ữ li ệ u

3.3.2 Kiến trúc hệ thống thông tin

Hình 13: Kiến trúc hệ thống thông tin

Hệ thống được tổ chức theo cấu trúc nhiều tầng, bắt đầu từ tầng dưới cùng với phần truyền thông và phần cứng, tiếp theo là các tầng phần mềm hệ thống và quản trị cơ sở dữ liệu Tiếp đó là hệ thống phần mềm ứng dụng cùng với các trang web, và cuối cùng là tầng giao diện người sử dụng Ngoài ra, các tiêu chuẩn cần tuân thủ và vấn đề an ninh bảo mật được áp dụng xuyên suốt qua tất cả các tầng của hệ thống.

3.3.3 Sơ đồ khối chức năng của hệ thống

Tổng quan hệ thống được chia làm 3 thành phần chính (Auth Server, Website, Web App)

Hình 14: Sơ đồ khối chức năng hệ thống Single sign-on sử dụng OAuth2

- User: Người dùng thao tác với hệ thống

 Kết nối với Auth Server thông qua cấu hình cổng

 Database: Cơ sở dữ liệu của Website

 Kết nối với Auth Server thông qua cấu hình cổng

 Database: Cơ sở dữ liệu của Web App

 Auth Service: Chịu trách nhiệm xác thực, ủy quyền

 Resource Service: Chịu trách nhiệm cấp thông tin tài nguyên của người dùng

 Database: Lưu trữ cơ sở dữ liệu tập trung (User, SSO, trang tin tức)

 New Site Mgnt: Trang quản lý tin tức

- Browser Cookie Storage: Nơi lưu trữ cookie trên trình duyệt

3.3.4 Sơ đồ hoạt động của hệ thống

Hình 15: Sơ đồ hoạt động của hệ thống

SSO hoạt động theo các bước tuần tự như sau:

1 Người dùng (User) lần đầu truy cập Website

2 Website sẽ chuyển hướng về trang login Auth Server để xác thực người dùng

3 Auth Server thực hiện xác thực với thông tin nhận được từ trang đăng nhập

4 Auth Server thực hiện lưu ‘cookie’ với thông tin xác thực của

5 Auth Server gửi ‘token’ và chuyển hướng về Website

6 Website xác thực với ‘token’ nhận được cho phép người dùng truy cập hệ thống

7 Website thực hiện lưu trữ ‘cookie’ với thông tin ‘token’ xác thực nhận được

8 Người dùng lần đầu truy cập Web App

9 Web App chuyển hướng về trang login Auth Server để xác thực người dùng

10 Auth Server nhận thông tin từ ‘cookie’ ởbước 4 để kiểm tra xác thực

11 Auth Server gửi ‘token’ và chuyển hướng về Web App

12 Web App xác thực với ‘token’ nhận được cho phép người dùng truy cập hệ thống

13 Web App thực hiện lưu trữ ‘cookie’ với thông tin ‘token’ xác thực nhận được.

M ụ c tiêu c ủ a gi ả i pháp

- Xây dựng một hệ thống SSO giao thức chuẩn Oauth2 phù hợp

Kết hợp xây dựng mô hình hạ tầng trang thiết bị phần cứng và hệ thống thông tin với phát triển hệ thống SSO, nhằm tạo ra nền tảng cơ sở vững chắc cho việc quản lý tập trung hiệu quả.

Nâng cao trải nghiệm người dùng là ưu tiên hàng đầu, với tính thân thiện và dễ sử dụng được cải thiện đáng kể Đặc biệt, tính bảo mật thông tin và an toàn dữ liệu luôn được đặt lên hàng đầu, đảm bảo rằng người dùng có thể yên tâm khi sử dụng hệ thống Bên cạnh đó, các tính năng khôi phục và sao lưu dữ liệu cũng được chú trọng, giúp người dùng phục hồi thông tin một cách nhanh chóng và hiệu quả.

- Tăng cường ứng dụng CNTT trong quản lý hành chính bệnh viện góp phần hiện đại hóa, tiến tới mục tiêu xây dựng Bệnh viện thông minh

3.5 Ưu điểm và nhược điểm của giải pháp

Tận dụng tối đa tài nguyên hiện có và đề xuất bổ sung ngân sách hợp lý là cần thiết để phát triển ứng dụng CNTT tại đơn vị.

- Kết hợp giữa phần cứng và phần mềm để tạo ra mô hình bảo mật nhiều lớp

Công nghệ PHP Laravel Framework, đặc biệt là Laravel Passport, được cộng đồng ưa chuộng nhờ khả năng tích hợp hệ thống nhanh chóng và tính tiện dụng cao, đồng thời là mã nguồn mở (OpenSource).

- Tối ưu chi phí, nhân lực, thời gian triển khai trong giới hạn ngân sách giới hạn cho phép

- Chưa dẫn chứng được rõ ràng mô hình triển khai hạ tầng thiết bị có thể tăng cường tính năng bảo mật của người dùng và hệ thống

- Việc bảo mật thông tin của người dùng chủ yếu dựa trên hình thức xác thực truyền thống là nhập (username/password) và phương thức gửi và nhận

Token truy cập sử dụng giao thức SSL trong chuẩn Oauth2, giúp bảo vệ thông tin cá nhân Tuy nhiên, nếu thông tin tài khoản như tên đăng nhập và mật khẩu bị đánh cắp, việc bảo mật trở nên vô nghĩa.

Để nâng cao tính bảo mật thông tin người dùng, nên kết hợp xác thực truyền thống (tên đăng nhập/mật khẩu) với mã One Time Password (OTP) được gửi qua điện thoại, nhằm hoàn tất quá trình xác thực người dùng.

Ph ạ m vi th ử nghi ệ m

Trong đề tài luận văn, tôi đề xuất một mô hình thử nghiệm với hệ thống SSO chuẩn Oauth2 ở mức độ cơ bản, bao gồm ba đối tượng thử nghiệm: Oauth2 Server, Website1 và Website2.

- Quá trình thử nghiệm, demo được diễn ra trên môi trường Window, Webserver Xampp cho phù hợp với môi trường làm việc của tác giả.

Th ử nghi ệ m

 Cơ sở dữ liệu : 5.5.5-10.4.10-MariaDB

- Cài đặt Composer trên Win 7:

để cài đặt Phần mềm sẽ tự động thực hiện quá trình cài đặt mọi thứ Mặc dù còn nhiều phương pháp khác, nhưng cách này được xem là dễ dàng và đơn giản nhất.

3.7.2.1 Cài đặt Laravel - Oauth2 Server

- Bước 1: Bật Xampp và khởi động Apache và MySQL

Hình 16: Khởi tạo môi trường Webserver trên máy tính cá nhân

- Bước 2: Cài đặt laravel thông qua Composer: composer global require laravel/installer

- Bước 3: Tạo dự án Laravel ==> Gõ lệnh sau: (trong trường hợp này tác giả tạo dự án tên oauth2) composer create-project prefer-dist laravel/oauth2

- Bước 4: Gen key cho application php artisan key:generate

- Bước 5: Bật trình duyệt web và mớ link sau: http://localhost/oauth2/public

Hình 17: Giao diện mặc định của dự án Laravel

3.7.2.2 Cài đặt Laravel Passport (Oauth2 Server)

- Bước 1: Chuyển đến thư mục Oauth2 chạy lệnh composer composer require laravel/passport

- Bước 2: Tạo cơ sở dữ liệu cho dự án Oauth2

+ Tạo tên cơ sở dữ liệu (trong trường hợp này tác giả tạo cơ sơ dữ liệu tên auth2)

Hình 18: Tạo cơ sở dữ liệu trong PhpMyAdmin (Xampp)

Vào thư mục dự án Laravel tại D:\xampp_v7\htdocs\SSO\oauth2, mở file env và cấu hình lại tên cơ sở dữ liệu mới thay vì mặc định.

DB_PASSWORD- Bước 3: Mở cmd và vào thư mục gốc oauth2 mà thực hiện lệnh sau php artisan make:auth

- Bước 4: Sửa lại code trong file: AppServiceProvider.php Đường dẫn file: oauth2\App\Providers\AppServiceProvider.php

Hình 19: Sửa lại code trong file AppServiceProvider.php

- Bước 5: Thực hiện lệnh php artisan migrate

- Bước 6: Mở file oauth2\bootstrap\cache\service.php sau đó add đoạn code sau vào array providers

- Bước 7: Thêm thông báo ‘Trait Notifiable’ vào trong file \app\User.php

Hình 20: Thêm thông báo ‘Trait Notifiable’ vào trong file User.php

- Bước 8: Thay đổi driver của api tại oauth2\config\auth.php Điều này sẽ giúp ứng dụng sử dụng Passport's TokenGuard xác thực các request API

Hình 21: Thay đổi driver của api trong file auth.php

Step 9: Set up the frontend by enabling the management interface for ClientID and Client Secret using the command `php artisan vendor:publish tag=passport-components` After publishing, it is essential to declare the Vue components in the file located at `resources\js\app.js` to ensure proper functionality of the interface.

Hình 22: Khai báo các Vue component trong file app.js

- Bước 10: Sau khi đăng ký cần biên dịch lại bằng Laravel Mix bằng câu lệnh: npm install npm run dev

Khởi động server bằng câu lệnh: php artisan serve

3.7.2.3 Tich hợp trang tin tức vào Oauth2 Server

- Tạo Controller cho tin tức: Đường dẫn file Oauth2\App\Http\Controllers\AdminNewscontroller.php Php artisan make:controller AdminNewsController

- Quản lý User trên Server Oauth2 Cấu hình trong file routes\Web.php

Hình 23: Quản lý User trên Server Oauth2

- Đăng ký route cho phần tin tức Thêm cấu hình vào file routes\Web.php

Hình 24: Đăng ký route cho phần tin tức

- Các views trong mục tin tức:

+ Oauth2\Resources\views\admin\news\add.blade.php – Dùng để thêm hoặc sửa tin tức trong trang admin

+ Oauth2\Resources\views\admin\news\detail.blade.php – Xem chi tiết của một tin tức trang frontend

+ Oauth2\Resources\views\admin\news\index.blade.php – Quản lý danh sách tin tức trang admin

3.7.2.4 Cài đặt Laravel Client (Website 1, Website 2)

- Bước 1: Tạo dự án Laravel -> Gõ lệnh sau: (trong trường hợp này tác giả tạo dự án tên website1) composer create-project prefer-dist laravel/website1

- Bước 2: Cài đặt thư viện guzzlehttps/guzzle hỗ trợ: composer require guzzlehttps/guzzle php artisan make:auth

- Bước 3: Gen key cho application php artisan key:generate

- Bước 4: Tạo Controller mới trong dự án Website1: Đường dẫn file: Website1\App\Http\Controllers\Oauth2controller.php Php Artisan make:controller Oauth2Controller

- Bước 5: Đăng ký route cho Website1 Thêm cấu hình vào file routes\Web.php

Hình 25: Đăng ký route cho Website1

- Một sốđoạn code xử lý chính (file Oauth2controller.php):

+ Hiển thịcài đặt kết nối Oauth2 Server trên Website:

Hình 26: Hiển thị cài đặt kết nối Oauth2 Server trên Website1

+ Lưu cấu hình kết nối Oauth2 vào cơ sở dữ liệu:

Hình 27: Lưu cấu hình kết nối Oauth2 vào cơ sở dữ liệu

+ Thực hiện đăng nhập tài khoản bằng Server Oauth2

Hình 28: Thực hiện đăng nhập tài khoản bằng Server Oauth2

+ Hàm Callback sau khi login thành công bằng Oauth2

Hình 29: Hàm Callback sau khi login thành công bằng Oauth2

+ Màn hình Welcome: Hiển thị thông tin tài khoản người dùng

Hình 30: Màn hình Welcome - Hiển thị thông tin tài khoản người dùng

- 2 View hiển thị trên Website

+ Resources\views\oauth2_setting.blade.php – Hiển thịcài đặt kết nối Oauth2 Server trên Website và nút đăng nhập (login)

+ Resources\views\welcome.blade.php – Hiển thị thông tin tài khoản người dùng khi đăng nhập thành công

- Bước 6: Tiếp tục tạo project Website2 nhanh chóng (Website2 sẽ là clone ra của Website1 mục đích phục vụ test hệ thống SSO)

+ Copy thêm thư mục chứa project là Website1 và đổi tên thành Website2 + Tạo database cho website2

Hình 31: Tạo database cho website2 + Cấu hình lại file env

Hình 32: Cấu hình lại file env

3.7.2.5 Kiểm tra biến môi trường PHP trên Win 7

Để kiểm tra xem biến môi trường PHP đã được cài đặt hay chưa, bạn cần mở cmd và thực hiện lệnh kiểm tra Nếu kết quả hiển thị như hình dưới đây, điều đó có nghĩa là biến môi trường PHP chưa được cài đặt.

Hinh 33: Kiểm tra biến môi trường PHP

- Bước 2 Thực hiện mở phần cài đặt biến môi trường

Hình 34: Các bước cài đặt biến môi trường PHP

Hình 35: Cài đặt biến môi trường PHP thành công

Bộ source code hệ thống SSO thử nghiệm bao gồm 4 thư mục chứa file sau:

Hình 36: Bộ code thử nghiệm gồm 4 thư mục

- Bước 1: Copy thư mục SSO chứa 4 thư mục con database, oauth2, website1, website2 vào folder xampp/htdocs

Ví dụ: Như trong hình làvào thư mục sau trong trường hợp của tác giả:

- Bước 2: Thư mục Database => Chứa toàn bộ CSDL (database) của hệ thống thử nghiệm.Thực hiện import vào cơ sở dữ liệu ‘mysql’

+ Tạo CSDL dữ liệu auth2 => thực hiện import file database/oauth2.sql

+ Tạo CSDL dữ liệu auth2_website => thực hiện import file database/oauth2_website.sql

+ Tạo CSDL dữ liệu auth2_website2 => thực hiện import file database/oauth2_website2.sql

Hình 37: Sau khi import CSDL thành công

- Bước 3: Thực hiện khởi động Oauth2 Server, Website1, Website 2 trên 3 port 8000, 8001, 8002:

+ Tạo 3 file run.bat (làm nhiệm vụ khởi động Server) trên 3 thư mục Oauth2, Website1, Website2;

Hình 38: File khởi động bat để kích hoạt khởi động Project

+ Chạy 3 file run.bat để khởi động 3 server oauth2, website1, website2 lần lượt trên các port lần lượt 8000, 8001, 8002

Hình 39: Khởi đồng thành công 3 server trên 3 port

- Bước 4: Truy cập đường link để vào Oauth2 Server http://127.0.0.1:8000/

Hình 40: Trang chủ Oauth2 Server + Tiến hành đăng ký và đăng nhập

Hình 41: Đăng ký tài khoản trên Oauth2 Server + Giao diện trang quản trị:

Hình 42: Giao diện trang quản trị + Giao diện trang quản lý tin tức:

Hình 43: Giao diện trang quản lý tin tức

Hình 44: Giao diện chức năng chỉnh sửa tin tức + Trang cài đặt SSO:

Hình 45: Hoàn thành các bước cấu hình cài đặt SSO

==>Xong phần cấu hình trên Oauth2 Server!!!

- Bước 5: Truy cập đường link để vào Website1 http://127.0.0.1:8001/ và Website2 http://127.0.0.1:8002/ để cấu hình Oauth2 Client

Hình 46: Cấu hình Oauth2 Client trên Website1 Tương tự Website 1 ta có:

Hình 47: Cấu hình Oauth2 Client trên Website2

- Bước 6: Thử nghiệm tính năng đăng nhập, đăng xuất

+ Lần đầu tiên User truy cập Website đăng nhập thông qua Oauth2 Server sẽcó thông báo như sau:

Hình 48: Thông báo người dùng có đồng ý ủy quyền hay không?

+ Nếu đồng ý chọn ==> Authorize (Ủy quyền) ==> Màn hình đăng nhập thành công

Hình 49: Màn hình đăng nhập thành công trên Webiste1

+ Nếu không đồng ý ==> Chọn Cancel ==> Màn hình trang chủ

+ Tương tự đối với Website 2, sau lần đầu tiên có thông báo và đã chọn đồng ý

Hình 50: Màn hình đăng nhập thành công trên Webiste2

Qua quá trình đăng nhập lần đầu tiên khi có thông báo ‘Authorize’ và

Khi bạn chọn 'Authorize' cho phép Website truy cập thông tin người dùng trên Oauth2 Server, việc đăng nhập trên Oauth2 Server sẽ tự động đăng nhập trên cả Website1 và Website2 trong cùng một phiên Tương tự, khi bạn đăng xuất tài khoản trên Oauth2 Server, bạn sẽ tự động thoát trên cả Website1 và Website2 Điều này cho thấy hệ thống SSO cơ bản theo chuẩn Oauth2 đã được triển khai thành công.

Bảng 3: Một số kết quảđã thử nghiệm tính năng SSO STT Kịch bản Kết quả thử nghiệm thu được

1 Đăng nhập ở Oauth2 Server Tự động đăng nhập ở Website1 và

2 Đăng xuất ở Oauth2 Server Tự động đăng xuất ở Website1 và

Tự động chuyển hướng về trang đăng nhập của Oauth2 Server và sẽ tương tự kịch bản 1

4 Ấn F5 tại Website1, website 2 khi đăng nhập thành công

Hiển thị trạng thái đăng nhập thành công cùng thông tin người dùng trong phạm vi cho phép truy cập tài nguyên được thiết lập

Kế t lu ận và đề x ất hướ ng phát tri ể n