Mỗi lần truy nhập một dịch vụ của hệ thống, người dùng phải khai báo thông tin về mật khẩu và tên đăng nhập cho hệ thống xác thực. Do vậy, người dùng phải nhớ rất nhiều cặp tên truy cập và mật khẩu khác nhau và phải đăng nhập nhiều lần. Điều này gây khó khăn cho người dùng và nhà cung cấp dịch
vụ, người quản trị cũng phải đối mặt với một loạt vấn đề như bảo mật, mã hóa, lưu trữ cơ sở dữ liệu.
Trước đây, để giải quyết vấn đề này, người sử dụng bắt buộc phải nhớ các thông tin đăng nhập, hoặc lưu trong các file có mã hóa, hoặc sử dụng một chương trình quản lý tài khoản trên máy tính của họ. Tuy nhiên, người dùng vẫn phải nhớ quá nhiều tên truy cập và mật khẩu, người quản trị luôn nhận được các yêu cầu tạo lại mật khẩu và kích hoạt lại tài khoản người dùng, do họ gặp phải các sự cố về thông tin đăng nhập.
Một giải pháp cho vấn đề trên là sử dụng một kỹ thuật xác thực một lần cho tất cả các tài khoản có yêu cầu bảo mật khác nhau. Giải pháp này vừa đảm bảo tính thuận tiện, vừa tăng độ bảo mật khi sử dụng. Hơn nữa, áp lực trong việc quản lý tài khoản đối với nhà quản trị hệ thống có thể được giảm xuống. Hệ thống SSO có khả năng tích hợp và kết hợp các hệ thống tài khoản khác nhau. Điều này sẽ đem lại lợi ích cả cho người dùng và nhà cung cấp dịch vụ.
Ưu điểm của giải pháp SSO
Đối với người dùng: Hệ thống SSO cung cấp cho người dùng công cụ xác thực đăng nhập một lần. Công cụ này xác thực người dùng đăng nhập vào mọi hệ thống có tích hợp giải pháp SSO, vì vậy, người dùng chỉ cần nhớ một cặp tên truy cập và mật khẩu duy nhất.
Khi cập nhật mật khẩu và tên đăng nhập, người dùng chỉ cần cập nhật một lần cho toàn bộ các hệ thống có yêu cầu xác thực người dùng. Khi đã đăng nhập vào một hệ thống chứa các hệ thống con có tích hợp giải pháp SSO, người dùng có thể dễ dàng truy nhập vào các hệ thống con này mà không cần phải xác thực lại trong một khoảng thời gian nào đó, tùy thuộc vào chính sách quản trị.
Đối với nhà cung cấp dịch vụ, 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, vì vậy có thể
giảm dung lượng cơ sở dữ liệu và tránh được các 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.
Người quản trị có thể thay đổi và cập nhật thông tin được bảo mật của người dùng khi cần thiết, một cách dễ dàng hơn so với việc thay đổi ở từng hệ thống riêng lẻ mà người dùng đó được phép truy cập. Điều này rất hữu ích khi người dùng thay đổi vị trí của mình với các cấp độ bảo mật khác nhau.
Nhược điểm của giải pháp SSO
Việc xử lý một loạt các hệ thống con có tích hợp giải pháp SSO không đơn giản, bởi vì mỗi hệ thống con có thể hoạt động trên các nền phần cứng và phần mềm khác nhau. Vì vậy, khi cài đặt sẽ 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.
Khi đã được xác thực thành công, người dùng có thể truy nhập vào nhiều ứng dụng trong hệ thống. Bởi vậy, nếu không được bảo mật tốt tại các hệ thống con, thì đối tượng tấn công khi tiếp cận vào một ứng dụng có thể tấn công vào toàn bộ hệ thống.
Các kỹ thuật mang tính mở áp dụng với hệ thống hoặc chưa được chuẩn hóa, hoặc chưa được cung cấp, có thể gây mâu thuẫn và không tương thích với các sản phẩm khác.
Thách thức đối với giải pháp SSO là làm việc theo kiến trúc, các cơ chế bảo mật độc lập đối với các nền ứng dụng. Để thuận tiện và đơn giản hơn khi giải quyết nhược điểm của SSO, người ta thường đi theo hướng xây dựng các ứng dụng sử dụng cơ sở hạ tầng bảo mật, xác thực người dùng chung, thông suốt giữa các ứng dụng. Điều này đòi hỏi phải có định dạng chung khi thể hiện các thông tin xác thực hoặc ủy nhiệm, sao cho tất cả các ứng dụng đều có thể hiểu và chấp nhận chúng. Đồng thời, phải đảm bảo được các ủy nhiệm là đúng đắn. Mặc dù có một số nhược điểm, nhưng giải pháp SSO vẫn đang
được triển khai rộng rãi ở nhiều nước trên thế giới, trong nhiều hệ thống thông tin có nhu cầu xác thực và bảo mật. Nó được đánh giá là một trong các giải pháp hiệu quả, tiện dụng và kinh tế khi triển khai trên diện rộng. Các vấn đề nêu trên sẽ được giải quyết trong thời gian tới khi chúng ta tăng cường chuẩn hóa và có các chính sách cụ thể cho vấn đề này.
Các hệ thống xác thực SSO đang được sử dụng rộng rãi là: CAS (Central Authentication Service), WebAuth. RSA Single Sign On Manager, Open Single Sign - On (OpenSSO) hoạt động dựa trên Token, Java Open SSO (JOSSO)[3].
2.5.2.1. Open SSO Enterprise
OpenSSO là một sản phẩm mã nguồn mở của SUN. Nó là một sản phẩm đơn lẻ, kết hợp các tính năng của Sun Java System. Access Manager, Sun Java System Federation Manager và Sun System SAML v2 Java Plugin, kiểm soát truy nhập, đảm bảo an toàn các dịch vụ web và các dịch vụ định danh Web. Khi truy cập vào những tài nguyên được bảo vệ của người dùng, yêu cầu truy cập cần được xác thực và phải có đủ quyền truy cập. Khi một người gửi yêu cầu để truy cập tài nguyên được bảo vệ, policy agent chặn yêu cầu này và kiểm tra. Nếu OpenSSO token được tìm thấy không hợp lệ, policy agent sẽ yêu cầu máy chủ tiến hành xác thực và cấp phép.
Policy agent là ứng dụng web với nhiệm vụ ngăn tất cả yêu cầu đến ứng dụng, để kiểm tra xem người dùng đã xác thực hay chưa.
Hình 2.6: Cơ chế hoạt động của OpenSSO Cơ chế hoạt động của OpenSSO như sau:
- Từ trình duyệt, người dùng kết nối đến ứng dụng web.
- Policy Agent sẽ kiểm tra token có tồn tại trong URL hay không. Nếu token chưa tồn tại thì Policy Agent sẽ chuyển trình duyệt đến OpenSSO máy chủ.
- OpenSSO máy chủ xác thực người dùng thông qua trang đăng nhập. Người dùng nhập tên truy cập/mật khẩu để xác thực.
- OpenSSO (tạo ra session cho người dùng và kích hoạt nó nếu xác thực thành công).
- OpenSSO gửi token cho trình duyệt (trình duyệt sẽ lưu token dưới dạng cookie) và Trình duyệt sẽ gửi token đến cho Agent.
- Policy Agent sẽ lấy thông tin token gửi đến OpenSSO máy chủ để kiểm tra. - OpenSSO sẽ gửi thông tin đăng nhập (tên truy cập, mật khẩu) và thông tin vai trò đến Agent nếu kiểm tra token hợp lệ.
- Policy Agent sẽ quyết định cho phép truy cập ứng dụng hay không và ghi thông tin session trên URL[3].
2.5.2.2. Giải pháp Dịch vụ xác thực trung tâm CAS
CAS (Central Authenticate Service) là một giải pháp SSO mã nguồn mở được phát triển bởi đại học Yale, với các tính năng như sau:
- CAS hỗ trợ nhiều thư viện phía máy khách được viết bởi nhiều ngôn ngữ: PHP, Java, PL/SQL. Nó lấy thông tin SSO thông qua cookie. Cookie này sẽ bị hủy khi người dùng đăng xuất khỏi CAS hoặc đóng trình duyệt. Cookie được sinh ra bởi CAS, còn được gọi là TGC (Ticket Granting Cookie) chứa một ID duy nhất.
- CAS cung cấp nhiều trình quản lý xác thực (authenticate handler) khác nhau. CAS xác thực nhiều loại thông tin người dùng như tên truy cập/mật khẩu, chứng chỉ khóa công khai X509,... để xác thực những thông tin người dùng khác nhau này, CAS sử dụng những trình quản lý xác thực tương ứng.
- CAS cung cấp tính năng “Remember me”. Người phát triển có thể cấu hình tính năng này trong nhiều file cấu hình khác nhau và khi người dùng chọn “Remember me” trên khung đăng nhập, thì thông tin đăng nhập sẽ được ghi nhớ với thời gian được cấu hình. Khi người dùng mở trình duyệt thì CAS sẽ chuyển đến service URL tương ứng mà không cần hiển thị khung đăng nhập.
Chứng thực người dùng với máy chủ CAS: Người dùng nhập tên truy cập/mật khẩu vào khung đăng nhập. Các thông tin này được truyền cho CAS máy chủ thông qua giao thức HTTPS. Xác thực thành công, TGC được sinh ra và thêm vào trình duyệt dưới hình thức là cookie. TGC này sẽ được sử dụng để đăng nhập với tất cả các ứng dụng (Hình 2.7).
Hình 2.7: Người dùng truy cập vào ứng dụng khi đã chứng thực với CAS máy chủ
Trường hợp người dùng truy cập vào ứng dụng khi đã chứng thực với CAS máy chủ:
- Người dùng truy xuất ứng dụng thông qua trình duyệt.
- Ứng dụng lấy TGC từ trình duyệt và chuyển nó cho CAS máy chủ thông qua giao thức HTTPS.
- Nếu TGC này là hợp lệ, CAS máy chủ trả về một Service Ticket (ST) cho trình duyệt, trình duyệt truyền ST vừa nhận cho ứng dụng.
- Ứng dụng sử dụng ST nhận được từ trình duyệt và sau đó chuyển nó cho CAS máy chủ.
- CAS máy chủ sẽ trả về ID của người dùng cho ứng dụng, mục đích là để thông báo với ứng dụng là người dùng này đã được chứng thực bởi CAS máy chủ.
- Ứng dụng đăng nhập cho người dùng và bắt đầu phục vụ người dùng. Trường hợp người dùng truy cập vào ứng dụng mà chưa chứng thực với CAS máy chủ:
- Người dùng truy xuất ứng dụng thông qua trình duyệt. Vì chưa nhận được TGC nên ứng dụng sẽ chuyển hướng người dùng cho CAS máy chủ.
- Người dùng cung cấp tên truy cập/mật khẩu của mình thông qua khung đăng nhập để CAS xác thực. Thông tin được truyền đi thông qua giao thức HTTPS.
- Xác thực thành công, CAS máy chủ sẽ trả về cho trình duyệt đồng thời cả TGC và ST.
- Trình duyệt sẽ giữ lại TGC để sử dụng cho các ứng dụng khác (nếu có) và truyền ST cho ứng dụng nêu trên.
- Ứng dụng chuyển ST cho CAS máy chủ và nhận về ID của người dùng. - Ứng dụng đăng nhập cho người dùng và bắt đầu phục vụ người dùng (Hình 2.8)[3].
Hình 2.8. Người dùng truy cập ứng dụng mà chưa chứng thực với CAS