I tổng quát về công nghệ single sign-on

1.1 các khái niệm cơ bản

1.1.1 công nghệ single sign-on
Single Sign-On, đúng như tên gọi, là cơ chế cho phép người dùng
có thể truy cập nhiều trang web, ứng dụng mà chỉ cần đăng nhập
một lần. Một khi đã được định danh ở một trang website A, thì
cũng sẽ được định danh tương tự ở website B mà không cần lặp
lại thao tác đăng nhập
1.1.2 định danh
Định danh là thông tin gắn cho một cá nhân hoặc một tổ chức (thường là tên
hoặc một dãy số), giúp lưu trữ, truy xuất và xác định các thông tin của cá nhân
đó một các nhanh nhất. Việc này tương tự với mỗi người có một chứng minh
nhân dân hoặc căn cước công dân, trên đó có một mã số định danh ứng với cá
nhân đó. Từ đó, ta thấy định danh là một phần rất quan trọng để xác định
đúng các đối tượng sẽ truy cập vào trong hệ thống. Chẳng hạn như mỗi người
sẽ có một số chứng minh nhân dân, căn cước công dân hoặc là thẻ bảo hiểm y
tế. Chuỗi số đó được gọi là định danh
Định danh là một khái niệm rất phổ biến trong các hệ thống thông tin ngày
nay. Khả năng xác định được các đối tượng đang tương tác với hệ thống sẽ
đảm bảo độ an toàn một cách đáng kể đối với một hệ thống hay một ứng
dụng. Việc này đảm bảo chỉ những cá nhân hợp lệ được hệ thống nhận diện
danh tính mới có thể truy cập vào trong hệ thống. Mặt khác, định danh cũng
hỗ trợ trong quá trình xử lý sự cố, nếu có bất kỳ vấn đề bất thường nào xảy ra
với hệ thống, việc xác định chính xác danh tính những cá nhân đã tác động lên
hệ thống sẽ giúp đỡ phần nào trong việc điều tra giải quyết sự cố đó. Ngày
nay, việc định danh người dùng không chỉ dựa vào một ID mà họ được hệ
thống cung cấp mà có thể dựa trên các thông tin cá nhân khác như địa chỉ
email hay số điện thoại… Đối với một số hệ thống nâng cao còn có thể nhận
diện khuôn mặt hay các yếu tố sinh trắc của con người.

1.1.3 xác thực

 Xác thực là quá trình xác minh tính hợp lệ của người dùng hoặc một thực
thể nào đó. Việc xác minh này phòng tránh việc giả danh người dùng hợp lệ để có
quyền truy cập trái phép đến tài nguyên mạng với mục đích xấu. Xác thực rất
quan trọng bởi vì khi kẻ giả danh thành công thì việc bảo vệ tài nguyên mạng của
tổ chức là rất mong manh. Hậu quả của việc giả danh này sẽ rất trầm trọng, thậm
chí phá vỡ hoàn toàn các tài nguyên mạng và các hệ thống mạng đang hoạt động.

Việc xác thực là một quá trình tiên quyết để kiểm tra danh tính một tài
khoản đang yêu cầu đăng nhập vào hệ thống hiện tại thông qua một hệ thống xác
thực. Đây chính là bước đầu của hệ thống để nắm được các yếu tố của người
dùng. Xác thực còn là một quy trình nhằm cố gắng xác minh nhận dạng số của
phía truyền gửi thông tin trong giao dịch liên lạc chẳng hạn như một yêu cầu đăng
nhập. Phía gửi cần phải xác thực có thể là một người dùng sử dụng một máy tính,
bản thân một máy tính hoặc một chương trình ứng dụng máy tính.

Sau khi người dùng được xác thực, một phiên làm việc được tạo ra và tham
chiếu trong quá trình tương tác giữa người dùng và hệ thống ứng dụng cho đến
khi người dùng đăng xuất hoặc phiên làm việc đó bị kết thúc. Thông thường, xác
thực có hình thức cung cấp một tập hợp các thông tin xác thực, chẳng hạn ID
người dùng và mật khẩu được sử dụng. Bằng cách duy trì phiên của người dùng
một cách tập trung, hệ thống có thể cung cấp dịch vụ Đăng nhập một lần (Single-
Sign-On) để người dùng không cần đăng nhập lại khi truy cập vào hệ thống ứng
dụng hoặc tài nguyên khác được quản lý theo cùng một hệ thống xác thực tập
trung.

Để có thể xác thực được các đối tượng, việc đầu tiên là tập hợp danh tính
của các thực thể và ánh xạ chính xác vào tập hợp thực thể đó. Giống như quá
trình ánh xạ tập hợp các tên người vào một tập hợp người dùng cụ thể. Quá trình
tương tác với các tài nguyên mạng thường được tiến hành thông qua danh tính
của các thực thể mà không phải là trực tiếp với các thực thể. Chính vì vậy, xác
thực thực thể phải đảm bảo danh tính của đối tượng không thể bị mạo danh bởi
bất kỳ thực thể nào khác. Muốn làm được như vậy, mỗi danh tính của thực thể
phải cung cấp các nhân tố đặc trưng của thực thể đó mà không đặc trưng cho bất
kỳ thực thể nào khác.

Ngoài ra, để tăng độ bảo mật cho hệ thống, các ứng dụng hiện nay đều
triển khai xác thực nhiều lớp (thường là hai lớp). Đây là phương thức yêu cầu
nhiều hơn một yếu tố xác thực từ người dùng. Nếu một tài khoản không được xác
thực hai lớp, người dùng đơn giản chỉ cần nhập username và password là có thể
đăng nhập vào tài khoản. Với bảo mật hai lớp, thay vì lập tức có quyền truy cập,
họ sẽ được yêu cầu cung cấp thêm một thông tin khác. Yếu tố xác thực thứ hai
này có thể là một trong các loại thông tin sau:

 Những gì người dùng biết: có thể là mã PIN (Personal Identification

Number), password, câu trả lời cho các “câu hỏi bí mật”.
 Những gì người dùng có: chẳng hạn như Credit card, Smartphone
hoặc Smart Card.
 Những gì thuộc về người dùng: loại thông tin này cao cấp hơn hai loại
trước, và có thể là dữ liệu sinh trắc học như dấu vân tay, quét mống
mắt hoặc nhận diện giọng nói.

Dù có một chút rắc rối nhưng việc sử dụng bảo mật hai lớp sẽ giúp nâng cao
tính bảo mật cho các tài khoản trực tuyến, khiến các nỗ lực giả mạo một tài khoản
nào đó của bọn tội phạm trở nên khó khăn hơn nhiều.

1.1.4 ủy quyền

Ủy quyền quá trình xác định liệu người dùng có được phép truy cập vào
một tài nguyên cụ thể hay không. Việc ủy quyền được thực hiện bằng cách phân
tích các yêu cầu truy cập (chẳng hạn như mã định danh hoặc URI trong ứng dụng
dựa trên web), dựa trên các chính sách được xác định trước và được lưu trữ
trong kho chính sách chung. Ủy quyền là lĩnh vực cốt lõi thực hiện kiểm soát truy
cập dựa trên vai trò (RBAC). Hơn nữa, mô hình ủy quyền có thể cung cấp các kiểm
soát truy cập phức tạp dựa trên dữ liệu, thông tin hoặc chính sách bao gồm thuộc
tính người dùng như nhóm, vai trò người dùng, bản chất của hành động được
thực hiện, thời gian, loại tài nguyên, chính sách bảo mật, tuân thủ và các yêu cầu
quy định, v.v. để xác định mức độ tiếp cận hệ thống được cho phép đối với mỗi
người dùng khác nhau.

Kiểm soát truy cập dựa trên vai trò (RBAC) hạn chế truy cập mạng dựa trên
vai trò của một người trong tổ chức và đã trở thành một trong những phương
pháp chính để kiểm soát truy cập nâng cao. Các vai trò trong RBAC đề cập đến các
cấp độ truy cập mà nhân viên có vào mạng.

Nhân viên chỉ được phép truy cập thông tin cần thiết để thực hiện hiệu quả
nhiệm vụ công việc của họ. Quyền truy cập có thể dựa trên một số yếu tố, chẳng
hạn như quyền hạn, trách nhiệm và năng lực công việc. Ngoài ra, quyền truy cập
vào tài nguyên máy tính có thể bị giới hạn trong các tác vụ cụ thể như khả năng
xem, tạo hoặc sửa đổi tệp.

Do đó, nhân viên cấp dưới thường không có quyền truy cập vào dữ liệu
nhạy cảm nếu họ không cần nó để hoàn thành trách nhiệm của mình. Điều này
đặc biệt hữu ích nếu công ty có nhiều nhân viên và sử dụng bên thứ ba và nhà
thầu gây khó khăn trong việc giám sát chặt chẽ việc truy cập mạng. Sử dụng RBAC
sẽ giúp bảo mật dữ liệu nhạy cảm và các ứng dụng quan trọng của cơ quan.

Hầu hết các hệ thống RBAC được dựa trên việc áp dụng ba nguyên tắc cơ
bản. Các nguyên tắc này được áp dụng như thế nào trong các tổ chức riêng lẻ có
thể khác nhau, nhưng những nguyên tắc này vẫn không thể thay đổi:

 Phân công vai trò: Một chủ thề chỉ có thể thực hiện quyền nếu chủ thề đã
chọn hoặc được gán một vai trò.
 Ủy quyền vai trò: Vai trò chính xác của chủ thể phải được ủy quyền. Đó là,
tôi không thể chỉ định bản thân mình cho một vai trò. Tôi cần sự cho phép.
 Cho phép: Một chủ thề chỉ có thể thực hiện quyền nếu sự cho phép được
ủy quyền cho vai trò hoạt động của chủ thề. Với quy tắc 1 và 2, quy tắc này
đảm bảo rằng người dùng chỉ có thể thực hiện các quyền mà họ được ủy
quyền.

1.2 cơ chế đăng nhập một lần

1.2.1 tổng quan về đăng nhập một lần
Đăng nhập một lần (SSO) là một cơ chế xác thực cho phép người dùng đăng
nhập vào hệ thống với chỉ một lần và chỉ cần một tài khoản và mật khẩu để
truy cập vào nhiều ứng dụng khác nhau trong một phiên làm việc (session).
Trước khi có SSO, mỗi người sử dụng có một tài khoản đối với mỗi ứng dụng
và họ cần phải nhập các tài khoản và mật khẩu đó cho từng ứng dụng mỗi khi
họ đăng nhập vào các ứng dụng đó hoặc các hệ thống khác nhau trong cùng
một phiên. Điều này rõ ràng làm tốn thời gian và gây ra sự khó chịu với trải
nghiệm của người dùng. Đặc biệt là trong môi trường thông tin đa phương tiện
như hiện nay, khi mà người sử dụng phải đăng nhập lại mỗi khi họ truy cập vào
một ứng dụng mới. Đăng nhập Một lần không yêu cầu người dùng nhập lại
thông tin xác thực để chuyển đổi các ứng dụng trong cùng một tổ chức do vậy
tạo sự thuận tiện cho người dùng cũng như tăng khả năng bảo mật.
Hiểu cách đơn giản 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 một phiên làm việc (session).
Đăng nhập một lần đưa ra khái niệm cho phép kiểm soát truy cập vào các hệ
thống độc lập. Phương pháp này cho phép người dùng xác thực một lần và có
quyền truy cập vào tất cả các hệ thống mà không cần đăng nhập mới. Quy
trình đảo ngược của hệ thống Đăng nhập Một lần là Tắt Đăng nhập Một lần.
Nó thực hiện một thủ tục đăng xuất trong đó người dùng sẽ mất mọi quyền
truy cập vào tất cả các hệ thống.
Các cấu hình Đăng nhập một lần phổ biến nhất liên quan đến việc sử dụng Thẻ
thông minh, mã thông báo OTP và phần mềm như CAS, Shibboleth và
Kerberos, v.v.
Trong nền tảng đăng nhập một lần, người dùng thực hiện một lần đăng
nhập ban đầu (đăng nhập chính) vào một ứng dụng mà họ muốn truy cập. Sau
này, mỗi khi anh ta muốn truy cập vào một ứng dụng khác trong cùng tổ chức,
nó sẽ tự động xác minh rằng anh ta đã được xác thực đúng cách mà không yêu
cầu bất kỳ tương tác trực tiếp nào khác của người dùng đó. Một giải pháp
đăng nhập một lần được thiết kế và triển khai tốt làm giảm đáng kể cơ sở hạ
tầng xác thực và độ phức tạp của quản lý danh tính, do đó giảm chi phí trong
khi tăng cường bảo mật.
Đăng nhập một lần cho phép người dùng truy cập các miền bảo mật phụ khác
sau khi đăng nhập vào miền chính. Giữa các miền này tồn tại một mối quan hệ
tin cậy. Do đó, miền thứ hai có được thông tin đăng nhập của người dùng
thông qua dịch vụ đăng nhập từ miền chính nơi người dùng đã được xác thực.
Nói cách khác, miền bảo mật chính hỗ trợ các miền khác bằng thông tin đăng
nhập của người dùng giả định rằng người dùng đã đăng nhập chính xác

2 Hình 1.1 Trước và sau khi có SSO

 Trước khi có đăng nhập một lần, một người sử dụng đã phải nhập các tài
khoản và mật khẩu cho từng ứng dụng mỗi khi họ đăng nhập vào các ứng dụng
khác nhau hoặc các hệ thống trong cùng một phiên (session). Điều này thực sự
mang lại sự thuận tiện và tiết kiệm thời gian cho người dùng khi không phải
đăng kí bất kì tài khoản nào khác nữa cũng như không phải đăng nhập nhiều
lần để sử dụng các dịch vụ đó

2.1.1 cách thức hoạt động

Trong thế giới hiện tại, người dùng thường phải đăng nhập vào nhiều hệ
thống ứng dụng bằng các bộ thông tin xác thực khác nhau. Do đó người dùng
thường có rất nhiêu bộ tên đăng nhập và mật khẩu khác nhau và cũng rất khó
nhớ các thông tin này khi số lượng ứng dụng dịch vụ ngày càng tăng lên. Họ có xu
hướng dễ dàng quên những thông tin này và thực hiện các cuộc gọi đến bộ phận
trợ giúp để yêu cầu thiết lập lại tài khoản. Người quản trị hệ thống cũng gặp khó
khăn khi mà có một lượng lớn quy trình làm việc liên quan đến việc tạo mới và
quản lý tài khoản người dùng. Quản trị viên phải quản lý các tài khoản của người
dùng này để chúng được truy cập một cách đồng bộ mà không ảnh hưởng đến
tính toàn vẹn của các chính sách bảo mật.

Hệ thống Đăng nhập Một lần là một giải pháp để vượt qua các khó khăn
trên. SSO có vai trò đảm bảo cho người người dùng nhập thông tin đăng nhập của
mình một lần và thực hiện xác thực một lần duy nhất để người dùng có quyền
truy cập vào nhiều ứng dụng khách nhau. Điều này giúp loại bỏ nhu cầu ghi nhớ
nhiều tổ hợp tên người dùng, mật khẩu và do đó làm cho cả người dùng và quản
trị viên trở nên dễ dàng hơn.

Trước tiên, ta sẽ xem xét qua bài toán ban đầu khi các ứng dụng được triển
khai mà không có Single Sign On như sau:
 Hình 1.2 Mô hình xác thực khi chưa có SSO
Ở đây, em xin lấy ví dụ về hai hệ thống ứng dụng mà Văn phòng Trung ương
Đảng đã triển khai đó là Hệ điều hành tác nghiệp và Hệ thống Email. Hai hệ thống
ứng dụng này hiện tại đang chạy độc lập với nhau. Việc định danh và xác thức
người dùng của hệ thống cũng tách biệt và do mỗi ứng dụng tự thực hiện.

Yêu cầu hiện tại là người dùng khi truy cập vào Hệ điều hành tác nghiệp qua
trình duyệt web, người dùng được định danh, xác thực và phân quyền để sử dụng
hệ thống này. Sau đó, khi người dùng chuyển sang sử dụng Hệ thống Email, Hệ
thống Email có thể lấy được những thông tin đăng nhập mà người dùng đã dùng
để đăng nhập tại Hệ điều hành tác nghiệp để đăng nhập.

Giải pháp để thực hiện được yêu cầu trên chính là chia sẻ thông tin session
giữa các domain, những thông tin này có thể được lưu trong cookie của trình
duyệt. Hệ điều hành tác nghiệp có thể chia sẻ thông tin định danh người dùng cho
Hệ thống Email dùng để đăng nhập vào hệ thống này. Tuy nhiên, các trình duyệt
hiện này thì domain chỉ truy cập được chính cookie do nó tạo mà không thể truy
cập cookie do domain khác tạo ra bởi vì các trình duyệt cần phải tuân theo chính
sách “Same Origin Policy”.

Same Origin Policy có thể gọi là chính sách cùng nguồn gốc được đưa ra bởi
Netscape vào năm 1995 cùng với Javascript và Document Object Model (DOM),
chỉ một năm sau khi tạo ra HTTP cookies. Về cơ bản, đây là một chính sách quy
định nội dung từ một website chỉ có thể được đọc và thay đổi bởi một thành phần
khác cùng website đấy, trường hợp truy cập nằm ngoài phạm vi của website sẽ bị
chặn. Same-Origin Policy thực chất là một thỏa thuận giữa các đơn vị xây dựng
trình duyệt nhằm xây dựng một chuẩn hạn chế các chức năng trong các dòng lệnh
được thực thi trên trình duyệt của người dùng. Một cách ngắn gọn, Same-Origin
Policy biểu trưng cho việc khi một người dùng xem nội dung một trang web trên
trình duyệt của họ, các đoạn mã chạy trên trang web đó sẽ chỉ có thể được đọc
hoặc định nghĩa nội dung của một trang web khác nếu chúng có cùng một “nguồn
gốc - Origin”. Và nguồn gốc ở đây được hiểu là sự kết hợp của cả 3 yếu tố: giao
thức ứng dụng web (như HTTP hay HTTPS), cổng giao tiếp (thường là port 80 với
HTTP và port 443 với HTTPS), và tên miền (www.google.com,
www.facebook.com...). Nếu không có Same-Origin Policy, khi người dùng vô tình
truy cập một trang web độc hại, script được đặt sẵn trên này có thể truy cập được
dữ liệu và sử dụng các tính năng của bất kỳ trang web nào người dùng đã dùng
trước đó. Chẳng hạn như việc thực hiện chuyển tiền, đọc nội dung email hay chụp
ảnh thẻ tín dụng khi giao dịch trực tuyến. Vì lý do này, các trình duyệt bắt buộc
phải áp dụng Same-Origin Policy để ngăn chặn tương tác giữa các domain khác
nhau. Việc đó được thể hiện qua mô hình sau:
 Hình 1.3 Mô hình xác thực phải tuân thủ chính sách Same-Origin Policy
Vậy nên, dựa trên cơ sở của Same-Origin Policy, domain Hệ thống Email
không thể truy cập khai thác các cookie từ domain Hệ điều hành tác nghiệp và
ngược lại. Đây chính là vấn đề mà SSO giải quyết, SSO phải có nhiệm vụ chia sẻ
thông tin cookie giữa các domain với nhau. Mỗi giao thức SSO chia sẻ thông tin
của phiên (session) theo nhiều cách khác nhau, nhưng những đặc điểm cơ bản thì
giống nhau. Đó là: có một domain trung tâm (central domain) để thực hiện xác
thực (authentication) và sau đó session được chia sẻ với các domain khác theo
nhiều cách. Ví dụ, central domain có thể tạo một JSON Web Token đã được mã
hóa. Khi người dung truy cập vào domain con thì sẽ được hướng đến domain
trung tâm này, và Token này được truyền trả lại, lưu ở trình duyệt người dùng và
được sử dụng để xác thực người dùng cho domain hiện tại. Sau đó nếu người
dung tiếp tục truy cập vào domain con khác thì tương tự sẽ được điều hướng đến
domain trung tâm, nhưng do lần này đã có token nên sẽ được định danh và việc
đăng nhập không cần thiết nữa. Token có thể được truyền tới domain gốc bằng
cách điều hướng và nó chứa tất cả các thông tin cần thiết để xác minh người dùng
cho domain đang yêu cầu xác thực. Khi token đã được truyền đi, thì nó không thể
bị chỉnh sửa bởi bất kỳ client nào.

Từ đó ta có mô hình xác thực khi tạo một máy chủ xác thực trung gian như
sau:
 Hình 1.4 Mô hình xác thực khi có SSO
Bất cứ khi nào người dùng tới một domain yêu cầu phải xác thực, anh ta hay
cô ta sẽ được chuyển đến domain xác thực (authentication domain). Nếu người
dùng đã đăng nhập tại domain xác thực, anh ta hay cô ta sẽ ngay lập tức được
chuyển hướng trở lại domain gốc với token để xác thực các request tiếp theo. Đây
chính là cách giúp người dùng chỉ phải đăng nhập một lần duy nhất, các lần đăng
nhập sau họ đã được cung cấp token để xác thực ngay lập tức mà không cần phải
đăng nhập và xác thực lại lần nữa.

Tất cả các thông tin ứng dụng của các domain sẽ được lưu trữ trong Cookie
của trình duyệt đang sử dụng.

Cuối cùng, hệ thống SSO hoàn chỉnh cơ bản sẽ xác thực theo các bước sau:
 Hình 1.5 Các bước xác thực khi có SSO
Giải thích cơ chế hoạt động mô hình SSO:

1. Người dùng sử dụng trình duyệt truy cập đăng nhập vào hệ điều hành
tác nghiệp.
2. Webserver Hệ điều hành tác nghiệp sẽ chuyển tiếp yêu cầu xác thực tới
server xác thực trung gian.
3. Người dùng sẽ thực hiện đăng nhập và server xác thực trung gian lấy
các thông tin được chuyển đến và định danh, xác thực người dùng.
4. Đăng nhập thành công sẽ lưu cookie (access token) vào local storage
trên trình duyệt.
5. Máy chủ xác thực gửi Token và chuyển hướng về hệ điều hành tác
nghiệp.
6. Server của Hệ điều hành tác nghiệp thấy token gửi về sẽ biết là xác thực
thành công và gửi accesstoken đến trình duyệt của người dùng.
7. Thông tin của hệ điều hành tác nghiệp được lưu vào cookie của trình
duyệt.
 8. Người dùng tiếp tục dùng trình duyệt truy cập đăng nhập vào hệ thống
Email.
9. Webserver Hệ thống Email sẽ chuyển tiếp yêu cầu xác thực tới server
xác thực trung gian.
10. Lúc này, server xác thực trung gian kiểm tra phiên đăng nhập hiện tại đã
thấy được xác thực.
11. Server xác thực trung gian sẽ gửi lại access token và chuyển hướng về
hệ thống Email.
12. Khi đã có access token này thì người dùng sẽ truy cập được vào hệ
thống Email.
13. Thông tin sử dụng hệ thống Email được lưu vào cookie của trình duyệt.

Thông qua các bước trên, có thể thấy Server xác thực trung gian đóng vai trò
việc điều phối quyền truy cập của người dùng giữa các ứng dụng. Khi người dùng
đã được quyền truy cập ở ứng dụng này thì sẽ có thể đăng nhập trực tiếp vào ứng
dụng khác cùng qua Server xác thực trung gian.

2.1.2 ưu điểm của hệ thống

Giảm thời gian hiển thị cho người dùng vì họ không còn phải đăng nhập vào
các ứng dụng khác nhau.
Cải thiện khả năng sử dụng bằng cách giảm số lượng thông tin tài khoản mà
người dùng phải nhớ.
Giúp cho người quản trị hệ thống có thể tiết kiệm thời gian trong việc tạo lập
hay loại bỏ người dùng trên hệ thống, cũng như việc thay đổi quyền hạn của
một hay một nhóm người dùng nào đó.
Tăng cường khả năng bảo mật cũng như tăng tính tiện lợi thông qua việc giúp
người sử dụng không cần nhớ nhiều thông tin đăng nhập (định danh và mật
khẩu).
Bảo mật ở tất cả các cấp độ truy cập vào hoặc thoát ra khỏi hệ thống mà
không cần nhắc lại người dùng một cách bất tiện.
 Đăng nhập một lần, giúp cho người dùng và quản trị viên trở nên dễ dàng hơn
nhiều trọng việc sử dụng và vận hành hệ thống, vì họ sẽ phải xử lý một danh
tính duy nhất cho mỗi người dùng.
Tiết kiệm thời gian khi khôi phục hoặc thay đổi mật khẩu cho người dùng.
Người phát triển hay lập trình viên ứng dụng không cần thiết phải hiểu và thực
hiện nhận dạng bảo mật trong ứng dụng của họ, điều họ cần làm là liên kết
đến một máy chủ định danh đã được bảo đảm về độ tin cậy, việc này giúp
những người dùng của họ có thể truy cập vào các dịch vụ khác có cùng liên kết
đến máy chủ đó như họ.
Tạo nên sự đồng bộ về quản lý người dùng giữa các dịch vụ và ứng dụng trong
cùng một hệ thống thông tin.

2.2 hệ thống quản lý định danh và xác thực tập trung

2.2.1 định danh và quản lý định danh

Hiện nay, Truy cập vào hệ thống mạng thông qua hạ tầng mạng là tất yếu cho
những hoạt động mạng hàng ngày của một hệ thống mạng. Tuy nhiên, việc quan
trọng hơn là làm sao cung cấp bảo mật cho việc truy cập thông qua việc cho phép
đúng người đúng thời điểm cập vào hệ thống. Do đó, bài toán quản lý định danh
là vô cùng cấp thiết.

Ví dụ, một công ty có 5 nhân viên truy xuất vào 5 hệ thống của công ty như
vậy thì chúng ta cần rất nhiều định danh để truy cập được. Đây cũng là thực trạng
của hạ tầng công nghệ thông tin của các công ty hiện nay. Điều này được thể hiện
thông qua sơ đồ sau:
 Hình 1.6 Công ty trước khi có quản lý định danh
Từ sơ đồ trên ta có thể chỉ ra những điểm yếu trong quản lý định danh như
sau:

 Có quá nhiều định danh trong tổ chức, chỉ riêng nhân viên bên phòng tài
chính tương ứng là có 3 cái định danh.
 Quyền hạn trong các hệ thống đó không thể quản lý được.
 Không có cơ chế giám sát, theo dõi hoặc kiểm toán khi có sự cố hay thất
thoát tài liệu hoặc tài sản của công ty.
 Nếu nhân viên phòng tài chính nghỉ việc, chúng ta muốn xóa nhân viên
đó khỏi hệ thống trong công ty thì cần phải thực hiện xóa từng hệ thống
trong công ty.
 Nếu công ty có mô hình lớn nhiều nhân viên và nhiều hệ thống thì người
quản trị sẽ gặp nhiều khó khăn, nhân viên sẽ khó khăn khi truy cập vào
nhiều hệ thống.

Để giải quyết các vấn đề trên, xây dựng một hệ thống quản lý định danh và
truy cập IAM - Identity and Access Management là rất phù hợp với môi trường các
tổ chức công nghệ hiện nay.
 Hình 1.7: Công ty sau khi có quản lý định danh
IAM nói theo kiểu thông thường đó là hệ thống quản lý các định danh (ID) và
cấp quyền truy cập đến các tài nguyên của hệ thống trong doanh nghiệp. Như
trong trường hợp này, giải pháp IAM sẽ:

 Nhóm các quyền hạn lại và lúc này ta chỉ có 1 định danh duy nhất trong
toàn bộ hệ thống.
 Việc quản lý các định danh này được thực hiện tập trung tại giải pháp
IAM chứ không phải đi tới từng hệ thống riêng lẻ để tạo hay xóa các
user.
 Vấn đề cốt lõi ở đây là các quyền hạn ta có thể giám sát, cập nhật, kiểm
toán tập trung, tình trạng các user rác hay các user vô danh sẽ giảm bớt
rất nhiều khi có giải pháp IAM.
 Hệ thống sẽ dễ dàng mở rộng hơn.
 2.2.2 hệ thống quản lý định danh và truy cập AIM

Quản lý định danh và truy cập (gọi tắt IAM), là một khung chính sách và công
nghệ để đảm bảo rằng những cá nhân hợp lệ trong một hệ thống mạng có quyền
truy cập vào tài nguyên thông tin của một tổ chức. Các hệ thống IAM nằm dưới sự
bao bọc của bảo mật an toàn thông tin và quản lý dữ liệu. Giải pháp quản lý định
danh và truy cập cũng cung cấp khả năng quản lý tập trung thông tin của người
dùng, thông qua đó cung cấp nhiều hình thức để định danh và xác định người
dùng truy cập vào tài nguyên hệ thống. Giải pháp này cũng cung cấp khả năng
kiểm soát tương tự như một cổng kết nối cho phép xác thực và định danh người
dùng đang truy cập vào các phân vùng mạng trong hệ thống doanh nghiệp.

Truy cập và người dùng là hai khái niệm quan trọng trong IAM. Truy cập ám
chỉ đến các hành động của người dùng được phép thực hiện (như xem, tạo hoặc
thay đổi tệp). Người dùng có thể là nhân viên, các đối tác, bên nhà cung cấp, nhà
thầu hoặc khách hàng. Hơn thế, nhân viên có thể được phân khúc thành nhiều
lĩnh vực hơn nữa dựa trên vai trò của họ.

Các hệ thống IAM được thiết kế để thực hiện ba nhiệm vụ chính: định danh,
xác thực và ủy quyền. Điều này có nghĩa là chỉ những người phù hợp mới có
quyền truy cập vào máy tính, phần cứng, ứng dụng phần mềm, bất kỳ tài nguyên
công nghệ thông tin nào hoặc thực hiện các tác vụ cụ thể khác.

Một số thành phần cốt lõi tạo nên IAM framework bao gồm:

 Cơ sở dữ liệu chứa danh tính người dùng và đặc quyền truy cập.
 Các công cụ IAM để tạo, giám sát, sửa đổi và xóa các đặc quyền truy
cập.
 Một hệ thống kiểm tra lịch sử đăng nhập và truy cập.

Với người dùng mới gia nhập hoặc thay đổi vai trò của người dùng hiện tại,
danh sách các đặc quyền truy cập phải được cập nhật mọi lúc. Các chức năng IAM
thường thuộc quyền quản lý của các bộ phận công nghệ hoặc các bộ phận xử lý an
ninh mạng và quản lý dữ liệu.

IAM phải đạt được tối thiểu 4 khả năng như xác thực, phân quyền, quản trị
người dùng, lưu trữ người dùng.

Một số ví dụ đơn giản về nhận dạng và quản lý truy cập (IAM):

 Khi người dùng nhập thông tin đăng nhập của mình, danh tính của
người đó sẽ được kiểm tra dựa trên cơ sở dữ liệu để xác minh xem
thông tin khi đăng nhập có khớp với thông tin người dùng trong cơ sở
dữ liệu hay không. Chẳng hạn, khi một người đăng nhập vào hệ thống
quản lý tài chính, người này cần được sự cho phép để thực hiện công
việc của mình. Tuy nhiên, họ không được phép thay đổi các công việc
của người dùng khác.
 Một người điều hành công việc có thể xem một quy trình làm việc trực
tuyến nhưng sẽ không được phép sửa đổi nó. Mặt khác, người giám
sát không chỉ có quyền để xem mà còn có quyền sửa đổi tệp hoặc tạo
tệp mới. Nếu không có IAM, bất kỳ người dùng nào cũng có thể chỉnh
sửa hoặc thay đổi tài liệu và điều này có thể dẫn đến những hậu quả
nghiêm trọng.
 Thông qua IAM, chỉ những người dùng hợp lệ được xác minh trong tổ
chức mới được phép truy cập và xử lý thông tin nhạy cảm. Nếu không
có IAM, bất kỳ ai (ngay cả các tác nhân bên ngoài) đều có thể truy cập
các tài liệu bí mật của công ty, dẫn đến vi phạm dữ liệu có thể xảy ra.
Với khía cạnh này, IAM giúp các công ty đáp ứng các quy định nghiêm
ngặt và phức tạp chi phối việc quản lý dữ liệu.

Từ đó, ta thấy giải pháp IAM có các ưu điểm sau:

 IAM tăng cường khả năng bảo mật. Đây là lợi ích quan trọng nhất mà
tổ chức có thể nhận được từ IAM. Bằng cách kiểm soát quyền truy cập
 và thao tác của người dùng, các công ty có thể loại bỏ khả năng có các
trường hợp vi phạm dữ liệu, đánh cắp thông tin định danh và truy cập
bất hợp pháp vào thông tin bí mật. IAM có thể ngăn chặn nguy cơ lây
lan thông tin đăng nhập bị xâm nhập, tránh xâm nhập trái phép vào
mạng tổ chức, và cung cấp bảo vệ chống lại các hacker, mã độc
ransomware, lừa đảo và các loại tấn công mạng khác.
 IAM giúp giảm khối lượng công việc cho đội ngũ công nghệ. Bất cứ khi
nào một chính sách bảo mật được ban hành hay cập nhật, tất cả các
đặc quyền truy cập trên toàn tổ chức có thể được thay đổi trong một
lần quét. IAM cũng có thể giảm số lượng những yêu cầu gửi tới bộ
phận trợ giúp công nghệ thông tin liên quan đến việc khôi phục hoặc
đặt lại mật khẩu. Một số hệ thống thậm chí có một bộ tự động hóa cho
các tác vụ công nghệ thông tin cơ bản này.
 IAM giúp tuân thủ các chính sách. Với IAM, các công ty có thể nhanh
chóng đáp ứng các yêu cầu của các quy định trong ngành hoặc thực
hiện các thực tiễn tốt nhất của IAM.
 IAM cho phép hợp tác và nâng cao năng suất. Các công ty có thể cung
cấp cho các đối tượng ngoài hệ thống (như khách hàng, đối tác, nhà
cung cấp) truy cập vào mạng của họ mà không gây nguy hiểm cho an
ninh.
 IAM cải thiện trải nghiệm người dùng. Không cần nhập nhiều mật khẩu
để truy cập nhiều hệ thống thông qua khả năng của SSO. Nếu khả năng
sử dụng sinh trắc học hoặc thẻ thông minh được áp dụng, người dùng
có thể không cần phải nhớ mật khẩu phức tạp.

2.2.3 mục tiêu quản lý định danh và truy cập

Quản lý danh tính và quyền truy cập là một phần quan trọng của bất kỳ kế
hoạch bảo mật doanh nghiệp nào, vì nó được liên kết chặt chẽ với bảo mật và
năng suất của các tổ chức trong nền kinh tế số hóa ngày nay.
 Hệ thống IAM có thể đảm bảo và giúp theo dõi hoạt động của người dùng
cung cấp. Quản lý danh tính để bảo vệ tài sản thông tin của họ trước các mối
đe dọa giúp chương trình và ứng dụng tăng cường bảo mật và các hoạt động bảo
mật cho một tổ chức. Thông tin người dùng, cho dù đó là mật khẩu hay địa chỉ
email, có thể nhanh chóng trở thành một vấn đề phức tạp cần theo dõi nếu
không có hệ thống kiểm soát thích hợp. IAM giúp bảo vệ hệ thống khỏi các sự cố
bảo mật bằng cách cho phép quản trị viên tự động hóa nhiều tác vụ liên quan đến
tài khoản người dùng. Điều này bao gồm khả năng có quy trình làm việc tự động
để nhân viên được cấp quyền truy cập vào các hệ thống và ứng dụng mà họ được
phép truy cập, dựa trên vai trò của họ. Nó cũng bao gồm kiểm soát "một nút" để
loại bỏ quyền truy cập của nhân viên khỏi tất cả các hệ thống mà họ không được
cấp quyền truy cập thông qua nền tảng IAM.

Trong nhiều tổ chức, người dùng đôi khi có nhiều đặc quyền truy cập hơn
mức cần thiết. Một hệ thống IAM mạnh mẽ có thể thêm một lớp bảo vệ quan
trọng bằng cách đảm bảo áp dụng nhất quán các quy tắc và chính sách truy cập
của người dùng trong một tổ chức.

Các giải pháp IAM giúp các tổ chức đáp ứng các yêu cầu cần tuân thủ và giúp
họ tiết kiệm chi phí bằng cách giảm thiểu thời gian cần thiết để giải quyết các vấn
đề liên quan đến tài khoản người dùng. Quản lý danh tính và truy cập chuẩn hóa
và thậm chí tự động hóa các khía cạnh quan trọng của việc quản lý danh tính, xác
thực và ủy quyền, tiết kiệm thời gian và tiền bạc trong khi giảm rủi ro cho doanh
nghiệp.

Các khía cạnh bảo vệ khác nhau được cung cấp bởi các giải pháp IAM là chìa
khóa để xây dựng một chương trình bảo mật thông tin mạnh mẽ. Đây chỉ là một
số lĩnh vực mà các chuyên gia bảo mật phải xem xét trong khi phát triển hệ thống
kiểm soát truy cập và nhận dạng mạnh mẽ để bảo vệ tổ chức của họ. Khả năng có
thể kiểm soát và kiểm tra những người ra vào mạng của tổ chức là yếu tố quan
trọng để hỗ trợ hoạt động.
 Hệ thống quản lý định danh và truy cập có thể nâng cao năng suất kinh
doanh. Khả năng quản lý trung tâm của hệ thống có thể làm giảm sự phức tạp
và chi phí của việc bảo vệ thông tin xác thực và quyền truy cập của người dùng.
Đồng thời, hệ thống quản lý định danh cho phép người lao động làm việc hiệu
quả hơn trong nhiều môi trường khác nhau mà vẫn đảm bảo độ an toàn bảo
mật, cho dù họ đang làm việc tại nhà, văn phòng hay trên đường.
1.1. Các giao thức bảo mật web để cấu hình xác thực tập trung
Để giải quyết bài toán đăng nhập một lần, ta phải cấu hình để các ứng dụng,
dịch vụ cần đăng nhập phải ủy quyền và sử dụng server xác thực tập trung là nơi
giúp ứng dụng định danh và xác thực người dùng. Như vậy, giữa ứng dụng, dịch
vụ và Server xác thực tập trung cần chia sẻ các thông tin đăng nhập cũng như
thông tin tài nguyên ứng dụng mà không cần username và password, đồng thời
đạt được độ tin cậy và ủy quyền. Để đạt được mục đích đó, cần phải sử dụng các
chuẩn giao thức bảo mật của website và được Server xác thực tập trung hỗ trợ,
do đó chúng ta cần tìm hiểu các giao thức bảo mật đó là SAML, Oauth2 và OpenId
Connect.

Trước khi đến với các chuẩn giao thức trên, ta cần làm rõ lại khái niệm giữa
xác thực (Authentication) và ủy quyền (Authorization) vì 2 yếu tố này là các phần
rất quan trọng trong việc thực hiện các giao thức bảo mật trên.

 Xác thực là cơ chế xác minh người dùng hợp lệ trước khi cung cấp các
thông tin. Điều này rất quan trọng đối với hệ thống để kiểm tra tính hợp
lệ của người dùng nhằm tránh khả năng bị tấn công hoặc xâm nhập bất
hợp pháp. Trong quá trình này, người dùng đưa ra những yếu tố có thể
chứng minh được về danh tính cá nhân của họ hoặc danh tính thực thể.
 Ủy quyền là sự ủy thác một quyền tác động tới các thành phần của hệ
thống cho một người dùng hay một đối tượng nào đó. Việc ủy quyền xảy
ra khi giữa hệ thống và bên được ủy quyền có sự xác thực, tin tưởng lẫn
nhau. Đối tượng được ủy quyền chỉ được phép sử dụng các quyền mà
 hệ thống đã cấp phép mà không thể tác động đến các thành phần khác
của hệ thống. Việc đảm bảo ủy quyền giúp hệ thống tránh được rủi ro
các đối tượng tác động đến những dữ liệu nhạy cảm trong tổ chức.

Tóm lại, xác thực và ủy quyền là các biện pháp bảo mật được thực hiện để
bảo vệ dữ liệu trong hệ thống thông tin. Xác thực là quá trình xác minh danh tính
người truy cập vào hệ thống. Mặt khác, Ủy quyền là quá trình ủy thác và kiểm tra
các đặc quyền hoặc danh sách truy cập mà người dùng được ủy quyền. Nắm được
hai khái niệm này, ta sẽ hiểu rõ hơn về các giao thức bảo mật web hiện nay.

Ngoài ra, ta còn cần nắm được hai đối tượng chính trong quá trình bắt tay
giữa hệ thống định danh và xác thực tập trung với các ứng dụng dịch vụ. Đó là
Service Provider (SP) và Identity Provider (IdP).

 Service Provider: Là nhà cung cấp dịch vụ hay có thể hiểu là ứng dụng
cung cấp các dịch vụ cho người dùng sử dụng trên hệ thống thông
tin. Đây là các ứng dụng mà người dùng khi muốn truy cập vào cần
thực hiện đăng nhập với hệ thống.
 Identity Provider (IdP): Là nhà cung cấp định danh hay chính là hệ
thống định danh và xác thực. Nó cung cấp khả năng định danh danh
tính đồng thời xác thực người dùng cho các Service Provider được
cấu hình kết nối đến. Sau đó đảm nhiệm việc cấp quyền cho các
người dùng hợp lệ có thể đăng nhập và sử dụng dịch vụ.

2.3 các giao thức bảo mật web để cấu hình xác thực tập trung
2.3.1 giao thức SAML

Security Assertion Markup Language (SAML) là chuẩn lâu đời nhất, được
phát triển từ năm 2001, và lần cập nhật gần đây nhất vào năm 2005. Nó là một
chuẩn mở cung cấp cả khả năng xác thực (authentication) lẫn ủy quyền và phân
quyền (authorization).
 SAML được sinh ra nhằm giải quyết bài toán đăng nhập một lần. Khi các nhà
cung cấp dịch vụ muốn cho phép người dùng có thể sử dụng các dịch vụ khác
nhau mà chỉ cần đăng nhập một lần duy nhất, giúp cho việc sử dụng được thuận
tiện cũng như giúp cho người dùng quản lý các username và password được giảm
đi tối thiểu, việc này đòi hỏi cần có một cách nào đó cung cấp khả năng xác thực
và ủy quyền thông tin người dùng mà không cần bắt họ tạo tài khoản khác nhau
trên những dịch vụ khác nhau và SAML sẽ giải quyết vấn đề xác thực và ủy quyền
đó.

SAML là một "chuẩn mở" cho phép nhà cung cấp định danh thực thể Identity
Provider (IdP) xác thực người dùng và ủy quyền cho người dùng sử dụng một dịch
vụ, chức năng nào đó của nhà cung cấp dịch vụ Service Provider (SP) mà không
bắt buộc người dùng phải tạo tài khoản đăng nhập trên dịch vụ đó.

Cơ chế hoạt động :

Trước tiên, Service Provider (SP) và Identity Provider (IdP) phải bằng cách
nào đó trao đổi được khóa công khai với nhau trước. Thông thường, mỗi bên SP
và IdP sẽ có một public url chứa tệp metadata, tệp metadata này chứa các thông
tin công khai như là khóa công khai, ID thực thể và địa chỉ URL để điều hướng khi
có request đến. Phía IdP sẽ nhận biết được metadata url của SP và từ đó lấy ra
khóa công khai để xác thực chữ ký của SP. Trong trường hợp hệ thống của IdP
không lấy public key của SP thông qua metadata url được thì SP phải gửi khóa
công khai của mình cho IdP cài đặt trước khi thực hiện giao dịch. Dưới đây là một
file metadata ví dụ khi ta cấu hình giữa Service Provider và Identity Provider với
nhau:
 Hình 1.8 Tệp metadata khi cấu hình sử dụng giao thức SAML
Có thể thấy trên hình, dữ liệu chứa thông tin thực thể được mã hóa và phải
được trao đổi trước giữa SP và IdP qua một kênh kết nối an toàn.

Khi đó, SAML sẽ có cách hoạt động như sau:

Hình 1.9 Mô hình các bước xác thực của giao thức SAML
Bước 1: User sẽ click vào nút "Đăng nhập bằng tài khoản của WSO2" từ
browser, request này sẽ được gửi tới SP.

Bước 2: Phía SP sẽ tạo một SAML Request và gửi tới IdP, SAML Request này
được chính SP ký điện tử bằng chữ ký của SP (SP sử dụng khóa bí mật của để ký).
 Bước 3: Bên phía IdP khi nhận được SAML Request từ SP thì sẽ phải xác thực
chữ ký có đúng là của SP hay không bằng cách sử dụng khóa công khai của SP để
xác thực. Khóa công khai này được IdP lấy trong metadata trước đó hai bên đã
trao đổi.

Bước 4: Vẫn đang ở phía IdP, sau khi đã xác thực được chữ ký của SP rồi, IdP
sẽ làm những việc sau:

 Lấy ra thông tin người dùng đang sử dụng trình duyệt nếu người
dùng đã đăng nhập vào IdP (còn nếu người dùng đang không đăng
nhập thì bắt người dùng phải đăng nhập trước) để điều hướng (http
post) về cho SP sử dụng (kết quả trả về này ta gọi là SAML Response).
Trước khi gửi về cho SP thì IdP sẽ ký điện tử vào SAML Response (IdP
sử dụng khóa bí mật để ký).
 Không những IdP ký vào SAML Response mà IdP cũng sẽ mã hóa hết
các kết quả dữ liệu (SAML Assertions) có trong SAML Response bằng
khóa công khai của SP.

Bước 5: Khi SP nhận lại được SAML Response, nó sẽ làm những việc sau:

 Dùng khóa công khai của IdP để kiểm tra xem có đúng là kết quả
được gửi từ IdP hay không (đây chính là phần xác thực mà OAuth và
OAuth2 không có). Khóa công khai của IdP cũng giống như đã nói ở
trên, có thể lấy được thông qua metadata url của IdP hoặc có thể
được trao đổi trước.
 Nếu xác thực đúng chữ ký, SP sau đó dùng khóa bí mật của chính
mình để giải mãi SAML Assertions mà đã được phía IdP mã hóa.
 Lấy thông tin dữ liệu người dùng trong SAML Assertions để đăng
nhập người dùng vào hệ thống của chính mình, sau đó trả về cho
người dùng thông báo đăng nhập thành công hoặc điều hướng người
dùng tới các tài nguyên mong muốn.
 2.3.2 giao thức Oauth2

OAuth2.0 là giao thức xác thực các ứng dụng có thể chia sẻ tài nguyên với
nhau mà không cần chia sẻ thông tin về username và password như những cách
truyền thống. Đây là một chuẩn mở để ủy quyền/phân quyền (authorization).
Giao thức 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. OAuth2 làm điều này bằng cách gửi token được tạo ra bởi một nhà cung
cấp nhận dạng (indentity provider) cho các ứng dụng bên thứ ba, với sự chấp
thuận của người dùng.

Khi làm việc với OAuth2, chúng ta sẽ cần phải biết các khái niệm cơ bản như
sau:

 Resoure Owner: là chủ sở hữu của dữ liệu mà ta muốn chia sẻ. Ví dụ ta

muốn chia sẻ các thông tin như email, ngày sinh, giới tính, địa chỉ cho
một trang web nào đó thì chúng ta có thể đăng nhập trang web đó bằng
WSO2 account, những thông tin như email, ngày sinh, giới tính, địa chỉ là
những tài nguyên cần chia sẻ và Resource Owner lúc này chính là ta.
 Resource Server: là server lưu trữ những thông tin mà ta chia sẻ. Server
này có khả năng nhận và trả lời các yêu cầu (request) truy xuất dữ liệu.
Như ở ví dụ trên của chúng ta thì resource server chính là WSO2 Identity
Server.
 Client: Là những ứng dụng muốn sử dụng những tài nguyên mà ta chia
sẻ. Ta có thể thấy là ở ví dụ trên thì Client sẽ là trang web muốn lấy các
thông tin cá nhân của ta.
 Authorization Server: Là đối tượng quyết định việc cấp quyền truy cập
vào dữ liệu cho client. Ở đây, resource server và authorization server
 đều là WSO2 Identity Server, nhưng về mặt chức năng mà nói, đây là 2
chức năng hoàn toàn riêng biệt.

Dựa vào các khái niệm và ví dụ tương ứng trên, ta có thể hiểu Oauth2 vận
hành như sau:

 Khi người dùng đăng nhập vào Moodle client, website sẽ dẫn họ đến
trang đăng nhập của WSO2 Identity Server và liệt kê những quyền mà nó
cần phải có để cho phép họ đăng nhập và sử dụng dịch vụ.
 Nếu người dùng đồng ý thì lúc này WSO2 Identity Server sẽ phát cho
website một cái token. Token này chứa một số quyền hạn nhất định
giúp cho website có thể xác minh người dùng cũng như giúp cho website
có thể hoạt động được.
 Nếu website này bị hacker tấn công thì nó chỉ lấy được thông tin hay
hoạt động của người dùng trên website đó mà không ảnh hưởng đến
những website khác mà họ đang sử dụng. Do đó, cách đăng nhập bằng
phương thức OAuth này rất an toàn cho những người dùng.

Với cách vận hành như trên, ta có sơ đồ hoạt động của Oauth2 như sau:

Hình 1.10 Mô hình các bước xác thực của giao thức OAuth2
1. Ứng dụng yêu cầu ủy quyền để truy cập vào Resource Server (ở đây là
WSO2 Identity Server) thông qua user.
 2. Nếu user ủy quyền cho yêu cầu trên, ứng dụng sẽ nhận được ủy quyền từ
phía user dưới dạng một token string.

3. Ứng dụng gửi thông tin định danh (ID) của mình kèm theo ủy quyền của
user tới Authorization Server.

4. 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 access_token. Đến đây quá trình ủy quyền đã hoàn
tất.

5. Để truy cập vào tài nguyên ở Resource Server và lấy thông tin, ứng dụng sẽ
phải đưa ra access_token để xác thực.

6. Nếu access_token hợp lệ, Resource Server sẽ trả về dữ liệu của tài nguyên
đã được yêu cầu cho ứng dụng.

Ưu điểm:

 OAuth 2.0 là một giao thức linh hoạt dựa trên công nghệ tiêu chuẩn
SSL (Secure Sockets Layer đảm bảo dữ liệu giữa máy chủ web và trình
duyệt giữ được sự riêng tư) để lưu token truy cập của người dùng.
 Cho phép khả năng truy cập hạn chế vào dữ liệu của người dùng và
cho phép truy cập khi authorization token hết hạn.
 Có khả năng chia sẻ dữ liệu cho người dùng mà không phải tiết lộ
thông tin cá nhân.
 Dễ dàng hơn để thực hiện và cung cấp xác thực mạnh mẽ hơn.

2.3.3 giao thức OpenID connect

OpenID Connect (OIDC) là một lớp xác thực (Authentication layer) được phát
triển dựa trên nền tảng giao thức OAuth2.0. Là một framework dùng cho việc xác
thực, OIDC cho phép client xác định định danh của user dựa trên xác thực được
thực hiện bởi máy chủ Authorization hoặc Identity Provider (IdP). Bản chất của
vấn đề là việc ủy thác quyền xác thực người dùng và quyền sử dụng dịch vụ cho
bên IdP. Ví dụ: Người dùng muốn đăng nhập vào Moodle nhưng không có tài
khoản. Họ bắt buộc sẽ phải đăng ký một tài khoản Moodle để có thể sử dụng.
Việc đăng ký yêu cầu người dùng cần điền đầy đủ các thông tin của họ vào một
form đăng ký gồm rất nhiều các thông tin username, password, address, phone
number, email,… và sau khi quá trình đăng ký hoàn tất người dùng có thể sử dụng
tài khoản đó đăng nhập vào Moodle. Cả quá trình trên khá phiền hà và tốn thời
gian.

Vậy sẽ ra sao nếu người dùng có thể sử dụng một tài khoản ở một nơi khác
để đăng nhập vào hệ thống. Ta có thể gặp rất nhiều các trường hợp như vậy trên
rất nhiều các trang web hiện nay. Người dùng có thể sử dụng tài khoản Google
hoặc Facebook của họ để đăng nhập vào các trang web đó. Việc đó đem lại khá
nhiều sự tiện lợi khi chỉ cầu qua vài khâu đơn giản người dùng đã có thể được
đăng nhập và sử dụng dịch vụ mà học mong muốn.

OpenID là một giao thức xác thực phi tập trung theo chuẩn mở để hiện thực
hoá những việc ở trên. OpenID Connect giúp các client kiểm tra người dùng thông
qua các Authorization server, đồng thời với đó là lấy các thông tin cơ bản của user
đó bằng cách gọi đến các API. OpenID Connect dùng JSON Web Tokens (JWT)
trong đó việc xác thực dựa vào các token string trao đổi qua lại giữa Client và
Authentication Server. Thông tin mà server gửi về bao gồm một access_token, và
có thể có một ID token nếu được yêu cầu. Ví dụ khi đăng nhập vào Moodle:

1) Khi người dùng chọn đăng nhập dùng tài khoản WSO2, hệ thống sẽ gửi
một Authorization Request tới WSO2 Identity Server để xin được cấp
quyền truy cập.
2) WSO2 Identity Server xác thực thông tin của user hoặc yêu cầu user login
nếu họ chưa đăng nhập, và sau đó hỏi user việc cấp quyền, tức là các
quyền truy cập như tên, email, số điện thoại… của họ.
3) Khi người dùng đã chấp thuận việc đăng nhập, WSO2 Identity Server sẽ
gửi một access_token, và có thể có ID Token cho ứng dụng.
 4) Ứng dụng có thể nhận thông tin người dùng từ ID Token hoặc sử dụng
access_token để truy cập đến WSO2 Server.

Trong đó:

 Access Token là một mã bí mật dùng cho ứng dụng để có thể truy cập
API. Access Token có thể là một chuỗi, một JWT token, hay một loại
token khác. Nó báo cho API biết được là ứng dụng đã được cấp quyền
cho một số hoạt động nhất định dựa trên phạm vi mà ứng dụng đã
được cấp.
 ID Token là một JWT chứa các thông tin nhận dạng. Nó được ứng dụng
sử dụng để lấy các thông tin của user như username, email… và hiển
thị lên giao diện. ID Token tuân theo chuẩn công nghiệp (IETF RFC
7519) và gồm có 3 phần chính là: header, body và chữ ký.
 JWT Token chứa các claim là các thông tin về định danh (như là tên,
email, address) của một thực thể (thông thường là user) và các thông
tin metadata khác.

2.4 nghiên cứu đánh giá một số giải pháp SSO

3 Hiện nay có khá nhiều giải pháp SSO được giới thiệu và đưa vào sử dụng trong
thực tế chẳng hạn như: (1) Open Single SignOn (OpenSSO) hoạt động dựa trên
token; (2) Central Authentication Service (CAS) hoạt động dựa trên ticket; (3)
Tivoli Access Manager for Enterprise Single SignOn; (4) ASP.NET SAML Single
Sign-On; (5) Java Open SSO (JOSSO).
4 OpenSSO là một sản phẩm SSO nguồn mở của SUN phát triển. Đó là một sản
phẩm đơn lẻ, kết hợp các tính năng của Sun Java System. Access Manager, Sun
Java System Federation Manager và Sun System SAML v2 Java Plugin, kiểm
soát truy nhập, đảm bảo an toàn các dịch vụ web và các dịch vụ định danh
Web. Khi truy cập vào những tài nguyên được bảo vệ của người dùng, yêu cầu
truy cập cần được xác thực và phải có đủ quyền truy cập. Khi một người gửi
yêu cầu để truy cập tài nguyên được bảo vệ, policy agent chặn yêu cầu này và
 kiểm tra. Nếu OpenSSO token được tìm thấy không hợp lệ, policy agent sẽ yêu
cầu máy chủ tiến hành xác thực và cấp phép như hình dưới.
5

6 Hình 1.11 Giải pháp đăng nhập một lần sử dụng OpenSSO
7 Policy agent là ứng dụng web với nhiệm vụ ngăn tất cả yêu cầu đến ứng dụng,
để kiểm tra xem người dùng đã xác thực hay chưa.
 8

9 Hình 1.12 Cơ chế hoạt động của OpenSSO

10 Cơ chế hoạt động của OpenSSO như sau:
11 1) Từ trình duyệt, người dùng kết nối đến ứng dụng web.
12 2) Policy Agent sẽ kiểm tra token có tồn tại trong URL hay không. Nếu token
chưa tồn tại thì Policy Agent sẽ chuyển trình duyệt đến máy chủ OpenSSO.
13 3) Máy chủ OpenSSO xác thực người dùng thông qua trang đăng nhập. Người
dùng nhập tên truy cập/mật khẩu để xác thực.
14 4) OpenSSO tạo ra session cho người dùng và kích hoạt nó nếu xác thực thành
công.
15 5) OpenSSO gửi token cho trình duyệt (trình duyệt sẽ lưu token dưới dạng
cookie) và Trình duyệt sẽ gửi token đến cho Agent.
16 6) Policy Agent sẽ lấy thông tin token gửi đến máy chủ OpenSSO để kiểm tra.
17 7) Máy chủ OpenSSO sẽ gửi thông tin đăng nhập (tên truy cập, mật khẩu) và
thông tin vai trò đến Agent nếu kiểm tra token hợp lệ.
18 8) Policy Agent sẽ quyết định cho phép truy cập ứng dụng hay không và ghi
thông tin session trên URL.
19 Central Authentication Service là một giải pháp SSO mã nguồn mở được phát
triển bởi đại học Yale với các tính năng sau:
20 - CAS hỗ trợ nhiều thư viện phía máy khách được viết bởi nhiều ngôn ngữ:
PHP, Java, PL/SQL. Nó lấy thông tin SSO thông qua cookie. Cookie này sẽ bị hủy
khi người dùng đăng xuất khỏi CAS hoặc đóng trình duyệt. Cookie được sinh ra
bởi CAS, còn được gọi là Ticket Granting Cookie (TGC) chứa một ID duy nhất.
21 - CAS cung cấp nhiều trình quản lý xác thực (authenticate handler) khác nhau.
CAS xác thực nhiều loại thông tin người dùng như tên truy cập/mật khẩu,
chứng chỉ khóa công khai X509... để xác thực những thông tin người dùng khác
nhau này, CAS sử dụng những trình quản lý xác thực tương ứng.
22 - CAS cung cấp tính năng “Remember me”. Người phát triển có thể cấu hình
tính năng này trong nhiều file cấu hình khác nhau và khi người dùng chọn
“Remember me” trên khung đăng nhập, thì thông tin đăng nhập sẽ được ghi
nhớ với thời gian được cấu hình. Khi người dùng mở trình duyệt thì CAS sẽ
chuyển đến service URL tương ứng mà không cần hiển thị khung đăng nhập.
23 Nguyên tắc chứng thực người dùng với máy chủ CAS hoạt động như sau:
 24

25 Hình 1.13 Mô hình giải pháp CAS

26 - Người dùng nhập tên truy cập/mật khẩu vào khung đăng nhập. Các thông tin
này được truyền cho CAS máy chủ thông qua giao thức HTTPS.
27 - Xác thực thành công, TGC được sinh ra và thêm vào trình duyệt dưới hình
thức là cookie. TGC này sẽ được sử dụng để đăng nhập với tất cả các ứng
dụng.
28 Cơ chế hoạt động của CAS trong trường hợp người dùng truy cập ứng dụng mà
chưa được chứng thực với máy chủ CAS như hình sau:
 29

30 Hình 1.14 Cơ chế hoạt động khi người dùng chưa chứng thực với CAS
31 Trong trường hợp người dùng khi truy cập ứng dụng mà đã chứng thực với
máy chủ CAS thì cơ chế hoạt động như hình sau:
 32

33 Hình 1.15 Cơ chế hoạt động khi người dùng đã chứng thực với CAS
34 Trên đây là hai giải pháp SSO thường được sử dụng hiện này. Ngoài ra còn có
các sản phẩm có tích hợp các giải pháp SSO hiện có như bảng dưới đây:

Quản lý
Nhà phát Loại
Tên sản phẩm định Mô tả
triển hình
danh

Accounts & SSO Nokia , Intel Miễn phí Triển khai phía máy
khách với các plugin cho
các dịch vụ / giao thức
 khác nhau

Hệ thống dựa trên xác

Active Directory
Federation Services
Microsoft Bản quyền nhận quyền sở hữu và
liên kết ứng dụng

Gquản lý truy cập và

nhận dạng dựa trên đám
mây dành cho doanh
Bitium Bitium Bản quyền nghiệp với đăng nhập
một lần, tích hợp thư
mục hoạt động và các tùy
chọn xác thực 2 yếu tố

Giao thức và triển khai

máy chủ / máy khách SSO
CAS / Central mã nguồn mở với hỗ trợ
Authentication Apereo Miễn phí cho các giao thức CAS,
Service SAML1, SAML2, OAuth2,
SCIM, OpenID Connect và
WS-Fed

Facebook SSO cho các

Facebook connect Facebook Bản quyền bên thứ ba được
Facebook kích hoạt

FreeIPA RedHat Miễn phí Có

Hewlett-
Giải pháp đăng nhập một
IceWall SSO Packard Bản quyền
lần trên web và liên kết
Enterprise

Janrain Federate SSO của người dùng

Janrain Bản quyền Có
SSO thông thường và xã hội

JOSSO JOSSO Miễn phí Máy chủ đăng nhập một

 lần nguồn mở

Keycloak
SSO liên kết (LDAP và
(Red Hat Single Red Hat Miễn phí Có
Active Directory),
Sign-On)

Dịch vụ web đăng nhập

Microsoft account Microsoft Bản quyền
một lần của Microsoft

Đăng nhập một lần trên

myOneLogin VMware Bản quyền
đám mây

Nền tảng Quản lý Truy

NetIQ Access cập, Liên kết và Kiểm
Manager
NetIQ Bản quyền Có
soát Truy cập Dựa trên
Rủi ro

Quản lý danh tính và truy

OneLogin cập dựa trên đám mây
OneLogin Bản quyền Có
Inc. với đăng nhập một lần
(SSO)

Bộ quản lý danh tính và

Oracle Identity Oracle
Management
Bản quyền Có quyền truy cập của các
Corporation
sản phẩm từ Oracle

Kiểm soát truy cập nguồn

Shibboleth Shibboleth Miễn phí
mở dựa trên SAML

SSO dựa trên OpenID cho

Ubuntu Single Sign
On
Canonical Ltd. Bản quyền các dịch vụ Launchpad và
Ubuntu

IAM doanh nghiệp với

Univention
Corporate Server
Univention Miễn phí đăng nhập một lần
bằng SAML
 SSO dựa trên SAML 2.0,
WSO2 Identity OpenID, OpenID
Server
WSO2 Miễn phí Có
Connect, OAuth 2.0,
SCIM, XACML

Tham chiếu Triển khai

ZXID ZXID Miễn phí Có
bảo mật TAS3

35
36 Hệ thống SSO không tự thực sự cải thiện bảo mật và trên thực tế, nếu không
triển khai đúng cách có thể làm giảm bảo mật. SSO được sử dụng nhiều hơn
cho việc tăng sự thuận tiện với người sử dụng. Mặc dù vậy, nếu được đầu tư
giải pháp bảo mật thích hợp thì SSO sẽ gia tăng khả năng bảo mật hơn rất
nhiều. Máy chủ SSO sẽ có thể được hoạt động như một người gác cổng, đảm
bảo tất cả các xác thực đầu tiên thông qua máy chủ SSO phải đi qua các chứng
chi đã được lưu trữ để xác thực các ứng dụng đã được đăng ký với hệ thống
SSO. Vậy nên, nếu được triển khai đúng cách, có kế hoạch cụ thể và giám sát
chi tiết thì SSO sẽ gia tăng khả năng bảo mật của toàn hệ thống lên cao hơn so
với chỉ triển khai các biện pháp bảo mật thông thường.
37 Ngoài ra, hệ thống SSO thường có khả năng lưu trữ các thông tin xác thực và
các khóa mã hóa an toàn hơn, làm cho các thông tin này là một thách thức đối
với tin tặc. Hệ thống SSO nằm sâu trong kiến trúc IT của cơ quan đơn vị. Nó
thường được giấu một cách an toàn sau nhiều bức tường lửa. Điều này sẽ giúp
SSO an toàn hơn.