Nghiên cứu dịch vụ Web để xây dựng hệ thống đăng nhập một lần

Nguyễn Trần Quốc Vinh và Đtg<br /> <br /> Tạp chí KHOA HỌC & CÔNG NGHỆ<br /> <br /> 122(08): 27 - 33<br /> <br /> NGHIÊN CỨU DỊCH VỤ WEB ĐỂ XÂY DỰNG<br /> HỆ THỐNG ĐĂNG NHẬP MỘT LẦN<br /> Nguyễn Trần Quốc Vinh1*, Nguyễn Văn Vương2<br /> 1<br /> <br /> Trường Đại học Sư phạm, Đại học Đà Nẵng<br /> 2Trường Đại học Kinh tế, Đại học Đà Nẵng<br /> <br /> TÓM TẮT<br /> Việc mỗi tổ chức sở hữu và vận hành nhiều website ngày càng phổ biến trên thế giới. Tuy nhiên,<br /> nó thường dẫn đến vấn đề một người dùng cần phải ghi nhớ nhiều tài khoản đăng nhập và mật<br /> khẩu để đăng nhập vào các website khác nhau của cùng một tổ chức do cơ sở dữ liệu tồn tại độc<br /> lập với nhau. Từ đó, vấn đề đăng nhập một lần cho các website trong cùng một tổ chức là một yêu<br /> cầu phổ biến. Tác giả nghiên cứu đã xây dựng giải pháp và xây dựng hệ thống đăng nhập một lần<br /> hoàn toàn mới, cung cấp các dịch vụ xác thực người dùng dựa trên cơ sở dữ liệu người dùng tập<br /> trung. Hệ thống được xây dựng dựa trên việc khai thác tính độc lập đối với nền tảng của dịch vụ<br /> web, khả năng chia sẻ cookie giữa các trình duyệt cũng như ứng dụng web. Nghiên cứu cũng tiến<br /> hành triển khai ứng dụng thử nghiệm trên hệ thống đã được xây dựng.<br /> Từ khóa: Xác thực người dùng; đăng nhập một lần; website; cookie; dịch vụ web.<br /> <br /> ĐẶT VẤN ĐỀ*<br /> Ngày nay, việc sở hữu và vận hành nhiều ứng<br /> dụng web đã trở nên phổ biến, đặc biệt là các<br /> tổ chức lớn. Các ứng dụng hoạt động độc lập<br /> với nhau, có thể được phát triển trên những<br /> nền tảng khác nhau. Người dùng phải thực<br /> hiện đăng ký thông tin và đăng nhập lại khi<br /> chuyển sang sử dụng ứng dụng khác.<br /> Tổ chức càng nhiều ứng dụng, người dùng<br /> càng phải nhớ một lượng lớn tên đăng nhập<br /> và mật khẩu khác nhau. Công việc này chiếm<br /> một khoản thời gian lớn của người dùng, làm<br /> giảm hiệu suất phục vụ của toàn hệ thống.<br /> Các nhà phát triển phải giải quyết hàng loạt<br /> vấn đề liên quan đến quản lý cơ sở dữ liệu<br /> người dùng và bảo mật ở các hệ thống khác<br /> nhau. Để giảm bớt thao tác của người dùng,<br /> tăng tính chuyên nghiệp cho hệ thống, xây<br /> dựng hệ thống đăng nhập một lần (ĐNML,<br /> Single Sign On – SSO) được đánh giá là giải<br /> pháp tốt nhất hiện nay.<br /> Đăng nhập một lần là quá trình xác thực<br /> phiên làm việc của người dùng, cho phép sử<br /> dụng một tên đăng nhập và mật khẩu để truy<br /> cập vào nhiều ứng dụng [1]. Sau khi được xác<br /> thực, người dùng có thể truy cập các ứng<br /> *<br /> <br /> Tel: 0914 780898, Email: ntquocvinh@gmail.com<br /> <br /> dụng khác mà không phải đăng nhập lại, các<br /> quyền được trao và thông tin người dùng<br /> được lưu giữ trong suốt phiên làm việc. Như<br /> vậy, hệ thống ĐNML vừa đảm bảo tính thuận<br /> tiện vừa tăng độ bảo mật khi sử dụng. Hơn<br /> nữa, việc quản lý tài khoản tập trung sẽ làm<br /> cho nhà quản trị chuyên tâm vào phát triển<br /> ứng dụng, công việc bảo mật sẽ do hệ thống<br /> ĐNML đảm nhận. Đối với người dùng, họ chỉ<br /> cần một tài khoản cho tất cả các ứng dụng.<br /> Tuy nhiên, hệ thống ĐNML gặp phải vấn đề<br /> đó là cơ chế bảo mật độc lập với nền của ứng<br /> dụng, hoạt động trên kiến trúc riêng biệt [2].<br /> Điều này đặt ra vấn đề các ứng dụng phải<br /> hiểu được và chấp nhận các thông tin xác<br /> thực do ĐNML cung cấp. Đồng thời phải<br /> kiểm tra được tính chính xác của thông tin<br /> xác thực.<br /> CÁC HỆ THỐNG ĐNML TRÊN THẾ GIỚI<br /> Trên thế giới, có nhiều giải pháp ĐNML với<br /> nhiều phiên bản miễn phí và thương mại. Nổi<br /> bật nhất là hệ thống Central Authentication<br /> Service (CAS) và Oracle Enterprise Single<br /> Sign-on (Oracle ESSO).<br /> Hệ thống CAS do có đặc thù là mã nguồn mở<br /> nên cung cấp khả năng mở rộng cho nhà phát<br /> triển và được cộng đồng không ngừng bổ<br /> sung các tính năng mới. CAS client hỗ trợ các<br /> 27<br /> <br /> Nguyễn Trần Quốc Vinh và Đtg<br /> <br /> Tạp chí KHOA HỌC & CÔNG NGHỆ<br /> <br /> ứng dụng được phát triển bằng nhiều ngôn<br /> ngữ như PHP, Java, .NET. Tuy nhiên, tất cả<br /> ứng dụng phải được phát triển bằng một ngôn<br /> ngữ chung nhất, đây chính là hạn chế lớn của<br /> hệ thống CAS.<br /> Khi người dùng chưa đăng nhập, i) ứng dụng<br /> sẽ yêu cầu CAS xác thực tài khoản do người<br /> dùng cung cấp; ii) sau khi xác thực thành<br /> công, CAS trả về cho trình duyệt các chuỗi ký<br /> tự ngẫu nhiên chứa dữ liệu bảo mật và bắt đầu<br /> bằng tiền tố nhất định gọi là các vé (Ticket).<br /> Mỗi vé có một ý nghĩa riêng, CAS sử dụng vé<br /> ủy quyền (Ticket-Granting Ticket - TGT) làm<br /> cơ sở cho CAS thực hiện ĐNML. Ngoài ra,<br /> CAS sử dụng vé dịch vụ (Service Ticket - ST)<br /> được tạo duy nhất cho mỗi ứng dụng. Vé dịch<br /> vụ được dùng một lần trong một phiên làm việc<br /> của người dùng; iii) ứng dụng gửi vé dịch vụ<br /> cho CAS để nhận về mã người dùng và tự động<br /> tạo phiên làm việc cho người dùng [3].<br /> Trường hợp người dùng truy cập vào ứng<br /> dụng khi đã được CAS xác thực, i) ứng dụng<br /> sẽ gửi vé ủy quyền được lấy từ trình duyệt<br /> cho CAS để xác thực; ii) khi xác thực thành<br /> công, CAS sẽ gửi cho ứng dụng vé dịch vụ;<br /> iii) ứng dụng gửi vé dịch vụ cho CAS để lấy về<br /> thông tin mã người dùng và tự động tạo phiên<br /> làm việc cho người dùng [3]. Tất cả được xử lý<br /> thông qua các liên kết (URL) được trao đổi giữa<br /> các ứng dụng web và máy chủ CAS.<br /> Khác với hệ thống CAS, hệ thống Oracle<br /> ESSO là bản thương mại do Oracle phát triển.<br /> Hệ thống này là một giải pháp trọn gói cho<br /> việc xác thực và quản lý người dùng đối với<br /> tất cả các ứng dụng do Oracle cung cấp. Tuy<br /> nhiên, việc triển khai hệ thống này không hề<br /> đơn giản, tác động lớn đến hệ thống sử dụng<br /> do phải thay đổi phương thức truy cập hệ<br /> thống [4]. Bên cạnh đó, kinh phí để triển khai<br /> hệ thống này là khá lớn, chỉ phù hợp với số ít<br /> các doanh nghiệp sẵn sàng chi một số tiền lớn<br /> để triển khai.<br /> Oracle ESSO có cơ chế xác thực rất phức tạp,<br /> dựa trên các công nghệ quản lý đăng nhập<br /> (Logon Manager), khôi phục mật khẩu<br /> 28<br /> <br /> 122(08): 27 - 33<br /> <br /> (Password Reset), quản lý khởi tạo xác thực<br /> người dùng và tự động tạo “chữ ký tắt” của<br /> người dùng (Kiosk Manager), quản lý xác<br /> thực (Authentication Manager), các công cụ<br /> dành cho quản trị viên (Provisioning<br /> Gateway). Oracle ESSO không chỉ cung cấp<br /> xác thực một lần cho ứng dụng nền web mà<br /> còn cho các loại ứng dụng khác [5].<br /> Tại Việt Nam, nhu cầu về việc triển khai hệ<br /> thống quản lý ĐNML ngày càng trở nên cấp<br /> thiết và đã được triển khai ứng dụng ở nhiều<br /> nơi, chủ yếu là dựa trên các hệ thống có sẵn.<br /> Chẳng hạn, Đại học Đà Nẵng đã xây dựng và<br /> triển khai hệ thống quản lý đăng nhập tập<br /> trung, được công bố trong công trình [6]. Tuy<br /> nhiên, công trình này cũng mới chủ yếu tập<br /> trung giới thiệu tổng quan về ĐNML, giới<br /> thiệu mô hình hệ thống tổng quan và các kết<br /> quả triển khai ứng dụng, chưa chỉ ra được các<br /> công nghệ được ứng dụng cũng như cách thức<br /> ứng dụng các công nghệ, kỹ thuật khác nhau<br /> để xây dựng hệ thống ngoài thông tin về giao<br /> thức LDAP.<br /> Nghiên cứu này chỉ rõ kiến trúc của hệ thống,<br /> cụ thể cách thức ứng dụng công nghệ dịch vụ<br /> web [7, 8] cùng với kỹ thuật chia sẻ cookie<br /> giữa các ứng dụng web để xây dựng hệ thống<br /> ĐNML. Việc phân chia rõ ràng giữa quản lý<br /> xác thực và quản lý phân quyền cũng là yêu<br /> cầu phổ biến, nghiên cứu chỉ quan đến khía<br /> cạnh quản lý xác thực người dùng.<br /> XÂY DỰNG HỆ THỐNG ĐNML<br /> Các công nghệ được sử dụng<br /> Dịch vụ web<br /> Dịch vụ web (web service) là một tập các<br /> chuẩn đặc tả mở rộng khả năng của các chuẩn<br /> có sẵn như XML, URL và HTTP nhằm cung<br /> cấp chuẩn truyền thông giữa các hệ thống với<br /> nhau. Dịch vụ web cung cấp các phương thức<br /> giúp ứng dụng tại máy khách truy cập và sử<br /> dụng các dịch vụ như là một ứng dụng web<br /> thực sự. Về bản chất, dịch vụ web dựa trên<br /> XML và HTTP, trong đó XML làm nhiệm vụ<br /> mã hóa và giải mã dữ liệu và dùng SOAP để<br /> <br /> Nguyễn Trần Quốc Vinh và Đtg<br /> <br /> Tạp chí KHOA HỌC & CÔNG NGHỆ<br /> <br /> truyền tải dữ liệu. Một đặc trưng quan trọng<br /> của dịch vụ web đó là không phụ thuộc vào<br /> nền tảng công nghệ nào, điều này được tác<br /> giả ứng dụng để truyền dữ liệu giữa các ứng<br /> dụng khác nhau.<br /> Trong hệ thống ĐNML được tác giả xây<br /> dựng, dịch vụ web đóng vai trò trung tâm của<br /> việc xử lý đăng nhập và quản lý dữ liệu tài<br /> khoản người dùng. Nhằm đảm bảo các yêu<br /> cầu đặt ra, hệ thống ĐNML cần cung cấp các<br /> dịch vụ cơ bản như: i) Dịch vụ LogOn cung<br /> cấp các phương thức truy cập thông tin tài<br /> khoản người dùng dựa trên tên đăng nhập và<br /> mật khẩu; ii) dịch vụ VerifySessionKey dùng<br /> để xác thực thông tin phiên làm việc của<br /> người dùng được gửi kèm yêu cầu của ứng<br /> dụng; iii) dịch vụ AutoLogin trả về thông tin<br /> người dùng dựa vào thông tin phiên làm việc;<br /> iv) dịch vụ LogOut hỗ trợ đăng xuất người<br /> dùng ở tất cả các ứng dụng; v) dịch vụ<br /> ChangePassword giúp người dùng thay đổi<br /> mật khẩu. Tất nhiên, để có thể sử dụng các<br /> dịch vụ web này, người dùng hoặc trình ứng<br /> dụng triệu gọi chúng phải cung cấp thông tin<br /> xác thực quyền sử dụng.<br /> Cookie và vấn đề truyền dữ liệu giữa các<br /> ứng dụng<br /> Cookie là một phần dữ liệu được lưu trữ trên<br /> trình duyệt của máy khách và tồn tại trong một<br /> khoảng thời gian nhất định do ứng dụng web<br /> quy định. Cookie được trình duyệt tự động gửi<br /> theo mỗi khi truy cập đến máy chủ web.<br /> Cookie của các ứng dụng khác nhau sẽ khác<br /> nhau. Việc lấy thông tin cookie từ một ứng<br /> dụng web khác là rất khó khăn, nhất là khi hai<br /> ứng dụng khác tên miền (domain). Trong<br /> nghiên cứu này, tác giả đã tiến hành tạo<br /> cookie theo cách thay đổi đường dẫn mặc<br /> định để cookie được tạo ra có thể dùng chung<br /> cho các ứng dụng có nhu cầu. Đây chính là cơ<br /> sở quan trọng cho việc xây dựng hệ thống<br /> ĐNML cho nhiều ứng dụng với tên miền<br /> khác nhau.<br /> SSL và kết nối HTTPS<br /> SSL (Secure Sockets Layer) là công nghệ bảo<br /> mật tiêu chuẩn để thiết lập một kết nối đã<br /> <br /> 122(08): 27 - 33<br /> <br /> được mã hóa giữa một máy chủ và một máy<br /> khách [9]. Thông thường, dữ liệu được truyền<br /> qua lại giữa máy khách và máy chủ dưới dạng<br /> không được mã hóa, dữ liệu được truyền tải<br /> giữa hai nút mạng có thể được đọc và hiểu<br /> được bởi một bên thứ ba quan sát ở nút trung<br /> gian. Nếu dữ liệu được truyền qua kênh SSL,<br /> nó sẽ được mã hoá và bên thứ ba nằm ở nút<br /> trung gian sẽ không thể hiểu được nội dung<br /> thông điệp.<br /> HTTPS là giao thức HTTP trên nền SSL/TSL.<br /> Tất cả dịch vụ của hệ thống ĐNML được xây<br /> dựng trong phạm vi nghiên cứu được yêu cầu<br /> sử dụng SSL. Mọi kết nối từ máy khách đến<br /> hệ thống ĐNML đều được thiết lập bằng giao<br /> thức HTTPS. Việc mã hoá và giải mã được<br /> thực hiện theo chứng chỉ số SSL. Nếu chứng<br /> chỉ được cấp bởi một tổ chức có uy tín và<br /> được chấp nhận rộng rãi trên thế giới, chứng<br /> chỉ sẽ được trình duyệt web cũng như các ứng<br /> dụng tự động chấp nhận. Nếu chứng chỉ SSL<br /> được tạo ra bởi các cá nhân hoặc tổ chức chưa<br /> được công nhận rộng rãi trên thế giới, người<br /> dùng phải thực hiện thao tác xác nhận chứng<br /> chỉ số này khi duyệt web. Tuy nhiên, với ứng<br /> dụng web truy cập đến dịch vụ web, cần phải<br /> lập trình xử lý để mặc định nó luôn luôn tự<br /> động xác nhận chứng chỉ SSL của máy chủ<br /> dịch vụ web mà không chờ đợi vào thao tác<br /> thủ công của con người.<br /> Thiết kế hệ thống<br /> Mô hình xác thực người dùng<br /> Hệ thống ĐNML dùng một chuỗi ký tự được<br /> sinh ra ngẫu nhiên và không trùng nhau giữa<br /> các phiên làm việc của người dùng, gọi là<br /> SessionKey, để nhận biết phiên làm việc của<br /> người dùng. Khi người dùng truy cập vào các<br /> trang có yêu cầu xác thực, ứng dụng sẽ gọi<br /> các dịch vụ của hệ thống ĐNML. Trong<br /> trường hợp SessionKey không tồn tại, hoặc<br /> không hợp lệ, ứng dụng sẽ chuyển người<br /> dùng đến trang đăng nhập. Vậy, để được xác<br /> thực, người dùng cần phải có tài khoản và mật<br /> khẩu hợp lệ hoặc là SessionKey hợp lệ. Hình<br /> 1 mô tả quá trình xác thực người dùng.<br /> 29<br /> <br /> Tạp chí KHOA HỌC & CÔNG NGHỆ<br /> <br /> Nguyễn Trần Quốc Vinh và Đtg<br /> <br /> Ứng dụng<br /> domain1.udn.vn<br /> <br /> Browser<br /> <br /> Hệ thống SSO<br /> sso.udn.vn<br /> <br /> 122(08): 27 - 33<br /> Hệ thống Quản lý người dùng<br /> UserManager<br /> <br /> Gửi thông tin đăng nhập<br /> Gọi dịch vụ kiểm tra<br /> thông tin đăng nhập<br /> <br /> Kiểm tra tài khoản với<br /> thông tin đăng nhập<br /> <br /> [tài khoản không tồn tại]<br /> Thông báo<br /> đăng nhập không thành công<br /> [tài khoản tồn tại]<br /> Tạo SessionKey<br /> Lưu SessionKey vào<br /> cơ sở dữ liệu<br /> <br /> Lưu SessionKey vào cookie<br /> của trình duyệt<br /> <br /> Yêu cầu SessionKey<br /> Gửi SessionKey thông qua cookie<br /> <br /> [Tồn tại SessionKey]<br /> Gọi dịch vụ<br /> xác thực SessionKey<br /> <br /> Kiểm tra tài khoản với<br /> giá trị SessionKey<br /> [SessionKey không tồn tại]<br /> <br /> Chuyển đến trang đăng nhập<br /> <br /> Xóa cookie<br /> [SessionKey tồn tại]<br /> Gọi dịch vụ lấy thông tin người dùng<br /> <br /> Chuyển về trang người dùng yêu cầu<br /> <br /> Tạo phiên làm việc cho<br /> người dùng<br /> <br /> Cập nhật thời hạn SessionKey<br /> của phiên làm việc<br /> Tìm kiếm người dùng<br /> với SessionKey<br /> <br /> Hình 1: Sơ đồ mô tả quá trình xác thực người dùng<br /> <br /> Ban đầu, trình duyệt không có bất kỳ cookie<br /> nào dùng cho việc xác thực với dịch vụ<br /> ĐNML. Vì vậy, khi người dùng truy cập vào<br /> trang web có yêu cầu xác thực ở bất kỳ hệ<br /> thống domain1.udn.vn hoặc domain2.udn.vn<br /> đều được yêu cầu nhập thông tin người dùng<br /> tại trang đăng nhập của mỗi hệ thống. Một khi<br /> người dùng đăng nhập thành công vào hệ<br /> thống, cookie chứa thông tin xác thực cho<br /> người dùng sẽ được tạo và được gửi đến trình<br /> duyệt web.<br /> Bấy giờ, nếu người dùng truy cập vào bất cứ<br /> hệ<br /> thống<br /> domain1.udn.vn<br /> hoặc<br /> domain2.udn.vn, trình duyệt sẽ gửi cookie<br /> xác thực đến ứng dụng web. Các ứng dụng<br /> web sẽ nhận cookie và gửi SessionKey đến hệ<br /> thống sso.udn.vn. Nó sẽ kiểm tra và gửi thông<br /> tin người dùng về cho ứng dụng web yêu cầu,<br /> 30<br /> <br /> gia hạn thời gian cho phiên làm việc nếu<br /> SessionKey hợp lệ. Ứng dụng web sẽ cập<br /> nhật và gửi cookie mới cho trình duyệt web<br /> để nó gửi đến máy chủ web trong lần truy cập<br /> sau của người dùng.<br /> Mô hình đăng xuất một lần (Single Sign Out).<br /> Để kết thúc phiên làm việc, người dùng cần<br /> yêu cầu chức năng đăng xuất từ một hệ thống<br /> bất kỳ. Dịch vụ ĐNML sẽ được gọi để hủy<br /> SessionKey và xóa phiên làm việc của người<br /> dùng. Hình 2 mô tả chức năng đăng xuất một<br /> lần. Người dùng khi đăng xuất tại một hệ<br /> thống bất kỳ thì các hệ thống khác cũng tự<br /> động hủy phiên làm việc của người dùng. Lúc<br /> này, mọi thông tin đăng nhập của sẽ bị xóa,<br /> người dùng sẽ phải đăng nhập lại để bắt đầu<br /> phiên làm việc mới.<br /> <br /> Tạp chí KHOA HỌC & CÔNG NGHỆ<br /> <br /> Nguyễn Trần Quốc Vinh và Đtg<br /> <br /> Trình duyệt<br /> Browser<br /> <br /> Ứng dụng<br /> domain1.udn.vn<br /> <br /> Hệ thống SSO<br /> sso.udn.vn<br /> <br /> 122(08): 27 - 33<br /> <br /> Hệ thống Quản lý người dùng<br /> UserManager<br /> <br /> Yêu cầu đăng xuất<br /> Lấy giá trị SessionKey<br /> <br /> Gửi SessionKey<br /> thông qua cookie<br /> Kiểm tra<br /> SessionKey<br /> [Tồn tại SessionKey]<br /> Gửi yêu cầu đăng xuất<br /> <br /> Xóa SessionKey<br /> trên trình duyệt<br /> <br /> Xóa SessionKey trong<br /> CSDL<br /> <br /> Chuyển đến trang đăng nhập<br /> <br /> Hình 2: Mô hình Đăng xuất một lần<br /> <br /> Ứng dụng<br /> asp.udn.vn<br /> <br /> Hệ thống<br /> SSO<br /> sso.udn.vn<br /> <br /> IP: 192.168.20.9<br /> <br /> IP: 192.168.8.30<br /> <br /> IP: 192.168.7.10<br /> Ứng dụng<br /> php1.udn.vn<br /> php2.udn.vn<br /> IP: 192.168.3.3<br /> <br /> Hình 3: Sơ đồ thử nghiệm hệ thống ĐNML<br /> <br /> CÀI ĐẶT THỬ NGHIỆM VÀ ĐÁNH GIÁ<br /> KẾT QUẢ<br /> Hệ thống ĐNML được xây dựng trong phạm<br /> vi nghiên cứu đã được triển khai ứng dụng<br /> thành công tại Trường Đại học Kinh tế - Đại<br /> học Đà Nẵng từ tháng 5/2013 cho các ứng<br /> dụng web trên các máy chủ web riêng biệt, đó<br /> là các website được xây dựng dựa trên nền<br /> tảng Apache/PHP tapchikhkt.due.udn.vn,<br /> hoithao.due.udn.vn và kh.due.udn.vn và tại<br /> Trường Đại học Sư phạm – Đại học Đà Nẵng<br /> từ tháng 11/2013 cho các website<br /> scv.ued.udn.vn,<br /> conf.ued.udn.vn<br /> và<br /> jse.ued.udn.vn. Để kiểm tra khả năng thích<br /> ứng với các nền tảng lập trình khác nhau, các<br /> tác giả đã xây dựng, thử nghiệm kết hợp<br /> <br /> thành công một ứng dụng trên nền tảng .NET.<br /> Sơ đồ các ứng dụng thử nghiệm hệ thống như<br /> hình 3. Ứng dụng .NET gồm hai trang chính:<br /> Trang đăng nhập và trang hiển thị thông tin<br /> người dùng. Kịch bản thử nghiệm được mô tả<br /> như sau: Khi truy cập vào trang hiển thị thông<br /> tin người dùng, nếu chưa đăng nhập thì sẽ<br /> chuyển về trang đăng nhập. Nếu người dùng<br /> đã đăng nhập thì sẽ được chuyển tự động đến<br /> trang thông tin người dùng. Sau đó, người<br /> dùng có thể truy cập ở các ứng dụng còn lại<br /> mà không cần đăng nhập.<br /> Hệ thống ĐNML được xây dựng đã hoàn<br /> chỉnh các chức năng và giải quyết các vấn đề<br /> xác thực người dùng tập trung và ĐNML cho<br /> các ứng dụng. Ngoài ra, hệ thống còn đảm<br /> 31<br /> <br />