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

LUẬN VĂN THẠC SĨ
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Ơ MINH CƯỜNG
Ngành: Cơng nghệ thơng tin

Giảng viên hướng dẫn: TS. Trần Hồ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

LUẬN VĂN THẠC SĨ
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Ơ MINH CƯỜNG
Ngành: Cơng nghệ thơng tin

Giảng viên hướng dẫn:

TS. Trần Hồng Hải
Chữ ký của GVHD

Viện:

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

HÀ NỘI, 2020


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

Bổ sung kiến thức về SSO


2.1.2, 2.1.3,2.1.4

13-18

2.2

29

2

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

4.4

48-52

3

Mô tả cơ chế xác thực của
IdentityServer

4.5

55-57

4

Mô tả cơ chế tích hợp SSO

vào các ứng dụng khác

1

5
6

Bố cục lại các chương
Lỗi chính tả
Ngày

Giáo viên hướng dẫn

tháng

năm 2020

Tác giả luận văn

CHỦ TỊCH HỘI ĐỒNG


LỜI CẢM ƠN
Đầu tiên, tôi xin được gửi lời cảm ơn sâu sắc nhất tới TS Trần Hồng Hải,
Phó Giám đốc, Trung tâm Mạng thông tin và là giảng viên bộ mơn Truyền thơng
và Mạng máy tính, Viện Cơng nghệ thông tin và Truyền thông, Trường Đại học
Bách Khoa Hà Nội đã hướng dẫn và cho tôi những lời khuyên trong q trình thực
hiện luận văn này. Tiếp theo, tơi xin chân thành cảm ơn các thầy cô trong Viện
Công nghệ thông tin và truyền thông, Viện đào tạo sau đại học, Trường Đại học
Bách Khoa Hà Nội đã tạo điều kiện cho tơi trong suốt q trình học tập và nghiên

cứu tại trường. Cuối cùng, tôi xin bày tỏ lịng cảm ơn tới những người thân trong
gia đình, bạn bè đã động viên và giúp đỡ để tơi hồn thành bản luận văn này.
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 Hồ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 tồ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 ngồ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à
dịch vụ này là cần thiết. Cơ chế Single sign-on (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. 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.
4. Kết luận

Hệ thống Single sign-on sử dụng OAuth2 đáp ứng được lý do, mục đích
nghiên cứu
Hà Nội, ngày … tháng … năm 2020
Tác giả LVThS

Ngô Minh Cường


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

i


4.1.1 Mơ hình triển khai .......................................................................... 36
4.1.2 Ngun 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

ii



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
iii


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

iv


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
Thành phần chịu trách nhiệm
về quy trình xác thực và xử lý

IdP

Identity Provider

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
SPA

Application Programming
Interface
Single-page application

Giao diện lập trình ứng dụng
Ứng dụng đơn trang


v


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 tồ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,
…
c) Hệ thống ứng dụng trao đổi thơng tin với bên ngồ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, ..,
d) 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 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
1


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 tố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.

2


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.

3


2.1.2 Ngun lý hoạt động của Single sign-on
Mơ hình ngun 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.

4


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: 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.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

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 q 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 tồ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 tồ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)


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

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

10


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. Ngồ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)


11


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:

12


 Ứ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 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
 client_id: Xác định ID khách hàng
 redirect_uri: Chỉ định URI mà phản hồi xác thực phải được gửi đến.
Giá trị này phải là URI đã được chỉ định trong quá trình đăng ký khách hàng
 response_mode: Chỉ định xem phản hồi xác thực cho redirect_uri phải
được gửi dưới dạng tham số truy vấn hay được mã hóa dưới dạng giá trị biểu
mẫu HTML được gửi trong phương thức POST. Theo mặc định, Luồng mã ủy
quyền sử dụng truy vấn làm chế độ phản hồi. Để gửi phản hồi ở định dạng truy
vấn, bạn không cần gửi tham số này trong yêu cầu xác thực. Để gửi phản hồi


13


đượ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:
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_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.

14