GIỚI THIỆU 2.1 Tổng quan về Single sign on 2.1.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
GIỚI THIỆU
Tổng quan về Single sign on
SSO (Single Sign-On) là cơ chế xác thực cho phép người dùng chỉ cần đăng nhập một lần duy nhất bằng tài khoản và mật khẩu để truy cập vào nhiều ứng dụng trong cùng một phiên làm việc.
Hình 1: Tổng quan về SSO [1]
Trước khi có SSO, người dùng phải nhập tài khoản và mật khẩu cho từng ứng dụng, gây khó khăn và tăng nguy cơ mất bảo mật Hệ thống sử dụng SSO mang lại nhiều tiện lợi, giúp cải thiện trải nghiệm người dùng và nâng cao tính bảo mật Chẳng hạn, với các dịch vụ của Google như Gmail, YouTube, Drive, Scholar và CHPlay, người dùng chỉ cần một tài khoản Google duy nhất để truy cập vào tất cả các dịch vụ này, tiết kiệm thời gian và công sức.
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.1.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
2 Domain1 redirect 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 login
4 AuthServer thực hiện save cookie với thông tin xác thực của domain1
5 AuthServer send token và redirect 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 redirect về trang login AuthServer để xác thực người dùng
10 AuthServer get thông tin từ cookie ở bước 4 để kiểm tra xác thực
11 AuthServer send token và redirect 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
Kiến trúc Đăng nhập một lần (SSO) đơn giản liên quan đến việc sử dụng một cơ quan xác thực duy nhất Trong mô hình SSO này, có một máy chủ xác thực kết hợp với một cơ sở dữ liệu chứa thông tin đăng nhập duy nhất cho người dùng.
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ư :
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.1.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
Here is the rewritten paragraph:"SSO doanh nghiệp, cũng được biết đến với tên gọi Intranet/Enterprise SSO, cho phép các hệ thống khác nhau trong cùng một doanh nghiệp được kết nối lại với nhau Với SSO doanh nghiệp, số lần người dùng phải đăng nhập tài khoản và mật khẩu vào nhiều ứng dụng sẽ được giảm thiểu đáng kể Khi được triển khai, mỗi máy trạm, bao gồm máy tính để bàn và máy tính xách tay, sẽ được cung cấp một mã token duy nhất để quản lý quá trình xác thực, mang lại sự tiện lợi và an toàn cho người dùng."
SSO đa vùng miền (Extranet/ Multidomain SSO) cho phép kết nối nhiều hệ thống trong cùng một doanh nghiệp cùng với tất cả các ứng dụng của đối tác Người dùng chỉ cần một lần đăng nhập để truy cập vào nhiều doanh nghiệp khác nhau mà không cần nhớ 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
Cấu trúc đơn giản cho phép người dùng sử dụng thông tin đăng nhập riêng và phân quyền cụ thể, đảm bảo tính linh hoạt và bảo mật Hệ thống được triển khai trong môi trường mạng nội bộ đồng nhất, mang lại trải nghiệm dễ dàng và hiệu quả cho từng người dùng.
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) cho phép người dùng gửi thông tin đăng nhập đến cơ quan xác thực, nơi thông tin này được kiểm tra với cơ sở dữ liệu Nếu thông tin đăng nhập khớp, người dùng nhận được mã thông báo Khi muốn truy cập máy chủ ứng dụng của cơ quan xác thực thứ hai, mã thông báo này sẽ được sử dụng để lấy vé truy cập Thành công của quy trình này phụ thuộc vào sự tin tưởng của cơ quan xác thực.
Hệ thống SSO dựa vào mã (token) trên môi trường HTTP có thể được triển khai bằng cách sử dụng cookie, là thông tin được cung cấp cho trình duyệt bởi máy chủ và lưu trữ trên máy khách Cookies có thể được mã hóa để đảm bảo an toàn trong xác thực, cho phép máy chủ truy xuất và cung cấp dịch vụ tùy chỉnh cho người dùng Mặc dù hệ thống Kerberos cung cấp nền tảng cho SSO an toàn, nó yêu cầu cơ sở hạ tầng và cấu hình phía máy khách Ngược lại, trong môi trường HTTP, cookie có thể được sử dụng để xây dựng hệ thống SSO mà không cần cài đặt thêm Điểm khác biệt chính giữa Kerberos và SSO hỗ trợ Cookies là Kerberos sử dụng Cuộc gọi thủ tục từ xa để vận chuyển vé xác thực, trong khi SSO hỗ trợ Cookies sử dụng cookie làm mã thông báo.
Hệ thống SSO dựa trên PKI cho phép người dùng và máy chủ xác thực lẫn nhau thông qua các cặp khóa tương ứng Người dùng có khả năng xác thực máy chủ bằng cách yêu cầu máy chủ giải mã các tin nhắn được mã hóa bằng khóa công khai của họ.
Máy chủ có khả năng xác thực người dùng bằng cách thách thức họ giải mã các tin nhắn được mã hóa bằng khóa công khai của người dùng Chỉ có chủ sở hữu khóa riêng mới có thể thực hiện việc giải mã này, tạo ra một quá trình xác thực lẫn nhau giữa máy chủ và người dùng Nếu các cơ quan chứng nhận của người dùng và máy chủ khác nhau, thì cần phải có sự tin tưởng giữa các cơ quan chứng nhận đó để đảm bảo tính bảo mật.
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 là giải pháp giúp người dùng quản lý nhiều bộ thông tin xác thực cho các hệ thống khác nhau chỉ với một bộ thông tin duy nhất Phần mềm đồng bộ hóa cho phép người dùng dễ dàng thay đổi thông tin đăng nhập trên tất cả các hệ thống, đồng thời tự động chuyển tiếp yêu cầu thay đổi đến các máy chủ xác thực liên quan, như trong trường hợp của Pass Go.
Bộ nhớ đệm thông tin xác thực phía máy chủ là cơ chế lưu trữ thông tin đăng nhập tương tự như bộ đệm thông tin xác thực phía máy khách, nhưng thông tin đăng nhập được lưu trữ trực tiếp trên máy chủ thay vì trên máy khách.
Nó sử dụng một máy chủ trung tâm để quản lý tất cả các mật khẩu và cung cấp thông tin cần thiết cho các ứng dụng yêu cầu Ví dụ điển hình là CA Etrust SSO.
9 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.1.5 Các giao thức phục vụ triển khai SSO
OAuth2 cho phép truy cập an toàn được ủy quyền, cho phép ứng dụng hoặc client thao tác và truy cập tài nguyên trên server thay mặt người dùng mà không cần chia sẻ thông tin tài khoản.
Một số vấn đề thường gặp khi triển khai SSO
Triển khai SSO (Single Sign-On) là giải pháp lý tưởng cho các doanh nghiệp lớn với hệ sinh thái phong phú và lượng nhân lực đông đảo Lợi ích chính của SSO là nâng cao trải nghiệm người dùng, đồng thời hỗ trợ doanh nghiệp trong việc triển khai hệ thống theo mô hình microservice một cách dễ dàng và hiệu quả.
Việc triển khai dịch vụ theo mô hình microservice mang lại ý nghĩa lớn cho doanh nghiệp, đặc biệt khi có một lượng khách hàng lớn thường xuyên tương tác với hệ thống Doanh nghiệp có nhu cầu sử dụng thông tin từ các tương tác của khách hàng để cải thiện chăm sóc khách hàng và phát triển các chiến lược, kế hoạch kinh doanh phù hợp Sự hỗ trợ của trí tuệ nhân tạo (AI) và học máy (Machine Learning) sẽ mang lại lợi ích đáng kể cho cả doanh nghiệp và khách hàng.
SSO là một công cụ mạnh mẽ nhưng cũng tiềm ẩn rủi ro nếu không được triển khai đúng cách Nó không tự động cải thiện bảo mật, và nếu không tuân thủ các quy định nghiêm ngặt, có thể làm giảm khả năng bảo vệ hệ thống, dẫn đến nguy cơ bị tấn công từ tin tặc Rủi ro này càng lớn hơn khi các dịch vụ trong hệ sinh thái không được triển khai và giám sát đồng nhất, nhân sự không tương đồng, và các giải pháp không được áp dụng một cách nghiêm túc.
Hiện trạng đăng nhập ứng dụng tại Tổng cục Thế và đề xuất hướng giải quyết
Here is a rewritten paragraph that contains the important sentences and complies with SEO rules:ASP.NET Core là một phần mềm mã nguồn mở và framework đa nền tảng cho việc xây dựng các ứng dụng hiện tại dựa trên kết nối đám mây, bao gồm web apps, IoT và backend cho mobile Được thiết kế để cung cấp và tối ưu framework cho các ứng dụng được triển khai trên đám mây hoặc chạy theo nhu cầu, ASP.NET Core có thể chạy trên NET Core hoặc trên phiên bản đầy đủ của NET Framework Với các thành phần theo hướng module, ASP.NET Core giúp tối thiểu tài nguyên và chi phí phát triển, mang lại sự mềm giẻo trong việc xây dựng giải pháp của bạn.
23 bạn Có thể phát triển và chạy những ứng dụng ASP.NET Core đa nền tảng trên Windows, Mac và Linux
Here is a rewritten paragraph that complies with SEO rules:"Hệ thống phần mềm ứng dụng ngành Thuế hiện nay chủ yếu được phát triển trên nền tảng ASP.NET Core, bao gồm bốn hệ thống phần mềm ứng dụng chính Trong đó, hệ thống ứng dụng phục vụ công tác nội bộ của ngành tập trung vào quản lý công văn và các chức năng khác Ngoài ra, hệ thống ứng dụng hỗ trợ người nộp thuế cung cấp các tiện ích như kê khai thuế qua mạng, nộp thuế điện tử và quyết toán thuế thu nhập cá nhân online, góp phần nâng cao hiệu quả và thuận tiện cho người dùng."
Hệ thống ứng dụng trao đổi thông tin với bên ngoài bao gồm các ứng dụng kết nối với cơ quan nhà nước và ngân hàng Ngoài ra, hệ thống ứng dụng phục vụ công tác quản lý thuế của ngành Thuế bao gồm các ứng dụng lõi thiết yếu cho hoạt động quản lý thuế.
Hệ thống ứng dụng ngành Thuế hiện nay yêu cầu người nộp thuế đăng nhập bằng tài khoản và mật khẩu riêng cho từng ứng dụng, gây bất tiện và tốn nhân lực hỗ trợ Do đó, nhu cầu triển khai cơ chế SSO (Single Sign-On) là cần thiết Cơ chế SSO cho phép người dùng hợp pháp truy cập nhiều hệ thống chỉ với một tài khoản duy nhất, giúp tiết kiệm thời gian và nâng cao hiệu quả sử dụng dịch vụ thuế Khi người dùng đăng nhập vào một hệ thống, họ sẽ tự động được đăng nhập vào tất cả các hệ thống liên quan.
ASP.NET Core Identity is an API that facilitates user interface (UI) login functionality, user management, password handling, profile data, roles, claims, tokens, and email verification Users can create accounts with credentials stored in Identity or utilize external login providers such as Facebook, Google, Microsoft Accounts, and Twitter This framework enhances UI login capabilities for ASP.NET Core web applications To secure web APIs and Single Page Applications (SPAs), options include Azure Active Directory, Azure Active Directory B2C (Azure AD B2C), and IdentityServer4.
IdentityServer4 is an open-source framework that supports OpenID Connect and OAuth 2.0 on ASP.NET Core It enables Single Sign-On (SSO), token issuance, authentication, and other standard protocols Consequently, I conducted experiments on the SSO solution utilizing IdentityServer4.
GIỚI THIỆU IDENTITYSERVER
Khái niệm
Hình 14: Mô hình của các ứng dụng hiện đại [5]
Các tương tác phổ biến trong công nghệ bao gồm: trình duyệt giao tiếp với ứng dụng web, ứng dụng web giao tiếp với API web, và ứng dụng gốc cũng như ứng dụng dựa trên máy chủ tương tác với API web Thêm vào đó, API web có thể giao tiếp với nhau, thường là để phục vụ người dùng Mỗi lớp trong kiến trúc (mặt trước, tầng giữa và mặt sau) cần bảo vệ tài nguyên và thực hiện xác thực hoặc ủy quyền, thường cho cùng một cửa hàng người dùng Việc thuê ngoài các chức năng bảo mật cơ bản cho dịch vụ mã thông báo bảo mật giúp ngăn chặn việc sao chép chức năng này trên các ứng dụng và điểm cuối.
Tái cấu trúc ứng dụng để hỗ trợ dịch vụ mã thông báo bảo mật dẫn đến kiến trúc và giao thức sau:
Hình 15: Kiến trúc ứng dụng sử dụng mã thông báo bảo mật [5]
Thiết kế như vậy chia mối quan tâm bảo mật thành hai phần: a) Xác thực:
Xác thực là yếu tố quan trọng khi ứng dụng cần nhận diện người dùng hiện tại, đảm bảo rằng họ chỉ truy cập vào dữ liệu mà mình được phép Điều này đặc biệt cần thiết trong các ứng dụng quản lý dữ liệu, từ ứng dụng web truyền thống đến ứng dụng gốc và dựa trên JavaScript, nơi yêu cầu xác thực để bảo vệ thông tin người dùng.
Các giao thức xác thực phổ biến nhất là SAML2p, WS-Liên kết và OpenID Connect - SAML2p là phổ biến nhất và được triển khai rộng rãi nhất
OpenID Connect là công nghệ mới nhất trong ba loại, được xem là tương lai cho các ứng dụng hiện đại nhờ vào tiềm năng vượt trội Được phát triển dành riêng cho các kịch bản ứng dụng di động, OpenID Connect mang lại sự thân thiện với API, giúp tối ưu hóa trải nghiệm người dùng và tăng cường khả năng truy cập API.
Các ứng dụng giao tiếp với API thông qua hai phương thức chính: sử dụng danh tính ứng dụng và ủy quyền nhận dạng người dùng Trong một số trường hợp, cần kết hợp cả hai phương pháp này để đảm bảo hiệu quả tối ưu.
OAuth2 là giao thức cho phép ứng dụng yêu cầu mã thông báo truy cập từ dịch vụ bảo mật và sử dụng chúng để tương tác với API Việc ủy quyền này giúp giảm bớt sự phức tạp cho cả ứng dụng khách và API, vì quá trình xác thực và ủy quyền được tập trung hóa.
OpenID Connect và OAuth 2.0 đang trở thành giải pháp tối ưu cho việc bảo mật ứng dụng hiện đại IdentityServer4, một triển khai của hai giao thức này, được tối ưu hóa để giải quyết các vấn đề bảo mật phổ biến trong các ứng dụng di động, bản địa và web hiện nay.
IdentityServer4 là một framework hỗ trợ OpenID Connect và OAuth 2.0 trên ASP.NET Core
Hình 16: Sơ đồ khối của hệ thống sử dụng IdentityServer [5]
Trong hệ thống này, User là cá nhân sử dụng các client đã đăng ký để truy cập các resource Client là phần mềm yêu cầu mã từ IdentityServer để xác thực User (thông qua yêu cầu Identity token) hoặc để truy cập tài nguyên (thông qua yêu cầu Access token) Trước khi gửi yêu cầu mã, Client phải được đăng ký với IdentityServer Các Client có thể là ứng dụng web, ứng dụng di động hoặc ứng dụng máy tính Resource là các tài nguyên được bảo vệ bởi IdentityServer.
29 d) Identity data là các thông tin nhận dạng về user như tên, địa chỉ email,
API resource là chức năng mà client yêu cầu từ Web API Identity token là kết quả của quá trình xác thực, bao gồm mã xác thực người dùng và thông tin về cách thức cũng như thời điểm xác thực Access token cho phép truy cập vào API resource, được yêu cầu bởi client và chuyển tới API Access token chứa thông tin về client và người dùng, giúp API phân quyền truy cập dữ liệu.
Hoạt động của IdentityServer4
Users seeking access to applications and APIs request tokens from IdentityServer4 for authentication (identity tokens) or resource access (access tokens) Access tokens contain information about both the client and the user, enabling them to connect to APIs In contrast, identity tokens encompass all user identification data, which is utilized for user authentication.
Các tính năng của IdentityServer4
Here are the rewritten paragraphs:Effective identity and access management involves protecting valuable resources, authenticating users, and managing sessions and single sign-on (SSO) authentication This ensures that only authorized individuals have access to sensitive information and systems Additionally, managing and authenticating clients is crucial to prevent unauthorized access and data breaches To facilitate secure communication, identity tokens and access tokens are issued to clients, enabling them to access protected resources Furthermore, verifying codes and tokens is essential to prevent fraudulent activities and ensure the integrity of the system.
Các chuẩn hỗ trợ
OpenID Connect Front-Channel Logout 1.0
OpenID Connect Back-Channel Logout 1.0 b) OAuth 2.0
OAuth 2.0 Form Post Response Mode
Proof Key for Code Exchange
JSON Web Tokens for Client Authentication
OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens
Đăng nhập
Để IdentityServer phát hành mã thông báo thay mặt cho người dùng, người dùng đó phải đăng nhập vào IdentityServer
Khi IdentityServer nhận yêu cầu tại điểm cuối ủy quyền mà người dùng chưa được xác thực, họ sẽ được chuyển hướng đến trang đăng nhập đã được cấu hình Để thông báo cho IdentityServer về đường dẫn đến trang đăng nhập, cần sử dụng các tùy chọn UserInteraction, với giá trị mặc định là /account/login Ngoài ra, tham số returnUrl cũng cần được thông báo để chỉ định trang mà người dùng sẽ được chuyển hướng đến sau khi hoàn tất đăng nhập.
Đăng xuất
Đăng xuất khỏi IdentityServer rất đơn giản, chỉ cần xóa cookie xác thực Tuy nhiên, để thực hiện quá trình đăng xuất một cách hoàn chỉnh, hệ thống cần xem xét việc đăng xuất người dùng khỏi các ứng dụng khách và có thể cả nhà cung cấp nhận dạng.
Khi người dùng đăng xuất khỏi IdentityServer và đã sử dụng nhà cung cấp nhận dạng bên ngoài, họ có thể được chuyển hướng để đăng xuất khỏi nhà cung cấp này Tuy nhiên, không phải tất cả các nhà cung cấp bên ngoài đều hỗ trợ tính năng đăng xuất, điều này phụ thuộc vào giao thức và tính năng mà họ cung cấp Để xác định xem người dùng có cần được chuyển hướng đến nhà cung cấp nhận dạng bên ngoài để đăng xuất hay không, thường sử dụng khiếu nại ID được lưu trong cookie tại IdentityServer Giá trị trong khiếu nại này là AuthenticationScheme của phần mềm trung gian xác thực tương ứng, và tại thời điểm đăng xuất, yêu cầu sẽ được kiểm tra để quyết định xem có cần thực hiện đăng xuất bên ngoài hay không.
Việc chuyển hướng người dùng đến một nhà cung cấp nhận dạng bên ngoài có thể gặp khó khăn do yêu cầu dọn dẹp và quản lý trạng thái trong quy trình đăng xuất thông thường Để hoàn tất quy trình đăng xuất và dọn dẹp tại IdentityServer, cần yêu cầu nhà cung cấp nhận dạng bên ngoài chuyển hướng người dùng trở lại IdentityServer sau khi đăng xuất Tuy nhiên, không phải tất cả các nhà cung cấp bên ngoài đều hỗ trợ tính năng chuyển hướng sau đăng xuất, điều này phụ thuộc vào giao thức và tính năng mà họ cung cấp.
Sau khi đăng xuất, quy trình bao gồm theo dõi cookie xác thực của IdentityServer để hoàn tất việc đăng xuất và chuyển hướng đến nhà cung cấp bên ngoài để xác minh yêu cầu đăng xuất Để duy trì trạng thái đăng xuất, giá trị tham số logoutId cần được giữ nguyên Sau khi đăng xuất thành công tại nhà cung cấp bên ngoài, sử dụng API AuthenticationProperties của ASP.NET Core để chuyển hướng trở lại IdentityServer.
Đăng xuất liên kết
Đăng xuất liên kết xảy ra khi người dùng sử dụng nhà cung cấp nhận dạng bên ngoài để đăng nhập vào IdentityServer và sau đó thực hiện đăng xuất khỏi nhà cung cấp đó Việc nhận dạng thông báo đăng xuất là cần thiết để đảm bảo người dùng được đăng xuất khỏi IdentityServer cũng như tất cả các ứng dụng liên quan.
Không phải tất cả các nhà cung cấp nhận dạng bên ngoài đều hỗ trợ đăng xuất liên kết, nhưng họ cung cấp cơ chế thông báo cho khách hàng khi người dùng đã đăng xuất Thông báo này thường xuất hiện dưới dạng yêu cầu từ trang của nhà cung cấp nhận dạng bên ngoài IdentityServer cần thông báo cho tất cả khách hàng của mình qua yêu cầu từ bên trong nhà cung cấp nhận dạng Đăng xuất liên kết khác với đăng xuất thông thường vì yêu cầu này không phải là điểm cuối đăng xuất thông thường trong IdentityServer; mỗi nhà cung cấp nhận dạng bên ngoài có điểm cuối riêng để kết nối với máy chủ IdentityServer, do việc sử dụng các giao thức và phần mềm trung gian khác nhau.
Tác động của các yếu tố này là không có trang nào được đăng xuất ra khỏi trang bị xóa như trong quy trình đăng xuất thông thường, dẫn đến việc thiếu thông báo đăng xuất cho khách hàng của IdentityServer Để giải quyết vấn đề này, chúng tôi cần thêm mã cho từng điểm cuối đăng xuất liên kết nhằm hiển thị các thông báo cần thiết để thực hiện quá trình đăng xuất liên kết.
"Xin lưu ý, IdentityServer đã integrà mã này Khi nhận được yêu cầu vào IdentityServer và gọi quá trình xử lý cho các nhà cung cấp xác thực bên ngoài, hệ thống sẽ tự động phát hiện các yêu cầu đăng xuất liên kết và tự động hiển thị các iframe để xử lý đăng xuất Trong vòng tới đây, chức năng đăng xuất liên kết sẽ được hỗ trợ tự động."
Cổng kết nối liên kết
Cổng kết nối (gateway) là một kiến trúc phổ biến, trong đó IdentityServer đóng vai trò là cổng vào cho một hoặc nhiều nhà cung cấp nhận dạng bên ngoài.
Kiến trúc này mang lại nhiều lợi ích, bao gồm: a) Các ứng dụng chỉ cần biết về dịch vụ một mã thông báo (gateway), giúp bảo vệ khỏi các chi tiết kết nối với các nhà cung cấp bên ngoài, đồng thời cho phép thêm hoặc thay đổi nhà cung cấp mà không cần cập nhật ứng dụng b) Kiểm soát cổng kết nối cho phép thực hiện các thay đổi mà không bị ảnh hưởng bởi các thay đổi từ nhà cung cấp bên ngoài c) Cổng kết nối giúp xử lý hậu kỳ phản hồi từ các nhà cung cấp, cho phép chuyển đổi, thêm hoặc sửa đổi thông tin nhận dạng tên miền d) Cổng kết nối có thể phát hành mã thông báo truy cập dựa trên các danh tính bên ngoài, ngay cả khi một số nhà cung cấp không hỗ trợ mã này e) Các cổng kết nối hoạt động như một ứng dụng duy nhất cho nhà cung cấp bên ngoài, cho phép kết nối nhiều ứng dụng nội bộ mà không bị giới hạn.
Một số nhà cung cấp áp dụng giao thức độc quyền hoặc sửa đổi các giao thức chuẩn, dẫn đến việc chỉ có một cổng kết nối duy nhất cần xử lý Việc buộc mọi xác thực, dù là nội bộ hay bên ngoài, thông qua một điểm duy nhất mang lại sự linh hoạt lớn trong ánh xạ định danh, đồng thời cung cấp danh tính ổn định cho tất cả ứng dụng và xử lý các yêu cầu mới một cách hiệu quả.
Xác thực ứng dụng khách
Trong một số tình huống cụ thể, khách hàng cần thực hiện xác thực với IdentityServer, bao gồm: a) các ứng dụng bí mật (hay còn gọi là khách hàng) yêu cầu mã thông báo từ điểm cuối mã thông báo; b) API xác thực mã thông báo tham chiếu tại điểm cuối nội quan.
Với mục đích đó, có thể chỉ định một danh sách các bí mật cho khách hàng hoặc tài nguyên API
Phân tích và xác thực bí mật là một tính năng mở rộng trong máy chủ nhận dạng, cho phép hỗ trợ các bí mật được chia sẻ Nó cũng cho phép truyền tải bí mật thông qua tiêu đề xác thực cơ bản hoặc phần thân của yêu cầu POST.
ÁP DỤNG THỬ NGHIỆM TẠI TỔNG CỤC THUẾ
Kịch bản triển khai
Trong luận văn này, tôi sẽ phát triển cổng xác thực SSO theo mô hình đơn giản như hình minh họa Mô hình này sẽ được thử nghiệm trên hệ thống cục bộ trong khuôn khổ nghiên cứu.
Hình 19: Mô hình thử nghiệm áp dụng
Khối Identity Server 4 đảm nhiệm chức năng xác thực người dùng, cung cấp quyền truy cập vào các dịch vụ Trong khi đó, các dịch vụ Thuế điện tử do Tổng cục Thuế cung cấp bao gồm nộp thuế điện tử và kê khai thuế qua mạng, phục vụ nhu cầu của người nộp thuế.
4.1.2 Nguyên tắc hoạt động a) Người nộp Thuế truy cập vào dịch vụ web để đăng nhập một lần các dịch vụ Thuế điện tử b) Hệ thống SSO sẽ yêu cầu người nộp Thuế đăng nhập bằng tài khoản và mật khẩu được cấp c) Nếu người nộp Thuế đăng nhập đúng thông tin thì hệ thống sẽ hỏi người nộp Thuế muốn sử dụng dịch vụ Thuế điện tử nào d) Sau khi người nộp Thuế lựa chọn dịch vụ Thuế điện tử thì sẽ không cần phải đăng nhập lại
4.1.3 Mục tiêu a) Giảm thời gian người nộp Thuế thực hiện trong các hoạt động đăng nhập vào các dịch vụ Thuế điện tử b) Cải thiện bảo mật thông qua việc giảm nhu cầu cho người dùng xử lý và ghi nhớ nhiều bộ thông tin xác thực c) Người dùng không phải ghi nhớ nhiều tên và mật khẩu khác nhau d) Giảm nhân lực CNTT phục vụ việc hỗ trợ nhập mật khẩu của người dùng.
Các bước thực hiện như sau
+ Cấu hình OpenIdConnect, redirect tới trang callback.html sau khi login thành công IdentityServer:
Hình 21: Cấu hình redirect tới trang callback.html
+ Tạo hàm xử lý sự kiện click nút Login, Logout:
Hình 22: Hàm xử lý login, logout
File redirect.html: trỏ tới các dịch vụ sau khi đăng nhập thành công
Hình 24: File redirect.html b) Bên Identity Server (dùng IdentityServerAspNetIdentity)
Hình 25: Cấu trúc thư mục
File Config.cs, cấu hình các Ids, Apis, Clients (thông tin client phải khớp với cấu hình client bên javascript như ClientId, RedirecUris, AllowedGrantTypes, AllowedScopes):
File Startup.cs, thiết lập các service cho IdentityServer với các config đã cho:
Cấu hình IdentityServer để thực hiện SSO
Hình 29: Khởi tạo Client b) Quá trình xác thực người dùng
- IdentityServer sử dụng Authorization Code Flow
Luồng xử lý của Authorization Code Flow như sau:
Hình 30: Hoạt động của Luồng mã ủy quyền
Các bước xử lý như sau:
1 Client gửi yêu cầu xác thực đến IdentityServer:
{"ClientId": "js", "ClientName": "JavaScript Client", "RedirectUri":
"http://localhost:5003/redirect.html", "AllowedRedirectUris": ["http://localhost:5003/redirect.html"], "SubjectId": "00ebf9d7-9fdd-4ca7- a2ea-04e6c7a5f077", "ResponseType": "code", "ResponseMode":
"query", "GrantType": "authorization_code", "RequestedScopes": "openid profile", "State": "c37aad380230435a82ef296a1080970a", "UiLocales": null, "Nonce": null, "AuthenticationContextReferenceClasses": null,
"DisplayMode": null, "PromptMode": null, "MaxAge": null, "LoginHint": null, "SessionId": "pjN083vM0zdwgBkKvCWaaw", "Raw": {"client_id":
"js", "redirect_uri": "http://localhost:5003/redirect.html", "response_type":
"code", "scope": "openid profile", "state":
"lzqvt8wP2G4BKoC_hrsgO4IdPMTAKZrfLnR5gEEQiH8",
"code_challenge_method": "S256", "response_mode": "query"}, "$type":
Hình 31: Client gửi yêu cầu xác thực đến IdentityServer
2 IdentityServer xác thực người dùng và yêu cầu người dùng xác nhận để chia sẻ thông tin với client:
{"Username": "alice", "Provider": null, "ProviderUserId": null,
"SubjectId": "00ebf9d7-9fdd-4ca7-a2ea-04e6c7a5f077", "DisplayName":
"alice", "Endpoint": "UI", "ClientId": "js", "Category": "Authentication",
"Name": "User Login Success", "EventType": "Success", "Id": 1000,
"Message": null, "ActivityId": "0HM1T379OGP6H:00000006",
Hình 32: IdentityServer xác thực người dùng
Hình 33: IdentityServer yêu cầu người dùng xác nhận để chia sẻ thông tin với client
3 IdentityServer chuyển hướng người dùng đến client với một mã xác thực {"ClientId": "js", "ClientName": "JavaScript Client", "RedirectUri":
"http://localhost:5003/redirect.html", "AllowedRedirectUris": ["http://localhost:5003/redirect.html"], "SubjectId": "00ebf9d7-9fdd-4ca7-a2ea- 04e6c7a5f077", "ResponseType": "code", "ResponseMode": "query",
"GrantType": "authorization_code", "RequestedScopes": "openid profile",
"State": "c37aad380230435a82ef296a1080970a", "UiLocales": null, "Nonce": null, "AuthenticationContextReferenceClasses": null, "DisplayMode": null,
"PromptMode": null, "MaxAge": null, "LoginHint": null, "SessionId":
"pjN083vM0zdwgBkKvCWaaw", "Raw": {"client_id": "js", "redirect_uri":
"http://localhost:5003/redirect.html", "response_type": "code", "scope": "openid
44 profile", "state": "c37aad380230435a82ef296a1080970a", "code_challenge":
"lzqvt8wP2G4BKoC_hrsgO4IdPMTAKZrfLnR5gEEQiH8",
"code_challenge_method": "S256", "response_mode": "query"}, "$type":
Hình 34: IdentityServer chuyển hướng người dùng đến client với một mã xác thực
4 Client gửi mã xác thực và yêu cầu access token
{"ClientId": "js", "ClientName": "JavaScript Client", "RedirectUri":
"http://localhost:5003/redirect.html", "Endpoint": "Authorize", "SubjectId":
"00ebf9d7-9fdd-4ca7-a2ea-04e6c7a5f077", "Scopes": "openid profile",
"GrantType": "authorization_code", "Tokens": [{"TokenType": "code",
"TokenValue": "****Syhw", "$type": "Token"}], "Category": "Token",
"Name": "Token Issued Success", "EventType": "Success", "Id": 2000,
"Message": null, "ActivityId": "0HM1T379OGP6H:0000000C", "TimeStamp":
Hình 35: Client gửi mã xác thực và yêu cầu access token
5 IdentityServer xác thực yêu cầu và sinh ra Access token như sau:
AspNetCore.Antiforgery.fGd5_-dvDmEJ8AMtv-
I'm sorry, but the text you've provided appears to be a string of encoded or hashed data rather than coherent content that can be rewritten into a meaningful paragraph If you have a different article or text that you'd like help with, please share that, and I'll be happy to assist!
I'm sorry, but the text you've provided appears to be a random string of characters and does not convey any coherent meaning or context for rewriting Please provide a clear and meaningful article or text that you'd like me to help rewrite.
8U0NqdUaelvw1gam_Qz7IAJSpGXAIXuOvIvhW3sMDW1i4YueKgobSDWMvjhkiItYuwn0YXq9Wr3F9FynCDL784Z4pn6tGJ3YcCWH9zlORrU88YARUNzDjIljpS98veAkipPERSQfwzE1YmAWVFhzbsANj49r1M4e8FkVNUbdbsAQS3Gdx237UR94f2Ic0lYuK0l9zfiO1A2uVrA7RIk3hqd6ULv1WS6KQ_ahmGU1
ZEjGjUev9EL-hgyVZoJGaxEoi9d4EoJaKOfww-N7IpC8HaDL-8WpeGLGUZ0MEj3GGJPfU-
JsuSGXmFSg3GX0mWivywH_2ndfKGFjzoVcfyV2low
6 Sau khi có thông tin, sẽ redirect đến thông tin người dùng được phân quyền
{"SubjectId": "00ebf9d7-9fdd-4ca7-a2ea-04e6c7a5f077", "ClientId": "js",
"RedirectUri": "http://localhost:5003/redirect.html", "State":
"c37aad380230435a82ef296a1080970a", "Scope": "openid profile",
"Error": null, "ErrorDescription": null, "$type":
7 Client dùng access token để yêu cầu các dịch vụ
Hình 36: Client dùng access token để yêu cầu các dịch vụ
Kết quả đạt được
Hình 37: Đăng nhập client b) Chọn login Sau đó đăng nhập user/pass:
Hình 38: Đăng nhập user/pass
47 c) Lựa chọn các dịch vụ cần truy cập:
Hình 39: Lựa chọn các dịch vụ
Hình 40: Kết quả lựa chọn dịch vụ
Tích hợp SSO vào các ứng dụng khác
- Thực hiện tích hợp IdentiyServer với các database chứa cơ sở dữ liệu xác thực người dùng:
Cấu hình trong Configure services trong Startup class
48 services.AddDbContext(options => options.UseSqlite(Configuration.GetConnectionString("DefaultConnection"))); services.AddIdentity()
Cấu hình Configure method trong Startup class services.AddAuthentication()
AddMicrosoftAccount(options => { options.ClientId = _clientId; options.SignInScheme = "Identity.External"; options.ClientSecret = _clientSecret;
- Khi đó tại màn hình login sẽ cho chọn đăng nhập bằng database chứa CSDL người dùng Ví dụ như ở dưới là chọn Microsoft
Hình 41: Lựa chọn đăng nhập bằng database chứa CSDL người dùng
-Sau khi chọn hình thức đăng nhập thì sẽ redirect đến web đăng nhập của database:
Hình 42: Đăng nhập bằng Microsoft
- Sau khi đăng nhập thành công, sẽ chuyển đến trang xác nhân để chia sẻ thông tin
Hình 43: Xác nhân để chia sẻ thông tin
- Sau khi xác nhận chia sẻ thông tin, thì sẽ chuyển đến trang lựa chọn dịch vụ
Hình 44: Lựa chọn dịch vụ
Khi sử dụng nhiều CSDL xác thực khác, tại trang đăng nhập cũng sẽ có lựa chọn để người dùng
Đánh giá kết quả
Giải pháp xây dựng hệ thống SSO sử dụng IdentityServer4 đã được áp dụng thành công cho các ứng dụng hỗ trợ Người nộp thuế, bao gồm kê khai thuế qua mạng, nộp thuế điện tử và quyết toán thuế thu nhập cá nhân online Kết quả thử nghiệm cho thấy hệ thống SSO đã nâng cao trải nghiệm người dùng, cho phép tích
Trong khuôn khổ luận văn, do thời gian hạn chế, giải pháp hiện chưa được triển khai cho Hệ thống ứng dụng phục vụ công tác nội bộ của Tổng cục Thuế, bao gồm các ứng dụng quản lý công văn và trao đổi thông tin với các cơ quan nhà nước, ngân hàng Hệ thống ứng dụng phục vụ công tác quản lý thuế cũng chưa được thử nghiệm kết nối đến cơ sở dữ liệu của người nộp thuế, do yêu cầu bảo mật thông tin.