Tìm hiểu các chuẩn kết nối single sign on đánh giá và áp dụng thử nghiệm tại tổng cục thuế

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

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

Giảng viên hướng dẫn: TS Trần Hoàng Hải

Viện: Công nghệ thông tin và truyền thông

HÀ NỘI, 2020

TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI

Giảng viên hướng dẫn: TS Trần Hoàng Hải

HÀ NỘI, 2020

Chữ ký của GVHD

CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM

Độc lập – Tự do – Hạnh phúc BẢN XÁC NHẬN CHỈNH SỬA LUẬN VĂN THẠC SĨ

Họ và tên tác giả luận văn : Ngô Minh Cường

Đề tài luận văn: Tìm hiểu các chuẩn kết nối single sign on, đánh giá và

áp dụng thử nghiệm tại Tổng cục Thuế

Ngành: Công nghệ thông tin

Mã số SV: CB180192

Tác giả, Người hướng dẫn khoa học và Hội đồng chấm luận văn xác nhận tác giả đã sửa chữa, bổ sung luận văn theo biên bản họp Hội đồng ngày

27/6/2020 với các nội dung sau:

STT Nội dung chỉnh sửa Mục Trang

1 Bổ sung kiến thức về SSO 2.1.2, 2.1.3,2.1.4 13-18

Hà Nội, ngày … tháng … năm 2020

Tác giả LVThS

Ngô Minh Cường

Tóm tắt nội dung luận văn Tên đề tài (tiếng Việt): Tìm hiểu các chuẩn kết nối Single Sign on, đánh

giá và áp dụng thử nghiệm tại Tổng cục Thuế

Tên đề tài (tiếng Anh): Learn the standards of Single Sign on connection,

assessment and test application at the General Department of Taxation

Tác giả luận văn: Ngô Minh Cường

Chuyên ngành: Công nghệ thông tin Khóa: 2018B

Người hướng dẫn: TS Trần Hoàng Hải - Viện Công nghệ thông tin và

Truyền thông, Trường Đại học Bách khoa Hà Nội

Nội dung tóm tắt:

1 Cơ sở khoa học và thực tiễn của luận văn

Trong thời gian gần đây với sự phát triển của nghành Công nghệ thông tin,

xu hướng các dịch vụ cùng nhau chia sẻ dữ liệu người dùng đang là hướng phát triển chung Thực tế một người dùng quản lý rất nhiều tài khoản, mật khẩu cho các dịch vụ, ứng dụng mà họ tham gia Việc người dùng quản lí các thông tin tài khoản

và sử dụng sẽ nảy sinh các vấn đề không đảm bảo tính an ninh, an toàn và phát sinh thêm những nghiệp vụ khác

Hệ thống phần mềm ứng dụng ngành Thuế được chia thành 4 hệ thống phần mềm ứng dụng chính như sau:

- Hệ thống ứng dụng phục vụ công tác nội bộ của ngành bao gồm các ứng dụng về quản lý công văn, …

- Hệ thống ứng dụng hỗ trợ Người nộp thuế bao gồm các ứng dụng về kê khai thuế qua mạng, nộp thuế điện tử, quyết toán thuế thu nhập cá nhân online, …

- 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

để trao đổi thông tin với các cơ quan nhà nước, các ngân hang, ,

- 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 của ngành Thuế

Đối với các ứng dụng hỗ trợ người nộp Thuế, mỗi hệ thống đều yêu cầu đăng nhập tài khoản và mật khẩu riêng khi sử dụng Điều này dẫn đến khá nhiều bất tiện cho người nộp Thuế và các cơ quan Thuế tốn khá nhiều nhân lực để hỗ trợ người nộp Thuế

Do vậy nhu cầu đăng nhập một lần – Single sign-on cho các ứng dụng và

vụ này là cấp thiết Cơ chế SSO đảm bảo cho người dùng hợp pháp có thể truy cập

và một hệ thống hay nhiều hệ thống kết nối với nhau, chỉ phải sử dụng một tài khoản duy nhất SSO cho phép người dùng đăng nhập vào một hệ thống, họ sẽ đăng nhập vào tất cả các hệ thống liên quan

2 Mục đích của đề tài (các kết quả cần đạt được):

Đề tài được thực hiện với các mục đích sau:

- Nghiên cứu các chuẩn kết nối Single Sign on

- Xây dựng và triển khai thử nghiệm cổng xác thực SSO tại Tổng cục Thuế

3 Phương pháp nghiên cứu

- Phương pháp nghiên cứu lý thuyết: Đọc, tìm hiểu các tài liệu, kiến thức liên quan đến: Single sign-on; OpenID, Oauth2, SAML; IdentityServer

- Phương pháp thực nghiệm: Lựa chọn giải pháp phù hợp xây dựng hệ thống SSO; Thực nghiệm, phân tích, đánh giá kết quả của giải pháp

MỤC LỤC

CHƯƠNG 1 MỞ ĐẦU 1

1 Đặt vấn đề 1

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

3 Bố cục luận văn 2

CHƯƠNG 2 GIỚI THIỆU 3

2.1 Tổng quan về Single sign on 3

2.1.1 Khái niệm 3

2.1.2 Nguyên lý hoạt động của Single sign-on 4

2.1.3 Kiến trúc SSO 5

2.1.4 Các hình thức triển khai SSO 6

2.1.5 Các giao thức phục vụ triển khai SSO 9

2.1.6 So sánh các giao thức 18

2.1.7 Một số giải pháp SSO hiện nay 19

2.1.8 Keycloak (Red Hat Single Sign-On): 21

2.1.9 Lợi ích của SSO 21

2.2 Một số vấn đề thường gặp khi triển khai SSO 22

2.3 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 22

CHƯƠNG 3 GIỚI THIỆU IDENTITYSERVER 26

3.1 Khái niệm 26

3.2 Hoạt động của IdentityServer4 29

3.3 Các tính năng của IdentityServer4 29

3.4 Các chuẩn hỗ trợ 29

3.5 Đăng nhập 30

3.6 Đăng xuất 31

3.7 Đăng xuất liên kết 32

3.8 Cổng kết nối liên kết 33

3.9 Xác thực ứng dụng khách 34

CHƯƠNG 4 ÁP DỤNG THỬ NGHIỆM TẠI TỔNG CỤC THUẾ 35

4.1 Kịch bản triển khai 36

4.1.1 Mô hình triển khai 36

4.1.2 Nguyên tắc hoạt động 37

4.1.3 Mục tiêu 37

4.2 Các bước thực hiện như sau 37

4.3 Cấu hình IdentityServer để thực hiện SSO 41

4.4 Kết quả đạt được 46

4.5 Tích hợp SSO vào các ứng dụng khác 47

4.6 Đánh giá kết quả 51

CHƯƠNG 5 KẾT LUẬN 52

TÀI LIỆU THAM KHẢO 53

DANH MỤC HÌNH VẼ

Hình 1: Tổng quan về SSO [1] 3

Hình 2: Nguyên lý hoạt động của SSO 4

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 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 6

Hình 5: Các hình thức triển khai SSO 9

Hình 6: Sơ đồ luồng của giao thức Oauth2 [1] 10

Hình 7: Các thành phần của OpenID Connect [4] 11

Hình 8: Hoạt động của Luồng mã ủy quyền 12

Hình 9: Sơ đồ luồng xử lý của giao thức SAML [4] 15

Hình 10: Sơ đồ luồng xử lý của giao thức LDAP [4] 16

Hình 11: Xác thực sử dụng LDAP [4] 17

Hình 12: Luồng xử lý của giao thức CAS [4] 18

Hình 13: Hệ thống ứng dụng ngành Thuế 24

Hình 14: Mô hình của các ứng dụng hiện đại [5] 26

Hình 15: Kiến trúc ứng dụng sử dụng mã thông báo bảo mật [5] 27

Hình 16: Sơ đồ khối của hệ thống sử dụng IdentityServer [5] 28

Hình 17: Luồng đăng nhập 30

Hình 18: Cổng kết nối 33

Hình 19: Mô hình thử nghiệm áp dụng 36

Hình 20: File index.html 37

Hình 21: Cấu hình redirect tới trang callback.html 38

Hình 22: Hàm xử lý login, logout 38

Hình 23: File callback.html 38

Hình 24: File redirect.html 39

Hình 25: Cấu trúc thư mục 39

Hình 26: File config.cs 40

Hình 27: File startup.cs 40

Hình 28: Khởi tạo IdentityServer 41

Hình 29: Khởi tạo Client 41

Hình 30: Hoạt động của Luồng mã ủy quyền 42

Hình 31: Client gửi yêu cầu xác thực đến IdentityServer 42

Hình 32: IdentityServer xác thực người dùng 43

Hình 33: IdentityServer yêu cầu người dùng xác nhận để chia sẻ thông tin với client 43

Hình 34: IdentityServer chuyển hướng người dùng đến client với một mã xác thực 44

Hình 35: Client gửi mã xác thực và yêu cầu access token 44

Hình 36: Client dùng access token để yêu cầu các dịch vụ 45

Hình 37: Đăng nhập client 46

Hình 38: Đăng nhập user/pass 46

Hình 39: Lựa chọn các dịch vụ 47

Hình 40: Kết quả lựa chọn dịch vụ 47

Hình 41: Lựa chọn đăng nhập bằng database chứa CSDL người dùng 48

Hình 42: Đăng nhập bằng Microsoft 49

Hình 43: Xác nhân để chia sẻ thông tin 50

Hình 44: Lựa chọn dịch vụ 50

DANH MỤC KÝ HIỆU, CÁC CHỮ VIẾT TẮT

Từ viết tắt Nghĩa tiếng Anh Nghĩa tiếng Việt

SSO Single sign-on Hệ thống đăng nhập một lần

IdP Identity Provider

Thành phần chịu trách nhiệm

về quy trình xác thực và xử lý việc lưu trữ thông tin người dùng dưới dạng các thuộc tính trong mã thông báo nhận dạng

API Application Programming

Interface Giao diện lập trình ứng dụng SPA Single-page application Ứng dụng đơn trang

CHƯƠNG 1 MỞ ĐẦU

1 Đặt vấn đề

Trong thời gian gần đây với sự phát triển của ngành Công nghệ thông tin,

xu hướng các dịch vụ cùng nhau chia sẻ dữ liệu người dùng đang là hướng phát triển chung Thực tế một người dùng quản lý rất nhiều tài khoản, mật khẩu cho các dịch vụ, ứng dụng mà họ tham gia Việc người dùng quản lí các thông tin tài khoản và sử dụng sẽ nảy sinh các vấn đề không đảm bảo tính an ninh, an toàn và phát sinh thêm những nghiệp vụ khác

Hệ thống phần mềm ứng dụng ngành Thuế được chia thành 4 hệ thống phần mềm ứng dụng chính như sau:

a) Hệ thống ứng dụng phục vụ công tác nội bộ của ngành bao gồm các ứng dụng về quản lý công văn, …

b) Hệ thống ứng dụng hỗ trợ Người nộp thuế bao gồm các ứng dụng về kê khai thuế qua mạng, nộp thuế điện tử, quyết toán thuế thu nhập cá nhân online,

Do vậy nhu cầu đăng nhập một lần cho các ứng dụng và dịch vụ này là cần thiết Cơ chế SSO cho các ứng dụng và dịch vụ này là cấp thiết Cơ chế SSO đảm bảo cho người dùng hợp pháp có thể truy cập và một hệ thống hay nhiều hệ thống kết nối với nhau, chỉ phải sử dụng một tài khoản duy nhất SSO cho phép người dùng đăng nhập vào một hệ thống, họ sẽ đăng nhập vào tất cả các hệ thống liên quan

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

Với sự phát triển bùng nổ của nghành Công nghệ thông tin, các dịch vụ phát triển mạnh Nhu cầu đăng nhập một lần – SSO là cấp thiết khi vấn đề về bảo

mật, dữ liệu cá nhân ngày càng được quan tâm Người dùng được cấp quyền truy cập hệ thống, nhưng cũng có thể bị thu hồi mọi quyền truy cập trái phép ở tương lai và họ không cần cung cấp mật khẩu của họ Người dùng được quyết định việc cho phép cấp quyền truy cập vào dữ liệu cá nhân mỗi khi ứng dụng thứ 3 có nhu cầu Có nhiều giao thức, giải pháp, kỹ thuật cho phép xây dựng hệ thống SSO Các giải pháp này có những ưu điểm, nhược điểm, phù hợp với những nhu cầu, nghiệp vụ riêng Tuy vậy các giải pháp cũng đã giải quyết được bài toán xây dựng hệ thống SSO Trong đó, IdentityServer 4 là một giải pháp mã nguồn mở phổ biến cho hệ thống SSO Trong luận văn này, tôi thử nghiệm giải pháp SSO

sử dụng IdentityServer4 Phương pháp nghiên cứu sử dụng trong luận văn là phương pháp nghiên cứu lý thuyết và kếp hợp với phương pháp triển khai thực nghiệm Để có thể làm được thì tác giả phải thu thập 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 sau sẽ mô tả về SSO, cũng như giải pháp sử dụng IdentityServer 4 xây dựng hệ thống SSO

3 Bố cục luận văn

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

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

CHƯƠNG 2 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 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.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

2.1.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: K iế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

 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

 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

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.v (ví dụ: Trình quản lý thông tin Windows)

+ 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)

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

2.1.5.1 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

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.1.5.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]

a) Các thành phần của OpenID Connect

Hình 7: Các thành phần của OpenID Connect [4]

 Người dùng muốn truy cập vào một dịch vụ của ứng dụng Do đó, người dùng cung cấp thông tin xác thực cho ứng dụng Ngoài ra, người dùng có thể phân quyền cho ứng dụng có thể truy cập tài nguyên của mình thông qua các thông tin ở tên của người dùng

 Ứng dụng được ủy quyền để xác thực người dùng Ứng dụng có thể yêu cầu mã xác thực (ID token) (bao gồm xác thực của người dùng) và mã truy cập (access token) (nếu có) để truy cập các tài nguyên được bảo vệ của người dùng

 OpenID Provider: sinh ra ID token (bao gồm các thông tin của người dùng) và access token (nếu có)

b) Các luồng xử lý của OpenID Connect

 Luồng phân quyền (Authorization Code Flow)

Hình 8: Hoạt động của Luồng mã ủy quyền

+ Luồng mã ủy quyền hoạt động như sau:

 Ứng dụng khách gửi yêu cầu xác thực đến Điểm cuối cấp phép

 Điểm cuối ủy quyền xác thực người dùng và nhận được sự đồng ý của người dùng để chia sẻ thông tin phạm vi được yêu cầu với Khách hàng

 Điểm cuối ủy quyền chuyển hướng người dùng đến Máy khách cùng với mã ủy quyền

 Khách hàng gửi mã ủy quyền đến Token Endpoint và yêu cầu Access Token

 Token Endpoint cho phép yêu cầu và tạo Access Token và ID Token

Nó cũng tạo Mã làm mới, nếu được định cấu hình

 Khách hàng gửi Mã truy cập đến Điểm cuối UserInfo

 UserInfo Endpoint xác thực yêu cầu và trả về xác nhận quyền sở hữu về người dùng

+ Điểm cuối ủy quyền: Điểm cuối ủy quyền xác thực và ủy quyền cho người dùng bằng cách sử dụng yêu cầu xác thực máy khách Điểm cuối xác thực người dùng để thiết lập danh tính của họ, cho phép người dùng, yêu cầu sự đồng

ý của họ và sau đó cấp cho họ quyền truy cập vào tài nguyên

+ Quy trình điểm cuối cấp phép: Máy chủ ủy quyền thực hiện các bước sau tại Điểm cuối ủy quyền:

 Ứng dụng khách gửi một yêu cầu xác thực ở định dạng được chỉ định đến Điểm cuối cấp phép

 Máy chủ ủy quyền tại Điểm cuối ủy quyền xác thực yêu cầu xác thực

và sử dụng các tham số yêu cầu để xác định xem người dùng đã được xác thực chưa

 Nếu người dùng không được xác thực, Máy chủ ủy quyền xác thực người dùng và khi xác thực thành công, nó sẽ chuyển hướng người dùng đến trang chấp thuận xác nhận xem thông tin phạm vi được yêu cầu có thể được chia

sẻ với Máy khách hay không

 Nếu người dùng đã được xác thực, Máy chủ ủy quyền sẽ chuyển hướng người dùng đến trang chấp thuận xác nhận xem thông tin phạm vi được yêu cầu

có thể được chia sẻ với Máy khách hay không

 Nếu người dùng nhấp vào Cho phép trên trang chấp thuận, Máy chủ Ủy quyền sẽ gửi phản hồi xác thực cùng với mã ủy quyền tới URI được chỉ định trong yêu cầu xác thực

 Nếu người dùng nhấp vào Từ chối trên trang chấp thuận hoặc xác thực không thành công, trình duyệt sẽ được chuyển hướng đến Ứng dụng khách với

mã lỗi tương ứng được thêm vào phản hồi xác thực Nếu redirect_URI không hợp lệ, trình duyệt sẽ không được chuyển hướng đến Máy khách

+ Các thông số được hỗ trợ:

 response_type: Xác định quy trình xử lý ủy quyền phải được sử dụng

 scope: Xác định phạm vi của yêu cầu truy cập Có thể chỉ định nhiều giá trị được phân tách bằng dấu cách

được mã hóa dưới dạng các giá trị biểu mẫu HTML, hãy chỉ định form_post làm giá trị trong yêu cầu xác thực

+ Các phương thức HTTP được hỗ trợ: Điểm cuối cấp phép hỗ trợ các phương thức GET và POST

 Đối với GET, yêu cầu ủy quyền chứa URL điểm cuối ủy quyền và các tham số truy vấn bắt buộc ở định dạng sau:

id=clientID_value&state=state_value

&redirect_uri=redirect_URL_value&nonce=nonce_value&code_challenge=code_challe nege_value&code_challenge_method=plain or S256 value

 Đối với POST, yêu cầu xác thực có định dạng sau:

https://authorization_endpoint_URL?response_type=code&scope=scope_value&client_ id=clientID_value&state=state_value&redirect_uri=redirect_URL_value&nonce=nonce _value&code_challenge=code_challenege_value&code_challenge_method=plain or S256 value

+ Điểm cuối mã thông báo (Token Endpoint): Máy chủ ủy quyền sử dụng

mã ủy quyền để tạo mã thông báo truy cập và nhận dạng Khách hàng gửi Mã ủy quyền trong một yêu cầu mã thông báo đến Điểm cuối mã thông báo bằng cách

sử dụng mã ủy quyền làm loại cấp_cấp Nếu loại máy khách là bí mật, máy khách phải xác thực tại Token Endpoint bằng phương pháp xác thực được chỉ định trong quá trình đăng ký máy khách

 Luồng ẩn (Implicit Flow)

+ Client gửi yêu cầu xác thực đến Authorization Server

+ Authorization Server xác thực người dùng Nếu người dùng được xác thực, Authorization Server sẽ gửi một ID token và một Access token (nếu có)

+ Client sử dụng ID token để truy cập thông tin người dùng

 Luồng lai (Hybrid Flow)

+ Client gửi yêu cầu xác thực đến Authorization Server;

+ Authorization Server xác thực người dùng Nếu người dùng được xác thực, Authirization Server gửi Authorization code và một vài thông số bổ sung;

+ Client sử dụng Authorization Code để lấy ID Token và Access token Client sử dụng ID Token để truy cập các thông tin của người dùng

2.1.5.3 SAML

Security Assertion Markup Language (SAML) là một giao thức phục vụ xác thực và phân quyền Sử dụng SAML, một service có thể liên hệ với một IdP

để xác thực người dùng muốn truy cập một nội dung bảo mật [4]

Luồng xử lý của giao thức SAML như sau:

Hình 9 : Sơ đồ luồng xử lý của giao thức SAML [4]

a) 1: Một client muốn sử dụng 1 dịch vụ

b) 2: Để truy câp dịch vụ, client gửi một tin nhắn đến IdP và máy chủ AS

để yêu cầu quyền truy câp ứng dụng

c) 3: IdP hoặc máy chủ AS yêu cầu client cung cấp thông tin đăng nhập d) 4: Client cung cấp thông tin đăng nhập cho IdP hoặc máy chủ AS

e) 5: Nếu thông tin đăng nhập là chính xác, IdP liên hệ với AS và yêu cầu truy cập các dữ liệu được truy cập

f) 6: AS gửi lại mã truy cập cho IdP

g) 7: IdP gửi thông tin về dịch vụ mà người dùng đã xác thực và một mã truy cập

h) 8: Người dùng đăng nhập vào dịch vụ và truy cập các dữ liệu được cho phép

2.1.5.4 LDAP

The Lightweight Directory Access Protocol (LDAP) là một giao thức sử dụng để truy cập các dịch vụ thư mục phân tán LDAP thường được kết hợp với một ative directory [4]

Hình 10 : Sơ đồ luồng xử lý của giao thức LDAP [4]

Giao thức LDAP bao gồm các client LDAP và một máy chủ LDAP LDAP client gửi một message chứa một yêu cầu về một thực thể nhất định và gửi đến máyc hủ Máy chủ xử lý yêu cầu này, tìm trong thư viện và thấy nhiều thực hteer.Các thực thể này được gửi đến client theo các message Mỗi message là thông tin về một thực thể

Việc xác thực sử dụng LDAP theo 2 cách:

a) Máy chủ 1 gửi đến máy chủ 2 các thông tin về người dùng được xác thực Máy chủ 2 sẽ chọn máy chủ 1 để xác thực các thông tin đăng nhập

b) Máy chủ 1 gửi các các thông tin xác thực người dùng đến máy chủ 2 Máy chủ 2 sẽ tự thực hiện việc xác thực người dùng

Hình 11 : Xác thực sử dụng LDAP [4]

2.1.5.5 CAS

Central Authentication Server (CAS) là một giao thức phục vụ việc SSO trên nền tảng web CAS là một giao thức mở có thể tương thích với các client viết bởi ngôn ngữ Java, Net, PHP, Perl, Apache, uPortal [4]

Giao thức CAS bao gồm hai thành phần máy chủ CAS và CAS client a) Máy chủ CAS là một máy đơn phục vụ việc xác thực Máy chủ này biết mật khẩu người dùng và thực hiện 2 nhiệm vụ:

 Xác thực người dùng;

 Truyền các thông tin của người dùng được xác thực tới CAS client Một phiên SSO bắt đầu khi máy chủ sinh ra một ticket cho phép đăng nhập sau khi người dùng xác thực thành công Một ticket dịch vụ được gửi tới dịch vụ sau khi nhận được một yêu cầu từ người dùng Client kiểm tra thông tin của ticket dịch vụ

b) CAS client là các nhà cung cấp dịch vụ sử dụng CAS và có thể kết nối với máy chủ

Hình 12 : Luồng xử lý của giao thức CAS [4]

2.1.6 So sánh các giao thức

2.1.6.1 Oauth2 và OpenID Connect

a) Oauth 2 chỉ phục vụ việc xác thực còn OpendID Connect có bổ sung thêm tính năng phân quyền;

b) OpenID Connect không có luống để chia sẻ dữ liệu giữa ứng dụng còn với Oauth2, bất kỳ thông tin của người dùng trên một website có thể chia sẻ với một website khác

2.1.6.2 OpenID Connect và SAML

a) OpenID Connect được sử dụng cho các ứng dụng web, ứng dụng gốc (native app) và các ứng dụng di động trong khi SAML chỉ sử dụng cho các ứng dụng web

b) OpenID Connect lấy người dùng làm trung tâm còn SAML lấy tổ chức làm trung tâm

c) Đối với SAML, bảo mật dữ liệu được thực hiện mức độ tin nhắn và sử dụng công nghệ XML để ký và mã hóa tin nhắn Bảo mật ở tầng giao vận có thể thực hiện với TLS Đối với OpenID Connect, bảo mật ở tầng giao vận là bắt buộc

2.1.6.3 OpenID Connect và LDAP

Cả OpenID Connect và LDAP đều sử dụng để xác thực và phân quyền LDAP là giải pháp hướng đến doanh nghiệp còn OpenID connect là giải pháp về web.LDAP chia sẻ thông tin về người dùng, hệ thống, kết nối mạng và các ứng dụng bên trong một mạng.Với LDAP, các dữ liệu người dùng được lưu trong một thư viện có chứa các tài khoản người dùng OpenID Connect không làm việc trực tiếp với thư viện hay cơ sở dữ liệu mà yêu cầu một dịch vụ riêng biẹt để xác thực người dùng

2.1.6.4 OpendID Connect vs CAS

CAS sử dụng để xác thực SSO đối với người dùng nội bộ còn OpenID Connect có thể sử dụng cả cho việc xác thực liên đoàn

2.1.7 Một số giải pháp SSO hiện nay

2.1.7.1 CAS / Central Authentication Service

 Nhà phát triển: Apereo

 Loại hình: miễn phí & mã nguồn mở (Apache 2.0)

 Mô tả: Giao thức và triển khai máy chủ / máy khách SSO nguồn mở với

sự hỗ trợ cho các giao thức CAS, SAML1, SAML2, OAuth2, SCIM, OpenID Connect và WS-Fed với tư cách là nhà cung cấp nhận dạng và nhà cung cấp dịch

vụ với các chức năng phụ trợ khác có sự đồng ý của người dùng, truy cập quản

lý, mạo danh, điều khoản sử dụng, v.v Được cấp phép theo Apache 2.0

 Central Authentication Service (CAS) là một mã nguồn mở cung cấp giải pháp SSO được phát triển bởi đại học Yale từ 12/2004 Giao thức CAS bao gồm ít nhất 3 bên: Trình duyệt Web của Client, các ứng dụng Web yêu cầu chứng thực, máy chủ CAS

b) Nhược điểm

 Chi phí để xây dựng hệ thống SSO với giải pháp CAS cao do được viết bởi ngôn ngữ Java

 Việc phát triển ở Client phụ thuộc vào thư viện được cung cấp do vậy khiến cho việc cập nhật, phát triển khá là khó khăn Việc cập nhật nghiệp vụ, thư viện cho toàn bộ các Client kết nối mỗi khi muốn scale hệ thống khá là khó khăn

và có chi phí cao Vì vậy giải pháp không phù hợp với những hệ thống nặng về nghiệp vụ, việc cập nhật, bổ sung nghiệp vụ diễn ra thường xuyên

2.1.7.2 Active Directory Federation Services:

 Mô tả: Facebook SSO cho các bên thứ ba được Facebook kích hoạt

 Facebook Connect là một Closesource cung cấp giải pháp SSO của Facebook được ra đời vào 12/2008 Giải pháp cho phép người dùng đăng nhập vào các trang web, ứng dụng hoặc thiết bị của bên thứ 3 bằng cách sử dụng tài khoản facebook

 Khi người dùng cho phép, ứng dụng 3 được phép truy cập thông tin cá nhân trên facebook: Họ tên, hình ảnh, bài viết, thông tin bạn bè

a) Ưu điểm

 Giải pháp có độ an toàn, bảo mật cao vì được phát triển bởi Facebook

 Với việc Client hỗ trợ các thư viện đa nền tảng (Android, Web ), đa ngôn

 ngữ (Java, PHP, JS ) khiến cho việc tích hợp với hệ thống Facebook nhanh chóng và đơn giản

 Cộng đồng người sử dụng đông đảo (2,234 tỷ người dùng tính đến hết quý 1/2018)

 Giải pháp phù hợp với mục tiêu tích hợp SSO cho những hệ thống muốn giảm bớt các nghiệp vụ liên quan đến người dùng, mong muốn có một giải

b) Nhược điểm

 Facebook Connect là một giải pháp SSO tốt được phát triển bởi Facebook Tuy nhiên do là một mã nguồn đóng, chỉ cung cấp giải pháp tích hợp cho bên thứ 3 khiến cho việc mở rộng hệ thống khá là khó khăn Sự phụ thuộc hoàn toàn vào giải pháp, chính sách của Facebook cũng là một rào cản lớn Do vậy Facebook Connect không phải là một sự lựa chọn hàng đầu với mục tiêu xây dựng, phát triển một hệ thống SSO cả 2 phía Server và Client

2.1.8 Keycloak (Red Hat Single Sign-On):

 Nhà phát triển: Red Hat

 Loại hình: mã nguồn mở

 Mô tả: SSO được liên kết (LDAP và Active Directory), các giao thức chuẩn (OpenID Connect, OAuth 2.0 và SAML 2.0) cho Web, phân cụm và đăng nhập một lần Đăng nhập một lần của Red Hat là phiên bản của Keycloak mà RedHat cung cấp hỗ trợ thương mại

2.1.8.4 WSO2 Identity Server

 Nhà phát triển WSO2

 Loại hình: Free & Open Source (Apache 2.0)

 Mô tả: SAML 2.0, OpenID, OpenID Connect, OAuth 2.0, SCIM, XACML, Passive Federation

2.1.9 Lợi ích của SSO

SSO mang lại các lợi ích như sau:

a) Giảm thời gian người dùng thực hiện trong các hoạt động đăng nhập vào các tên miền riêng lẻ, bao gồm giảm khả năng các hoạt động đăng nhập đó không thành công

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) Cải thiện bảo mật thông qua nâng cao kỹ năng của quản trị viên hệ thống để duy trì tính toàn vẹn của tài khoản người dùng

d) Bảo mật trên tất cả các cấp đăng nhập, thoát, truy cập vào hệ thống mà không gây bất tiện cho người dùng nhắc lại

e) Các nhà phát triển ứng dụng không phải thực hiện việc bảo mật danh tính trong ứng dụng của họ