Chương 1: Giới thiệu thiệu tổng quan về SSO và đưa ra vấn đề cần thiết thử nghiệm SSO đối với các ứng dụng Thuế điện tử Chương 2: Tổng quan về Identity Server 4 Chương 3: Trình bày việc áp dụng thử nghiệm SSO đối với ứng dụng Thuế điện tử Kết luận: Đưa ra được những kết quả đạt được trong luận văn và định hướng phát triển tiếp cho giải pháp.1 Tổng quan về Single sign on 2.1 Khái niệm SSO là một cơ chế xác thực yêu cầu người dùng đăng nhập vào chỉ một lần với một tài khoản và mật khẩu để truy cập vào nhiều ứng dụng trong 1 phiên làm việc [1] Hình 1: Tổng quan về SSO [1] Trước khi có SSO, để truy cập vào ứng dụng, hệ thống người dùng phải nhập tài khoản và mật khẩu. Điều này khiến trải nghiệm người dùng không tốt, tốn thời gian, tăng nguy cơ mất bảo mật… Do đó hệ thống, website có sử dụng SSO sẽ đem lại nhiều thuận tiện cho người dùng, tăng tính bảo mật. Ví dụ: Với các dịch vụ của Google cung cấp: Gmail, Youtube, Drive, Scholar, CHPlay. người dùng phải nhập thông tin tài khoản của dịch vụ để xác thực khi muốn truy cập, sử dụng.
Với SSO người dùng chỉ cần sử dụng 1 tài khoản Google để có thể 4 đăng nhập và sử dụng tất cả các dịch vụ, ứng dụng của google. Điều đó thực sự mang lại trải nghiệm tốt cho người dùng.2 Nguyên lý hoạt động của Single sign-on Mô hình nguyên lý hoạt động của Single sign-on Hình 2: Nguyên lý hoạt động của SSO 1. Người dùng lần đầu truy cập domain1. Domain1 redirect về trang login AuthServer để xác thực người dùng.
AuthServer thực hiện xác thực với thông tin nhận được từ trang login. AuthServer thực hiện save cookie với thông tin xác thực của domain1. AuthServer send token và redirect về domain1. Domain1 xác thực với token nhận được cho phép người dùng truy cập hệ thống.
Domain1 thực hiện lưu trữ cookie với thông tin token xác thực nhận được. Người dùng lần đầu truy cập domain2. Domain2 redirect về trang login AuthServer để xác thực người dùng. AuthServer get thông tin từ cookie ở bước 4 để kiểm tra xác thực.
AuthServer send token và redirect về domain2. 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.3 Kiến trúc SSO Kiến trúc Đăng nhập một lần đơn giản liên quan đến một cơ quan xác thực duy nhất. Trong các kiến trúc SSO đơn giản, chúng ta có thể có một máy chủ xác thực với một cơ sở dữ liệu thông tin đăng nhập duy nhất: Hình 3: Kiến trúc SSO đơn giản trong một môi trường với một xác thực duy nhất Chúng ta cũng có thể có nhiều máy chủ xác thực với nhiều cơ sở dữ liệu thông tin nhân rộng như : 5 Hình 4: Kiến trúc SSO đơn giản trong một môi trường có nhiều xác thực 2.4 Các hình thức triển khai SSO Các hình thức triển khai SSO được phân loại dựa theo các tiêu chí: a) Địa điểm triển khai SSO doanh nghiệp (Intranet/Enterprise SSO): cho phép kết nối nhiều hệ thống trong cùng 1 doanh nghiệp.
SSO doanh nghiệp được thiết kế để giảm số lần người dùng phải đăng nhập tài khoản, mật khẩu vào nhiều ứng dụng. Mỗi máy trạm (máy tính để bàn, máy tính xách tay) sẽ được cung cấp 1 mã (token) để quản lý quá trình xác thực SSO đa vùng miền (Extranet/ Multidomain SSO): cho phép kết nối nhiều hệ thống trong cùng 1 doanh nghiệp và tất cả các ứng dụng của đối tác. Người dùng có thể đăng nhập vào một doanh nghiệp và các doanh nghiệp khác mà không cần phải đăng nhập với nhiều thông tin đăng nhập khác nhau SSO qua Internet(Internet/ Web SSO): dựa trên hệ thống web, cho phép đăng nhập sử dụng đăng nhập một lần qua hệ thống web b) Phương thức triển khai 6 Cấu trúc đơn giản: sử dụng thông tin đăng nhập, phân quyền riêng, đơn giản cho từng người dùng. Được thực hiện trong môi trường mạng nội bộ đồng nhất Cấu trúc phức tạp: sử dụng nhiều đăng nhập, phân quyền với một hoặc nhiều tập thông tin đăng nhập cho từng người dùng c) Loại thông tin đăng nhập Cấu trúc phức tạp với một tập thông tin đăng nhập: có thể được triển khai theo các phương thức sau: + Hệ thống SSO dựa vào mã (token): Trong hệ thống SSO này, người dùng gửi thông tin đăng nhập cho cơ quan xác thực dựa trên mã thông báo, trong đó thông tin đăng nhập đã được kiểm tra với cơ sở dữ liệu thông tin đăng nhập.
Nếu thông tin đăng nhập của người dùng khớp với nhau, thì người dùng sẽ được trả lại bằng mã thông báo. Khi người dùng muốn truy cập vào một máy chủ ứng dụng được quản lý bởi cơ quan xác thực thứ hai, mã thông báo tương tự sẽ được gửi để lấy vé truy cập vào máy chủ ứng dụng. Thành công của quá trình này phụ thuộc vào sự tin tưởng của chính quyền xác thực. + Hệ thống SSO dựa vào mã (token) trên môi trường HTTP: SSO dựa trên Token có thể được triển khai bằng cách sử dụng cookie trong môi trường HTTP.
Cookie là một tập hợp thông tin được cung cấp cho trình duyệt web bởi máy chủ web và được lưu trữ trong máy khách. Cookies được sử dụng để xác thực có thể được mã hóa để giữ bí mật. Sau đó, máy chủ có thể truy xuất cookie và cung cấp dịch vụ tùy chỉnh cho khách hàng. Hệ thống Kerberos cung cấp cơ sở để xây dựng SSO an toàn trong môi trường mạng, tuy nhiên, nó cần cơ sở hạ tầng và cấu hình phía máy khách.
Trong môi trường hỗ trợ HTTP, cookie có thể được sử dụng để xây dựng hệ thống SSO và không cần cài đặt thêm hoặc cấu hình. Sự khác biệt lớn nhất giữa hệ thống Kerberos và hệ thống SSO hỗ trợ Cookies là trước đây sử dụng Cuộc gọi thủ tục từ xa để vận chuyển vé xác thực, trong khi hệ thống sau sử dụng cookie để đóng vai trò mã thông báo. + Hệ thống SSO dựa trên PKI: Trong SSO dựa trên PKI, các máy chủ/ tài nguyên và người dùng xác thực lẫn nhau bằng cách sử dụng các cặp khóa tương ứng của họ. Người dùng có thể xác thực các máy chủ bằng cách thách thức các máy chủ giải mã bất kỳ tin nhắn nào họ gửi được mã hóa bằng khóa chung của 7 máy chủ.
Tương tự, các máy chủ có thể xác thực người dùng bằng cách thách thức anh ta giải mã tin nhắn họ gửi được mã hóa bằng khóa chung của người dùng. Là chủ sở hữu thực sự của khóa riêng chỉ có thể giải mã, xác thực lẫn nhau tức là máy chủ xác thực người dùng và ngược lại xảy ra. Các cơ quan chứng nhận của người dùng và máy chủ có thể khác nhau và nếu chúng khác nhau thì phải có sự tin tưởng giữa các cơ quan chứng nhận. Cấu trúc phức tạp với nhiều tập thông tin đăng nhập: + Đồng bộ thông tin đăng nhập: Nhiều bộ thông tin cần thiết để truy cập vào nhiều hệ thống được che dấu bởi một bộ thông tin xác thực để tạo ảo giác rằng người dùng chỉ cần nhớ một bộ duy nhất.
Phần mềm đồng bộ hóa giúp người dùng thay đổi thông tin đăng nhập trong tất cả các hệ thống và khi lực lượng chính sách, bằng cách tự động chuyển tiếp yêu cầu thay đổi đến tất cả các máy chủ xác thực có liên quan. ví dụ: Pass Go + Bộ nhớ đệm thông tin phía client: Nó cho phép người dùng lưu trữ các thông tin nhạy cảm như thông tin đăng nhập (ví dụ: ID người dùng và mật khẩu) cần thiết cho các trang web hoặc tài nguyên họ truy cập trong mạng. Những thông tin đăng nhập được lưu trữ trong thư mục đặc biệt gọi là hầm. Với thông tin được lưu trữ này, hệ thống người dùng có thể tự động đăng nhập an toàn vào các trang web và máy tính trên mạng của họ mà không yêu cầu họ phải nhớ thông tin tất cả các thời gian.
Kho tiền có thể lưu trữ tất cả các loại thông tin đăng nhập như mật khẩu, chứng chỉ, mã thông báo, v. + Bộ nhớ đệm thông tin phía máy chủ: Cơ chế lưu trữ thông tin xác thực phía máy chủ giống như kiến trúc bộ đệm thông tin xác thực phía máy khách, chỉ khác nhau là thông tin đăng nhập được lưu trữ trong máy chủ thay vì máy khách. Nó sử dụng một máy chủ trung tâm để đảm nhận nhiệm vụ quản trị tất cả các mật khẩu khác nhau và cung cấp thông tin cần thiết trực tiếp cho ứng dụng yêu cầu chúng. Ví dụ: (CA Etrust SSO) 8 d) Giao thức: phụ thuộc vào giao thức triển khai SSO Hình 5: Các hình thức triển khai SSO 2.5 Các giao thức phục vụ triển khai SSO 2.
OAuth2 OAuth2 cung cấp quyền truy cập đã được ủy quyền an toàn (secure delegated access), điều đó có nghĩa là một ứng dụng hay một client có thể thao tác hoặc truy cập các tài nguyên trên một server thay mặt cho một người dùng, mà không cần người sử dụng phải chia sẻ thông tin tài khoản của họ với ứng dụng [2] Sơ đồ luồng hoạt động của Oauth 2: a) Client/Application yêu cầu ủy quyền để truy cập vào máy chủ tài nguyên (resource server) thông qua user b) Nếu user ủy quyền cho yêu cầu trên client 3 sẽ nhận được ủy quyền từ phía người dùng (dưới dạng một chuỗi ký tự mã nào đó chẳng hạn) c) Client gửi thông tin định danh (ID) của mình kèm theo ủy quyền của user tới máy chủ phân quyền (Authorization Server) d) Nếu thông tin định danh được xác thực và ủy quyền hợp lệ, Authorization Server sẽ trả về cho ứng dụng mã xác thực (access token). Đến đây quá trình ủy quyền hoàn tất. e) Để truy cập vào tài nguyên từ máy chủ tài nguyên và lấy thông tin, ứng dụng sẽ phải đưa ra mã xác thực để xác thực. 9 f) Nếu mã xác thực hợp lệ, máy chủ tài nguyên sẽ trả về dữ liệu của tài nguyên đã được yêu cầu cho client.
Hình 6: Sơ đồ luồng của giao thức Oauth2 [1] 2. OpenID Connect OpenID Connect (OIDC) được mô tả như một lớp nhận dạng ở trên OAuth2, cung cấp các phần mở rộng khác nhau, trong đó phần lớn nhất là xác thực. Vì vậy, giao thức này cung cấp ủy quyền (authorization) cũng như xác thực (authentication). Các luồng trong OpenID Connect rất giống với các luồng của OAuth2; sự khác biệt chính là IdP và mã xác thực (ID token) được thêm vào [4].