Xá thự và thẩm định trong á hệ thống đăng nhập một lần

Nguy n Linh Giang ễ Viện: Công ngh thông tin và truy n thông ệềHà N i, 2020 ộ Trang 3 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

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

LUẬN VĂN THẠC SĨ Xác th c và th ự ẩm đị nh trong các h ệ thống đăng nhậ p m t l n ộ ầ

Vũ Tuấ n Anh Vta2712@gmail.com Ngành: Công ngh thông tin ệ

Giảng viên hướng dẫn: PGS TS Nguy n Linh Giang ễ 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Ĩ Xác th c và th ự ẩm đị nh trong các h ệ thống đăng nhậ p m t l n ộ ầ

Vũ Tuấ n Anh Vta2712@gmail.com Ngành: Công ngh thông tin ệ

Giảng viên hướng dẫn: PGS TS Nguy n Linh Giang ễ Viện: Công ngh thông tin và truy n thông ệ ề

Hà N i, 2020 ộ

ký c a GVHD Chữ ủ

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

Độc lập – Tự do – Hạnh phúc

Họ và tên tác giả luận văn: Vũ Tuấn Anh

Đề tài luận văn: Xác thực và thẩm định trong các hệ thống đăng nhập một lần

Chuyên ngành: Công nghệ thông tin

Mã số SV: CA180130

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/06/2020 với các nội dung sau:

1 B ổ sung mô t bài toán ả thực tế khi áp d ụng SSO

2

B ổ sung giả i pháp gi i quy t bài toán thực tế và ả ế

năng SSO

9

B ổ sung thêm kết luận ch ra các h ỉ ạn chế và khó

10 S ửa lỗi chính tả

11 Sửa lỗi trích dẫn tài liệu tham khảo

Giáo viên hướng dẫn Tác giả luận văn

CHỦ TỊCH HỘI ĐỒNG

PGS TS Trương Thị Diệu Linh

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 Th y giáo PGS.TS ấ ớ ầ –Nguyễn Linh Giang – trưởng 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 quá 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 t ầh 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 quá trình h c t p và nghiên c u tệ ố ọ ậ ứ ại trường Ngoài ra, tôi xin cảm ơn đề tài KC.01.15/16-20 đã hỗ tôi trong quá trình trợthực hi n luệ ận văn Nghiên cứu này được tài tr bợ ởi Quỹ Phát tri n khoa h c và ể ọ

công ngh ệ Quốc gia (NAFOSTED) trong đề tài mã s 102.02- 2019.314.ố

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 hoà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

Vũ Tuấn Anh

MỤC LỤC

M C L C i Ụ Ụ DANH M C KÝ HI U, CÁC CH VI T T T iii Ụ Ệ Ữ Ế Ắ DANH M C HÌNH NH iv Ụ Ả DANH M C B NG BI U vi Ụ Ả Ể

M Ở ĐẦU 1

1 Đặ ấn đềt v 1

2 Phương pháp đề xu t 2 ấ 3 B cố ục luận văn 3

CHƯƠNG 1: Cơ chế đăng nhập m t l n (SSO) 4 ộ ầ 1.1 Giới thiệu v ề SSO 4

1.1.1 Khái ni m 4 ệ 1.1.2 Các phương pháp xác thực 5

1.1.3 Nguyên lý hoạt động 7

1.2 Các giao thức xác thực SSO phổ ế bi n 8

1.2.1 Giao thức OpenID 8

1.2.2 Giao thức SAML 9

1.2.3 Giao th c OAuth2 11 ứ 1.2.4 Giao thức Kerberos 12

1.3 M t s s n ph m ộ ố ả ẩ SSO đã được tri n khai b i các công ty l n 15 ể ở ớ 1.4 Ưu điểm, nhược điểm và r i ro khi tri n khai SSO 18 ủ ể CHƯƠNG 2: Giao th c Oauth2 20 ứ 2.1 Giới thiệu v OAuth2 20 ề 2.2 Nguyên lý hoạt động 20

2.2.1 Các đối tượng trong OAuth2 20

2.2.2 Sơ đồ ồ lu ng hoạt động 20

2.2.3 Đăng ký thông tin ứng d ngụ [3] 21

2.2.4 ClientID và Client Secret[3] 22

2.2.5 Các hoạt động khác 22

2.3 Các cấp ủy quy n 23 ề 2.3.1 C p y quy n s d ng mã y quy n (Authorization Code)ấ ủ ề ử ụ ủ ề [3] 23

2.3.2 C p y quy n ngấ ủ ề ầm định (Implicit)[3] 24

2.3.3 C p y quy n b ng password (Password)ấ ủ ề ằ [3] 26

2.3.4 C p y quy n b ng thông tin ng d ng (Client Credentials)ấ ủ ề ằ ứ ụ [3] 26

2.4 Ưu điểm và nhược điểm c a OAUTH2 26 ủCHƯƠNG 3: Đề xu t gi i pháp xây d ng h th ng SSO s d ng giao th c ấ ả ự ệ ố ử ụ ứ

OAuth2 tại Bệnh viện YHCTTW 28 3.1 Giới thiệu v ề ứng dụng CNTT t i B nh vi n Y Hạ ệ ệ ọc cổ truyền TW 28 3.1.1 Gi i thi u chung v B nh vi n 28 ớ ệ ề ệ ệ3.1.2 H t ng trang thi t b , ng d ng CNTT t i B nh vi n 28 ạ ầ ế ị ứ ụ ạ ệ ệ3.2 Gi i pháp xây d ng h thả ự ệ ống SSO ử ụs d ng giao th c OAuth 2.0 28 ứ3.2.1 Các thu n lậ ợi và khó khăn tại Bệnh viện 28 3.2.2 Bài toán thực tế đặ t ra 29 3.2.3 Lựa chọn gi i pháp 31 ả3.3 Phân tích và thiết kế ổ t ng quan h th ng 35 ệ ố3.3.1 Đề xuất mô hình hạ ầ t ng thi t b tế ị ại Bệnh vi n 35 ệ3.3.2 Ki n trúc h th ng thông tin 37 ế ệ ố3.3.3 Sơ đồ kh i chố ức năng của h th ng 38 ệ ố3.3.4 Sơ đồ hoạt động c a h th ng 39 ủ ệ ố3.4 M c tiêu cụ ủa giải pháp 40 3.5 Ưu điểm và nhược điểm của giải pháp 403.6 Phạm vi ửth nghi m 41 ệ3.7 Th nghi m 41 ử ệ3.7.1 Môi trường th nghi m 41 ử ệ3.7.2 Ti n hành th ế ử nghiệm 41 Chương 4: Kết lu n và đề xất hướng phát triển 66 ậ4.1 K t lu n 66 ế ậ4.2 Đề xu t h ng phát tri n 68 ấ ướ ểTÀI LIỆU THAM KHẢO 69

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 ộ ầ

AI Artificial Intelligence Trí tu nhân t o ệ ạ

Authen Authentication Xác th c ự

Author Authorization Thẩm định (Ủy quy n) ề

PKI Public key infrastructure H t ng khóa công khai ạ ầ

LDAP Lightweight Directory Access

Protocol

Giao thức truy cập thư m c nhẹụ

DANH M C HÌNH NH Ụ Ả

Hình 1: Gi i thi u v ớ ệ ề SSO[10] 4

Hình 2: Phân loại các phương thức xác thực[12] 6

Hình 3: Cách th c hoứ ạt động c a Single sign-ủ on[4] 7

Hình 4: Cách th c hoứ ạt động của OpenID Connect[16] 9

Hình 5: Cách th c hoứ ạt động của SAML[5] 10

Hình 6: Cách th c hoứ ạt động của OAuth2[1] 12

Hình 7: Cách th c hoứ ạt động c a Kerberosủ [13] 13

Hình 8: Sơ đồ ồ lu ng hoạt động OAuth2[3] 21

Hình 9: Sơ đồ hoạt động Authorization Code[3] 23

Hình 10: Sơ đồ hoạt động Implicit[3] 25

Hình 11: Mô hình ki n trúc v t lý hi n t i 35 ế ậ ệ ạ Hình 12: Mô hình h t ng thi t b xu t 36 ạ ầ ế ị đề ấ Hình 13: Kiến trúc h ệ thống thông tin 37

Hình 14: Sơ đồ kh i chố ức năng hệ ố th ng Single sign-on s d ng OAuth2 38 ử ụ Hình 15: Sơ đồ hoạt động của ệ ốh th ng 39

Hình 16: Khở ạo môi trười t ng Webserver trên máy tính cá nhân 42

Hình 17: Giao di n mệ ặc định của dự án Laravel 42

Hình 18: Tạo cơ sở ữ ệ d li u trong PhpMyAdmin (Xampp) 43

Hình 19: Sửa lại code trong file AppServiceProvider.php 44

Hình 20: Thêm thông báo ‘Trait Notifiable’ vào trong file User.php 45

Hình 21: Thay đổi driver c a api trong file auth.php 46 ủ Hình 22: Khai báo các Vue component trong file app.js 47

Hình 23: Quản lý User trên Server Oauth2 47

Hình 24: Đăng ký route cho phần tin t c 48 ứ Hình 25: Đăng ký route cho Website1 48

Hình 26: Hi n th ể ị cài đặ ế ốt k t n i Oauth2 Server trên Website1 49

Hình 27: Lưu cấu hình k t nế ối Oauth2 vào cơ sở ữ ệ d li u 49

Hình 28: Th c hiự ện đăng nhập tài khoản bằng Server Oauth2 50

Hình 29: Hàm Callback sau khi login thành công bằng Oauth2 50

Hình 30: Màn hình Welcome - Hi n th thông tin tài khoể ị ản người dùng 51

Hình 32: C u hình l i file env 52 ấ ạ

Hinh 33: Ki m tra biể ến môi trường PHP 53

Hình 34: Các bước cài đ t biặ ến môi trường PHP 56

Hình 35: Cài đặt biến môi trường PHP thành công 57

Hình 36: B ộ code thử nghi m gệ ồm 4 thư mục 57

Hình 37: Sau khi import CSDL thành công 58

Hình 38: File khởi động bat để kích hoạt khởi động Project 58

Hình 39: Khởi đồng thành công 3 server trên 3 port 59

Hình 40: Trang ch Oauth2 Server 59 ủ Hình 41: Đăng ký tài khoản trên Oauth2 Server 60

Hình 42: Giao di n trang qu n tr 60 ệ ả ị Hình 43: Giao di n trang qu n lý tin t c 60 ệ ả ứ Hình 44: Giao di n chệ ức năng chỉnh s a tin t c 61 ử ứ Hình 45: Hoàn thành các bước cấu hình cài đặt SSO 63

Hình 46: C u hình Oauth2 Client trên Website1 63 ấ Hình 47: C u hình Oauth2 Client trên Website2 64 ấ Hình 48: Thông báo người dùng có đồng ý ủy quyền hay không? 64

Hình 49: Màn hình đăng nhập thành công trên Webiste1 64

Hình 50: Màn hình đăng nhập thành công trên Webiste2 65

M Ở ĐẦU

1 Đặ ất v n đ ề

Cách mạng công nghiệp 4.0 có ảnh hưởng rất mạnh mẽ đến tất cả các nghành nghề, các lĩnh vực khác nhau tại Việt Nam trong đó có nghành Y tế Hiện nay, các cơ quan quản lý cùng các doanh nghi p vệ ẫn đang tìm kiếm các gi i pháp ảcông ngh nhệ ằm hướng t i xây d ng “Bớ ự ệnh viện thông minh”

Bệnh viện thông minh[6]có thể ểu với ý nghĩa đơn giản nhất là bệnh viện hi

có đội ngũ thầy thu c giố ỏi, cơ sở ậ v t ch t hiấ ện đại và ng d ng công ngh thông ứ ụ ệtin để ối ưu hóa, tự độ t ng hóa các quy trình và ho t đ ng t i b nh vi n H th ng ạ ộ ạ ệ ệ ệ ố

Bệnh viện thông minh được xây dựng lên từ ất nhiều các yếu tố khác nhau như r

trang bị ạ ầng CNTT hiệ h t n đ i, các ứng dụng phần mềm phục vụạ việc khám chữa bệnh, các ng d ng ph n m m quứ ụ ầ ề ản lý điều hành, chuyển đổi số hóa các thông tin dữ ệ li u, tích h p ợ ứng d ng các công nghự ệ nh n dạậ ng mới (gi ng nói, vọ ị trí, sinh trắc học…), ứng d ng trí tu nhân t o (AI) và các công nghụ ệ ạ ệ ớ m i hỗ ợ tr hoạt động quản lý bệnh viện và việc cuối cùng là việc đ m bảo an toàn thông tin ả

b o m t ả ậ

dTheo xu hướng phát triển chung của thờ ại đ i, mỗi người sẽ ần dần phải sử

dụng nhiều các ứng dụng khác nhau thông qua nhiều tài khoản khác nhau và phải ghi nhớ ậ m t mã riêng cho t ng tài kho n Thừ ả ực tế trước khi có SSO, mỗi 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 hoặc các hệthống khác nhau trong cùng một phiên (session) Điều này rõ ràng gây ra tốn nhiều thời gian, trong môi trường Y tế cũng như trong tất cả môi trường đặc thù khác, m i phút m i giây thỗ ỗ ời gian đề ất đáng quý u r

Trong môi trườ ế các ủ ục hành chính không ức tạp nhưng khá rườm rà và m t thấ ời gian như trong các khâu xếp hàng chờ, đăng ký khám, chuẩn bị ấy tờ, kiểm tra giấy tờ…Vì vậy thay vì phải ngồi chờ gi hoặc phải qua nhiều bộ phận để làm các thủ ục hành chính (các loại giấy tờ) thì người bệnh có t

th ể đăng ký hẹn khám trước và xem trước những giấy tờ ần phải chuẩn bị, quy ctrình đăng ký khám trước khi đến khám Vi c này không ch giúp cho gi m th i ệ ỉ ả ờgian chờ ấ r t nhi u cho b nh nhân mà còn làm gi m áp lề ệ ả ực cho người nhà bệnh

nhân cũng như làm tăng cơ hội chữa trị cho bệnh nhân ỗi khi đến khám Ngoài m

ra, b nh nhân ệ còn có th xem các thông tin Y t chính xác, chính thể ế ống, xin tư

vấn hỏi đáp khám bệnh và nh n phậ ản hồ ừ các chuyên gia đầu nghành đầy kinh i t nghiệm, địa chỉ mua thu c uy tín… trên h ố ệ thống website của Bệnh viện ch b ng ỉ ằ

một tài khoản duy nhất Hiện nay trên các trang mạng xã hội luôn tồn tại những thông tin không chính th ng, xuyên t c gây hoang mang xã h i, vi c xây dố ạ ộ ệ ựng

một hệ ố th ng thông tin chính xác, ưu tín, chính thống nhằm đảm bảo quyền lợi

của mọi người khi tham gia đều được minh bạch, rõ ràng và công bằng Do vậy, xây d ng b nh vi n thông minh v i gi i pháp SSO là rự ệ ệ ớ ả ất cần thi ết

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

Hiện nay có nhiều giải pháp ỹ k thuật khác nhau cho phép xây dựng hệ

th ng ố SSO Các giải pháp này đều có những ưu điểm, nhược điểm riêng Đứng trên phương diện người ph trách tri n khai h th ng thì vi c l a ch n m t gi i ụ ể ệ ố ệ ự ọ ộ ảpháp phù h p vợ ới đơn v ị mình là r t quan trấ ọng, đồng thời tiêu chí “An toàn,

b o m t thông tin”ả ậ phải đặt lên hàng đầu

Mục đích nghiên c ứ u c a luậ ủ n văn: Tập trung nghiên cứu gi i pháp xây ả

dựng hệ ống SSO giao thức chuẩn OAuth2 ại Bệnh việ cho phép thực thi các th t n nhiệm vụ liên quan đến xác thực (authentication) và ẩm định (ủy quyềth n) (authorization) cung cấp quyền truy cập tài nguyên người dùng ết hợp với mô khình hạ ầ t ng trang thi t bế ị phần cứng để tăng cường tính b o m t cho hả ậ ệ ố th ng Người dùng đăng nhập vào m t h th ng s t ộ ệ ố ẽ ự động đăng nhập vào t t c các h ấ ả ệ

thống còn lại trong một phiên đăng nhậ Giải pháp ạo n n tp t ề ảng cơ s giúp cho ởBệnh viện có thể xây dựng nghiệp vụ quản lý tập trung Nâng cao trải nghiệm, tính thân thi n, dệ ễ ử ụ s d ng, tính b o m thông tin ả ật cho người dùng, tính an toàn, tính

b o m t, tính khôi phả ậ ục, sao lưu khôi phục dữ ệ li u cho h th ng ệ ố Tăng cường ứng

dụng Công nghệ thông tin (CNTT) trong quản lý hành chính ệnh viện góp phần b

hiện đại hóa, ti n t i m c tiêu xây d ng Bế ớ ụ ự ệnh viện thông minh

Đối tượ ng nghiên c u c a lu n văn ứ ủ ậ bao gồm: Cơ chế đăng nhập một lần SSO, giao th c OAuth2, mô hình trang thi t b h t ng ứ ế ị ạ ầ

Phạm vi nghiên cứu của luận văn: Hệ ố th ng CNTT t i B nh vi n Y h c ạ ệ ệ ọ

c truyổ ền Trung ương

Để ự th c hiện được mục đích nghiên cứu nêu trên, 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ết hợp với

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 ủ c a luận văn tôi s khái quát l i các khái ni m v h ẽ ạ ệ ề ệ

thống đăng nhập một lần SSO và giao thức chuẩn OAuth2 Dựa trên điều kiện

thực tế ại đơn vị công tác ủa bả t c n thân xuđể đề ất giải pháp xây dựng hệ ố th ng đăng nhập m t l n, mô hình h t ng thi t b cho phù h p và t ng k t l i các k t ộ ầ ạ ầ ế ị ợ ổ ế ạ ế

qu ả đạt được, các kết lu n mậ ới, đề xu t ấ hướng phát tri n ể

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

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

Chương 1: Cơ chế đăng nh p m t l n (SSO): Trình bày các v ậ ộ ầ ấ n đ ề liên

điểm, r i ro khi tri n khai) ủ ể

Chương 2: Giao th c OAuth2: Trình bày các vứ ấ n đ ề liên quan đến giao

khác, ưu, nhược điểm)

Chương 3: Đề xu t gi i pháp xây d ng h th ng SSO s d ng giao th c ấ ả ự ệ ố ử ụ ứ

OAuth2 tại Bệnh viện YHCTTW: Trình bày v các về ấ n đ ề liên quan đến giải

pháp xây d ng hự ệ ố th ng SSO sử ụ d ng giao th c OAuth2 t i B nh viứ ạ ệ ện YHCTTW

(bài toán thực tế, giải pháp, mục tiêu của giải pháp, ưu điểm, nhược điểm của

nghi m ệ

Chương 4: ế K t lu n và đ xu t hư ng phát tri n: T ậ ề ấ ớ ể ổng kết các kết quả đạt

pháp

Ph l c tài liụ ụ ệu tham khảo

CHƯƠNG 1: CƠ CHẾ ĐĂNG NHẬP M T L N (SSO) Ộ Ầ

1.1 Gi i thiớ ệu về SSO

1.1.1 Khái niệm

Đăng nhập một lần (SSO) là dịch vụ xác thực phiên và người dùng cho phép người dùng cuối nhập một bộ thông tin đăng nhập (có thể gồm tên và mật khẩu) để có quyền truy cập vào nhiều ứng dụng Trong dịch vụ web SSO cơ bản, module agent trên máy chủ ứng dụng sẽ truy xuất thông tin xác thực cho từng người dùng từ máy chủ SSO chuyên dụng, đồng thời xác thực chéo người dùng qua kho lưu trữ người dùng dưới dạng thư mục LDAP[15] Dịch vụ xác thực người dùng cuối cho tất cả các ứng dụng mà người dùng đã được cấp quyền và loại bỏ lời nhắc nhập mật khẩu tiếp theo cho các ứng dụng riêng lẻ trong cùng một phiên[10].

Hình 1: Gi i thi u v ớ ệ ề SSO[10]

Trước khi có SSO, người dùng phải quản lý nhiều tài khoản và mật khẩu khác nhau để truy cập các ứng dụng website, phần mềm, hệ thống khác nhau

Điều đó gây khó khăn cho người dùng trong việc quản lý tài khoản, ghi nhớ và

sử dụng các tài khoản một cách nhanh chóng Do đó hệ thống SSO sẽ đem lại , nhiều thuận tiện cho người dùng trong việc quản lý thay vì quản lý trên nhiều tài khoản khác nhau thì chỉ phải quản lý một tài khoản duy nhất Tuy nhiên, việc bảo mật trên một tài khoản duy nhất như “1 con dao 2 lưỡi”, việc quản lý tài khoản,

sử dụng một tài khoản sẽ dễ dàng, thuận tiện hơn rất nhiều nhưng đồng thời rủi

ro, sự thiếu an toàn thông tin bảo mật cũng bị đẩy lên cao Nếu không may tài khoản gốc bị tin tặc đánh cắp thì một loạt thông tin cá nhân sẽ bị truy cập trái phép Do vậy, hệ thống SSO nên kết hợp các loại hình xác thực khác nhau được

trình bày trong mục 1.1.2 để tăng cường tính bảo mật của hệ thống là điều rất

quan trọng

Đăng nhập là quá trình người dùng sử dụng định danh và các thông tin bảo mật khác để kết nối bảo mật với hệ thống, thông thường là dùng ID (Identification) và mật khẩu Quá trình đăng nhập gồm 2 bước xác thực và thẩm định (ủy quyền):

- Xác thực (Authentication): Xác thực người dùng có hợp lệ không thông qua các phương thức xác thực của hệ thống phổ biến nhất là, username/password, ngoài ra còn một số phương pháp xác thực khác

- Thẩm định (ủy quyền) (Authorization): Là quá trình kiểm tra sau khi người dùng đã được xác thực có đồng ý ứng dụng bên thứ 3 truy cập vào tài nguyên lấy thông tin người dùng hay không?

1.1.2 Các phương pháp xác thực

Xác thực (Authentication) là một hành động nhằm chứng thực một người, một cá nhân hay một đối tượng nào đó Xác thực cho phép xác định đối tượng sử dụng hiện tại là ai và có mặt ở đây hay không? Theo cách hiểu đơn giản nhất, quá trình xác thực (Authentication) là đi tìm câu trả lời cho câu hỏi “Bạn là ai?” Các phương pháp xác thực có thể chia thành 3 loại dựa theo các đặc điểm của chúng

Hình 2: Phân loại các phương thức xác thực[12]

Knowledge-based authentication [12] (xác thực theo tri thức): Đây là phương thức s d ng r ng rãi nh t hiử ụ ộ ấ ện nay Phương thức s d ng m t kh u ử ụ ậ ẩ

bằng các chuỗi ký tự, hình ảnh, nhận dạng khuôn mặt hay sử ụng mã số cá nhân d(PINs) Đố ới v i mạng Internet không đảm b o v ả ề an ninh, để xác thực thường s ử

d ng ụ chứng ch s (ỉ ố Digital Certificates) and chữ ký s (ố Digital Signatures) Chúng được cung c p b i m t h t ng khóa công khai (PKI) bao g m m t c p ấ ở ộ ạ ầ ồ ộ ặkhóa mật mã công khai và riêng tư

Possession-based authentication [12] (xác thực theo sự ở ữ s h u): Dựa vào

những gì mà người dùng có phổ ến là các loại thẻ ừ Tuy nhiên nhược điểm , bi t

của phương thức này là thẻ cá nhân có thể ị b chiếm đoạt hay lấy cắp bởi các thủđoạn tinh vi Vì v y ậ phương thức này ph i k t h p gi a th và các lo i mã PIN ả ế ợ ữ ẻ ạ

để có th s d ng ể ử ụ

Biometric-based authentication [12] (xác thực theo sinh trắc họ Đây là c):phương thức xác th c d a trên các đự ự ặc điểm sinh lý, hành vi của người dùng, đó

là các đặc điểm đã được chứng minh là có th xác thể ực như vân tay, võng mạc,

khuôn m t, gi ng nóiặ ọ … Phương thức này đem lại hiệu quả ảo mật rất cao vì nó bkhông d dàng bễ ị đánh cắp Tuy nhiện phương thức này chủ ếu đượ y c s d ng ử ụtrong các hệ ố th ng quan trọng, nơi yêu cầu độ ả b o m t cao vì chi phí tri n khai ậ ể

r t l n ấ ớ

SSO hoạt động theo các bước tuần tự như sau:

1 Người dùng lần đầu truy c p domain1 ậ

2 Domain1 s chuyẽ ển hướng 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 đăng

nh p ậ

4 AuthServer th c hi n ự ệ lưu ‘cookie’ v i thông tin xác thớ ực của domain1

5 AuthServer g i ‘token’ và chuyử ển hướng 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 ực nhậth n được

8 Người dùng lần đầu truy c p domain2 ậ

9 Domain2 chuyển hướng v ề trang login AuthServer để xác thực người dùng

10 AuthServer nh n thông tin t ‘cookie’ ậ ừ ở bước 4 để ể ki m tra xác th c ự

11 AuthServer g i ‘token’ và chuyử ển hướng 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ự ệ lưu trữn ‘cookie’ với thông tin ‘token’ xác thực

nhận được

1.2 Các giao th c xác thứ ực SSO phổ biến

Giao thức xác thực là loại giao thức mã hóa với mục đích chứng thực các đối tượng Hiện nay có rất nhiều các giao thức xác thực được sử dụng (Pap, Chap, Radius, Kerberos, Open Id, OAuth2, Saml2…) , tuy nhiên phổ biến nhấthiện nay là các giao thức: OAuth2, Open Id, Saml2 vì chúng tuân theo chuẩn chung và có nhiều ưu điểm và giao thức Kerberos những năm gần đây bắt đầu được sử dụng nhiều hơn

1.2.1 Giao thức OpenID

 Khái ni m ệ

OpenID là một chuẩn mở cho xác thực (Authentication) Được phát triển bởi tổ chức phi lợi nhuận ‘OpenID Foundation’, OpenID cho phép người dùng

có thể được xác thực bởi rất nhiều website sử dụng dịch vụ của bên thứ ba

Người dùng có thể đăng nhập tới nhiều webstie không hề liên quan tới nhau mà không cần dùng những định danh (Username) và mật khẩu (Password) riêng cho

 Cách thức hoạt động ủ c a OpenID Connect

Hình 4: Cách th c hoứ ạt động c a ủ OpenID Connect[16]

Quy trình hoạt động diễn ra theo các bước như sau[16]:

(A) Người dùng s truy c p bên th ba và yêu c u truy c p; ẽ ậ ứ ầ ậ

(B) Bên th 3 gứ ửi ‘Authentication_request’ cho OpenID provider, mô tả

‘scope’ s ẽ được yêu c u và ầ ‘Response_type’ mu n nhố ận được;

(C) OpenID provider yêu c u user xác nhầ ận danh tính sau đó sẽ cho phép bên th ứ 3 các quyền trong ‘scope’;

(D) OpenID provider g i l i bên thử ạ ứ 3 ‘Authentication_Response ch a ’ ứthông tin mu n ố ở bước (A) thường s là ẽ ‘ID_Token’ và ‘Access_token’;

(E, F) Bên th 3 sứ ẽ dùng ‘Access_token’ để trao đổi thông tin mà mình mong mu n ố

1.2.2 Giao th c SAML ứ

 Khái ni m: ệ

SAML (Security Assertion Markup Language) là giao thức ‘chuẩn mở’ cho phép nhà cung cấp nhận dạng (Identity Provider) 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ụ nào đó của nhà cung cấp dịch vụ (Service Provider) mà không bắt buộc người dùng phải tạo tài khoản đăng nhập vào dịch vụ đó[5]

 Cách thức hoạt động:

Các thành ph n chính ầ

- Identity Provider (IdP): Nhà cung c p nhấ ận dạng

- Service Provider (SP): Nhà cung c p d ch v ấ ị ụ

- SP Private Key: Được th ng nhố ất, trao đổi trước gi a SP và IdP b ng cách ữ ằnào đó

Hình 5: Cách th c hoứ ạt động của SAML[5]

Quy trình hoạt động diễn ra theo các bước như sau[5]:

Bước 1: Người dùng th c hi n 1 yêu c u ự ệ ầ đăng nhậ ớp t i SP

Bước 2: Phía SP s t o ra m t ‘ẽ ạ ộ SAML_Request ’ để g i t i IdP, ử ớ

‘SAML Request _ ’ này sẽ được chính SP ký điện tử (sign) bằng chữ ký của SP ‘ ’ (ch ký cữ ủa SP ở đây chính là khóa bí mật của SP)

Bước 3: Phía IdP khi nhận được ‘SAML_Request t SP s ph i xác th c ’ ừ ẽ ả ựchữ ký có đúng là của SP hay không b ng cách dùng khóa private (SP private ằkey) của SP để xác thực

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

- Lấy ra thông tin người dùng đang sử ụng browser (nếu người dùng đang dđă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 đăng nhập trước) đ chuyể ển hướng (http post) v cho SP sử ụề d ng (k t qu ế ả

tr v ả ề này mình gọi là ‘SAML_Response’) Trước khi gửi về cho SP thì IdP sẽ

ký điệ ửn t (sign) vào ‘SAML_Response’ bằng khóa bí m t c a IdP ậ ủ

- Không những IdP ký vào ‘SAML_Response’ mà IdP cũng sẽ mã hóa 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 đư c ‘SAML_ậ ợ Response , nó s th c hi n nh ng vi c ’ ẽ ự ệ ữ ệsau:

- Dùng khóa công khai của IdP để xác thực 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ể ấy thông qua lmetadata url c a IdP ho c có th ủ ặ ể đượ trao đổi trước.c

- Nếu xác thực đúng chữ ký, SP sẽ ếp tục dùng khóa công khai của chính timình để ả gi i mã ‘SAML_Assertions’đã được mã hóa t phía IdP ừ

- Lấy các thông tin dữ ệu người dùng trong ‘SAML_Assertions’ để đăng li

nhập người dùng vào hệ ống của chính mình, và trả ề cho người dùng thông th v báo thành công

1.2.3 Giao thức OAuth2

 Khái ni m ệ

OAuth2 là một giao thức chuẩn mở để thẩm định (ủy quyền) (Authorization), OAuth2 cũng là nền tảng của OpenID Connect, nó cung cấp OpenID xác thực (Authentication) ở phía trên của OAuth2 thẩm định (ủy quyền) (Authorization) để có một giải pháp bảo mật hoàn chỉnh hơn[2]

 Cách thức hoạt động:

Các thành phần chính:

- Resource Owner: Một thực thể có khả năng cấp quyền truy cập vào một tài nguyên được bảo vệ Khi chủ sở hữu tài nguyên là một người, nó được gọi là người dùng cuối

- Resource Server: Máy chủ lưu trữ các tài nguyên được bảo vệ, có khả năng chấp nhận và đáp ứng các yêu cầu tài nguyên được bảo vệ bằng

Hình 6: Cách th c hoứ ạt động của OAuth2[1]

Quy trình hoạt động diễn ra theo các bước như sau[1]:

A Client yêu cầ ủy quyền để truy cập vào Resource Server thông qua u Resource Owner

B Nếu Resource Owner ủy quyền cho yêu cầu trên, Client sẽ nhận đư c ợ

gi y ấ ủy quy n tề ừ phía Resource Owner (dưới dạng một ‘token’ string nào đó chẳng hạn)

C Client ửi thông tin định danh (ID) của mình kèm theo giấ ủy quyền g y

của Resource Owner ớ t i Authorization Server

D Nếu thông tin định danh được xác thực và giấ ủy y quy n h p lề ợ ệ, Authorization Server sẽ ả ề tr v cho Client ‘Access_token’ Đến đây quá trình ủy quy n hoàn t t ề ấ

E Để truy c p vào tài nguyên (resource) t ậ ừResource Server và l y thông ấtin, Client ẽ s phải đưa ra ‘Access_token’ để xác thực

F 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 ầ Client

1.2.4 Giao thức Kerberos

 Khái ni m:ệ

Kerberos[13] là một giao thức mật mã dùng để xác thực trong các mạng máy tính hoạt động trên những đường truy n không an toàn Giao th c Kerberos có ề ứ

kh ả năng chống lại việc nghe lén hay gửi lại các gói tin cũ và đảm bảo tính toàn

vẹn của dữ ệu Mục tiêu khi thiết kế giao thức này là nhằm vào mô hình client li - server và đảm b o xác th c cho c hai chi u Giao thả ự ả ề ức được xây d ng d a trên ự ự

mã hoá đố ứi x ng và cần đến m t bên th ba mà c hai phía tham gia giao d ch tin ộ ứ ả ịtưởng

 Cách thức hoạt động [13]:

Hình 7: Cách th c hoứ ạt động c a Kerberosủ [13]

Kerberos không xây d ng các giao thự ức chứng th c phự ức tạp cho m i máy ỗ

chủ mà hoạt động d a trên m t máy ch ự ộ ủ chứng th c tập trung KDC (Key ựDistribution Centre) KDC cung c p vé cho viấ ệc chứng thực người dùng và bảo

m t truy n thông b i khoá phiên trong vé g m 3 pha ậ ề ở ồ và 6 bước trao đổi

- Pha 1: Client chứng thực AS (Authentication Server) ết khoá mật của bi

t t c ấ ả người dùng được lưu giữ trên một cơ sở ữ ệ ậ d li u t p trung)

+ AS_REQ là yêu cầu người dùng xác th c ban đầự u (kh i t o dich v ) yêu ở ạ ụ

cầu này được chu ển trực tiếp tới các thành phần được gọi là KDC yAuthentication Server (AS);

+ AS_REP là trả ời của máy chủ l xác th c đểự yêu cầu trước đó Về cơ b n ả

nó ch a TGT (mã hóa b ng cách sứ ằ ử ụ d ng khóa TGS bí mật) và khóa phiên (được

mã hóa b ng khóa bí m t cằ ậ ủa người dùng yêu c u) ầ

- Pha 2: Client xác thực TGS (Ticket Granting Server) cung cấp vé dịch

v ụ cho phép người dùng truy nhập vào các máy chủ trên mạng)

+ TGS_REQ là yêu cầu từ khách hàng đến (TGS) cho một vé thông hành

V ề cơ bản nó chứa TGT (mã hóa bằng cách sử ụng khóa TGS bí mật) và khóa dphiên (được mã hóa b ng khóa bí m t cằ ậ ủa người dùng yêu c u); ầ

+ TGS_REP là trả ờ l i của Cấp vé máy ch yêu củ để ầu trước đó.Nằm bên trong là vé dịch vụ theo yêu cầu (được mã hóa v i khóa bí mớ ật của dịch vụ) và phiên d ch vị ụ một khóa t o ra bạ ởi TGS và được mã hóa bằng khóa phiên trước

đó đượ ạc t o ra b i ở AS

- Pha 3: Khách hàng truy cập và được cấp phép s ử dung dịch v ụ

+ AP_REQ là yêu cầu khách hàng gửi tới một máy chủ ứ ng dụng để truy

cập vào một dịch vụ Các thành phần là các dịch vụ bán vé thu được từ TGS ới vthư trả ời trướ l c và nh n th c m t l n nậ ự ộ ầ ữa đượ ạc t o ra bởi khách hàng, nhưng lần này được mã hóa b ng khóa phiên d ch (t o ra b i ằ ị ạ ở TGS);

+ AP_REP là trả ời rằng các máy chủ ứng dụng cung cấp cho khách hàng l

để ch ng minh nó th c s là máy ch c a khách hàng là mong mu n Gói này ứ ự ự ủ ủ ốkhông phải lúc nào cũng được yêu c u Các khách hàng yêu c u máy chầ ầ ủ cho nó

chỉ khi xác thực lẫn nhau là c n thi t · ầ ế

Lưu ý t t c các trao đấ ả ổi giữa các máy đều dược đóng dấu th i gian ờ

‘Timestamp’

1.3 M t s sộ ố ản phẩ SSO đã được ển khai ởm tri b i các công ty l n ớ

B ng 2: Danh sách mả ột số ả s n phẩm SSO đã được tri n khai b i các công ty l n ể ở ớ

Client-side implementation with plugins for various services/protocols Active

web access management system that enables user authentication and secure Internet SSO (single sign-on), policy-driven authorization, federation of identities (SAML and OIDC)

C, and complete auditing of all access to the web applications it protects Facebook

connect Facebook

Proprietary

Facebook SSO to third parties enabled by Facebook

FreeIPA Red Hat Free

Mô t ả

solution with single sign-on (SSO), Multi Factor Authentication and Active Directory integration

IceWall SSO

Packard Enterprise

Hewlett-Proprietary

Web and Federated Single Sign-On Solution

to map different identities and hence allow single signon to all IBM server platforms (Windows, Linux, PowerLinux, IBM i, i5/OS, OS/400, AIX) even when the user name differs

Mô t ả

and single sign on Red Hat Single Sign-On is version of Keycloak for which RedHat provides commercial support

OpenAM

Open Identity Platform Community

CDDL

Yes, used in conjunction with OpenD

J and OpenI

DM

Access management, entitlements and federation server platform

Oracle

Identity

Management

Oracle Corporation

Propriet

Identity and Access Management Suite of products from Oracle

SecureLogin NetIQ Propriet

ary Enterprise Single-Sign-On

Shibboleth Shibboleth

Free &

Open Source (Apache 2.0)

SAML-based open source access control

Ubuntu

Single Sign

On

Canonical Ltd

Proprietary

OpenID-based SSO for Launchpad and Ubuntu

services WSO2

Yes

SAML 2.0, OpenID, OpenID Connect, OAuth 2.0, SCIM, XACML, Passive Federation

Mô t ả

(Apache 2.0)

Software Yes

Reference Implementation of

TAS3 security Ideal

Identity

Management

Data Market Corporation

Proprietary Y es

Ideal Identity Management Suite of products from Data

lý tập trung

- Đối với ngườ ử ụi s d ng: H thệ ống SSO giúp cho người dùng trong việc quản lý tài khoản, ghi nhớ và sử dụng các tài khoản một cách nhanh chóng, dễ dàng hơn thay vì quản lý nhiều tài khoản thì người dùng phải quản lý một tài khoản duy nhất, điều này là ưu điểm đồng thời cũng là rủi ro của hệ thống SSO trong vấn đề bảo mật của người dung, nâng cao tr i nghi m, tính thân thi n, d ả ệ ệ ễ

s dử ụng cho người dùng

- Đố ớ i v i ngườ i qu n trị hệ thống: ả

+ Người qu n tr ỉ ầả ị ch c n b o m t và quả ậ ản lý thông tin đăng ký của người dùng m t l n, vì v y có thộ ầ ậ ể giảm dung lượng cơ sở ữ ệu và tránh đượ d li c các

xung độ ảt n y sinh do ph i x lý m t kh u c a các h thả ử ậ ẩ ủ ệ ống khác nhau, tăng khảnăng mở ộ r ng và tri n khai các chiể ến lược b o m t ả ậ

+ Người qu n tr có th ả ị ể thay đổi và c p nhậ ật thông tin được bảo mật của người dùng khi c n thi t, m t cách d ầ ế ộ ễ dàng hơn so với việc thay đổ ở ừi t ng h ệ

thống riêng lẻ mà người dùng đó được phép truy cập Điều này rất hữu ích khi người dùng thay đổ ịi v trí c a mình v i các củ ớ ấp độ ả b o m t khác nhau ậ

 Nhượ c đi m: ể

- Để có th triể ển khai mộ ệ ốt h th ng SSO theo đúng nghĩa và tăng cường tính năng bảo m t c a h th ng thì c n t n kém c v nhân l c, ngu n l c, kinh phí ậ ủ ệ ố ầ ố ả ề ự ồ ự

Do v y c n có k ho ch rõ ràng ậ ầ ế ạ trước và trong quá trình tri n khai ể

- Việc xử lý một loạt các hệ thống con có tích hợp giải pháp SSO không đơn giản, b i vì m i h th ng con có th hoở ỗ ệ ố ể ạt động trên các n n ph n c ng và ề ầ ứ

phần mềm khác nhau Vì vậy, khi cài đặt sẽ phải giải quyết nhiều vấn đề liên quan đến tính tương thích và đồng b gi a các h th ng ộ ữ ệ ố

- Các kỹ thuật mang tính mở áp dụng với hệ ống hoặc chưa được chuẩn thhóa, hoặc chưa được cung c p, có th gây mâu thuấ ể ẫn và không tương thích với các sản ph m khác ẩ

 R i ro: ủ

- Mặc dù đăng nhập một lần là một tính năng rất tiện lợi đối với người dùng, nhưng lại tiềm ẩn nhiều rủi ro trong việc bảo mật Khi mà kẻ tấn công khi giành quyền kiểm soát thông tin đăng nhập SSO của người dùng sẽ có quyền truy cập vào mọi ứng dụng mà người dùng có thể truy cập, dẫn đến gia tăng mức độ thiệt hại rất lớn

- Để tránh các truy cập trái phép, điều cần thiết là toàn bộ các yếu tố khi triển khai SSO cần phải được kết hợp với quản trị định danh chặt chẽ, các loại hình xác thực phù hợp để nâng cao tính bảo mật của hệ thống và điều này cũng

liên quan đến nhược điểm của SSO

CHƯƠNG 2: GIAO TH C OAUTH2 Ứ

2.1 Gi i thiớ ệu về OAuth2

OAuth2[3] là một chuẩn mở để xác thực (Authentication), thẩm định (ủy quy n) ề (authorization) nhờ đó ứng dụng bên thứ 3 có thể đại diện cho người dùng truy cập vào tài nguyên người dùng n m trong mằ ột dịch v ụ nào đó

OAuth2 = Open + Auth (Authentication: xác thực người dùng thông qua

việc đăng nhập, Authorization: cấp quyền truy c p vào các Resource).ậ

- Resource Server: Máy chủ lưu trữ các tài nguyên được bảo vệ, có khả năng chấp nhận và đáp ứng các yêu cầu tài nguyên được bảo vệ bằng

Hình 8: Sơ đồ ồ lu ng hoạt động OAuth2[3]

Sơ đồ ồ lu ng hoạt động OAuth2 theo tu n t sau: ầ ự

Bước 1: Application yêu cầu ủy quyền đ ểtruy c p vào ậ Resource Server thông qua User

Bước 2: N u User y quy n cho yêu c u trên, Application s nhế ủ ề ầ ẽ ận được

gi y y quy n ấ ủ ề (Authorization_code) ừ t phía User

Bước 3: Application gửi thông tin định danh (ID) c a mình kèm theo ủ

‘Authorization_code’ ủa c User t i Authorization Server ớ

Bước 4: Nếu thông tin định danh được xác th c và ‘Authorization_code’ ự

hợp lệ, Authorization Server ẽ ả ề s tr v cho Application ‘Access_token’ Đến đây quá trình y quy n hoàn t t ủ ề ấ

Bước 5: Để truy c p vào tài nguyên t ậ ừ Resource Server và l y thông tin, ấApplication s phẽ ải đưa ra ‘Access_token’ xác thđể ực

Bướ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 Application ầ

2.2.3 Đăng ký thông tin ứng dụng[3]

Trước khi tích h p OAuth2 c a m t d ch v ợ ủ ộ ị ụ được cung c p (Facebook, ấGithub, Google) trong ng d ng Cứ ụ ần phải đăng ký ứng d ng vụ ới dịch vụ đó với các thông tin chính:

Application name: Tên ng d ng ứ ụ

Applcation website: Trang web ng d ng ứ ụ

Chuyển hướng URL hay Callback URL: Đường dẫn của ứng dụng để nh n ậ

kết quả khi quá trình ủy quyền hoàn tấ , nhận các thông tin như mã ủy quyềt n,

‘Access_token’

2.2.4 ClientID và Client Secret [3]

Sau khi đăng ký ứng d ng v i d ch v , ClientID và Client Secret s ụ ớ ị ụ ẽ được

Yêu c u có dầ ạng như sau:

https://API_SERVER.DOMAIN/v2/$OBJECT

V i request header: ớ

Accept: application/json

Authorization: Bearer ‘ACCESS_TOKEN’

Gi s mã thông báo truy c p là h p l , API s x lý yêu c u theo thông s ả ử ậ ợ ệ ẽ ử ầ ốAPI c a nó N u mã thông báo truy củ ế ập đã hết hạn hoặc nếu không thì không h p ợ

l , API s v l i không h p l ệ ẽ trả ề ỗ ợ ệ

2.2.5.2 Yêu cầu gửi ‘Access_token’ ớ m i [3]

M i ‘Access_token’ ỗ thường có thời gian sống nhất định Khi truy cập tài nguyên nếu ‘Access_token’ hết h n Appplication sạ ẽ nhận được mã l i “Invalid ỗ

‘token’ Error” Lúc này application phải gửi một yêu cầu đến Auth Server để

th c hi n l y ‘Access_token’ mự ệ ấ ới dướ ại d ng POST request

https://OAUTH_SERVER.DOMAIN/oauth/’token’?grant_type=refresh_’token’

&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&refresh_’token’=REFRESH_’TOKEN’

2.3 Các cấp ủy quyền

Trong sơ đồ lu ng hoồ ạt động OAuth2, y quy n (Authorization Grant) ủ ềđược s d ng b i ng dử ụ ở ứ ụng để ấ l y ‘Access_token’ V i ‘Access_token’ ng ớ ứ

dụng được cấp phép để ấy đượ l c tài nguyên của người dùng

Các dạng y quy n ph thuủ ề ụ ộc vào cách thức ứng d ng yêu c u xác thụ ầ ực và

d ng y quyạ ủ ền được hỗ ợ ở tr b i máy ch y quy n (Authoủ ủ ề rization server)

2.3.1 Cấp ủy quyền sử ụ d ng mã ủy quyền (Authorization Code) [3]

Đây là hình thứ ủc y quy n ph bi n nh t ề ổ ế ấ hay đượ ử ục s d ng hi n nay ệ

Hình 9: Sơ đồ hoạt động Authorization Code[3]

 Sơ đồ hoạt động Authorization Code tuần tự như sau:

Người dùng truy c p ng d ng ậ ứ ụ

1 Yêu cầu Authorization_code

Application g i User ử link đến nơi để ắt đầ b u quá trình nh n ậ

Authorization_code

https://OAUTH_SERVER.DOMAIN/oauth/authorize?response_type=‘token’&client_id=CLIENT_ID&chuyển hướng_uri=CALLBACK_URL&scope=read

2 User ủy quyền cho Application

Khi User truy cập vào link, nhập thông tin xác thực người dùng Sau khi xác th c xong, ự User s ẽ được hỏi có cho phép/ từ ch i ố Application truy cập thông tin c a mình không? ủ

3 Application nhận Authorization_code

Nếu User cho phép Application truy cập vào thông tin cá nhân, Auth Server

s chuyẽ ển hướng người dùng đến ApplicationChuyển hướ URL ( đã đăng ký ởngbước 2.3.3) Tại đây Application sẽ lưu lại Authorization_code

https://APPLICATION.DOMAIN/callback?code=AUTHORIZATION_CODE

4 Application yêu cầu ‘Access_token’

Sau khi nhận được Authorization_code Application c n th c hiầ ự ện request lên Auth Server để ấ l y ‘Access_token’

https://OAUTH_SERVER.DOMAIN/oauth/’token’?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=Authorization_code&code=AUTHORIZATION_CODE&chuyển hướng_uri=CALLBACK_URL

5 Application nhận ‘Access_token’

Nếu quá trình ủy quyền (authorization) thành công Auth Server sẽ chuyển hướng người dùng v chuyề ển hướngURL kèm theo ‘Access_token’

https://APPLICATION.DOMAIN/callback#’token’=‘ACCESS_TOKEN’

Lúc này Application đã được User y quy n truy c p Application có th s ủ ề ậ ể ử

d ng ‘Access_token’ ụ để truy cập tài nguyên của dịch vụ đã được User cho phép cho t i khi ‘Access_token’ h t hớ ế ạn sử ụ d ng

2.3.2 Cấp ủy quyền ngầm định (Implicit) [3]

Lo i ạ ủy quyền này thường được sử ụng cho các ứng dụng di động hay các d

ứng d ng ch y trên trình duy t ( vd: FireFox Extension) Vì lí do không th b o ụ ạ ệ ể ả

mật được thông tin Authorization_code tại Client Loạ ủy quyền này không thực i

hi n xác th c ID c a Application, không c n phệ ự ủ ầ ải trao đổi Authorization_code Implicit không h tr ‘ỗ ợ refesh_token’

Hình 10: Sơ đồ hoạt động Implicit[3]

 Sơ đồ hoạt động Implicit tuần tự như sau:

1 Implicit Authorization Link

Tương tự Authorization Code, User được đưa t i mớ ột link để yêu c u ầ

‘Access_token’ t Auth Server (v i response_type là ‘token’) ừ ớ

https://OAUTH_SERVER.DOMAIN/authorize?response_type=‘token’&client_id=CLIENT_ID&chuyển hướng_uri=CALLBACK_URL&scope=read

2 User ủy quyền cho Application

Khi User truy cập vào link, nhập thông tin xác thực người dùng Sau khi xác th c xong, ự User s ẽ được hỏi có cho phép/ từ ch i ố Application truy cập thông tin c a mình không? ủ

3 Browser nhận ‘Access_token’ thông qua chuyể n hư ng ớ URI

Sau khi User c p phép cho Application Auth Server sấ ẽ chuyển hướng về chuyển hướng URI (đã đăng ký ở bước trước đó)

https://APPLICATION.DOMAIN/callback#’token’=‘ACCESS_TOKEN’

4 Browser duy trì ‘Access_token’

Sau khi Browser được chuyển hướng v chuyề ển hướng URI, nhi m v c a ệ ụ ủbroser là duy trì ‘Access_token’ và điều hướng quay tr l i ng dở ạ ứ ụng

5 Application trích xu t ‘Access_token’ ấ

Sau khi điều hư ng, ‘Access_token’ ớ được trích xu t kèm các thông tin khác ấ

t chuyừ ển hướng URI

6 ‘Access_token’ được gửi đến Application

Thông tin ‘Access_token’ trích xuấ ở bước 5 được đính kèm khi điềt u hướng quay tr l i Application ở ạ

Lúc này quá trình quá trình xác th c, y quy n hoàn t t ự ủ ề ấ

2.3.3 Cấp ủy quyền bằng password (Password) [3]

Loại ủy quyền này đư c sử dụng cho những ứng dụợ ng đư c tin tư ng bởi ợ ởAuth Server Lúc này User ph i cung cả ấp username, password trực tiếp cho Application để lấy ‘Access_token’ Quá trình diễn ra hết sức đơn gi n và nhanh ảchóng

https://OAUTH_SERVER.DOMAIN/’token’?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID

2.3.4 Cấp ủy quyền bằng thông tin ng d ng (Client Credentials)ứ ụ [3]

Lo i ạ ủy quyền này được sử ụng cho việc truy cập vào chính thông tin tài dkhoản của Application tại dịch ụ để ấy thông tin của Application hay cập nhật v lthông tin (mô t , chuyả ển hướng_uri…) Tại đây không có sự tham gia c a User ủ

https://OAUTH_SERVER.DOMAIN/’token’?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

2.4 Ưu điểm và nhượ c đi m củ ể a OAUTH2

 Ưu điểm:

- Tính đa dạng, có thể ết nố ới nhiều nền tảng khác nhau B k i v : ạn có thể

s dử ụng OAuth 2.0 để đọc dữ ệu của người dùng từ li m t ộ ứng dụng khác Nó cung c p quy trình authorization cho web, ng dấ ứ ụng máy tính để bàn và thiết bị

di động Đây là mộ ứt ng d ng web phía máy ch s d ng authorization code và ụ ủ ử ụkhông tương tác với thông tin đăng nhập của người dùng

- Tính ảo mật, tính an toà OAuth 2.0 là một giao thức dựa trên SSL b n:(Secure Sockets Layer) m b o d u giđả ả ữ liệ ữa máy chủ web và trình duy t v n gi ệ ẫ ữđược tính riêng tư để lưu token truy cậ p của người dùng OAuth 2.0 d a trên ựSSL, được s dử ụng để đả m b o các giao th c b o mả ứ ả ật và đang được s dử ụng để

gi an toàn cho d li u ữ ữ ệ

- Tính riêng tư: Nó cho phép truy cập hạn chế vào dữ ệu của người dùng li

và cho phép truy c p khi authorization token h t h n 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 Nó dễ dàng hơn để

- Nếu các trang web yêu thích của bạn được kết nối với máy chủ trung tâm

và tài kho n trung tâm b hack, thì nó sả ị ẽ ẫn đế d n các ảnh hưởng nghiêm trọng trên m t s ộ ố trang web liên k t thay vì ch m t ế ỉ ộ

CHƯƠNG 3: ĐỀ XU T GI I PHÁP XÂY D NG H TH NG SSO S Ấ Ả Ự Ệ Ố Ử

D NG GIAO TH C OAUTH2 TỤ Ứ ẠI BỆNH VI N YHCTTW Ệ

3.1 Gi i thiớ ệu ề ứng dụv ng CNTT t Bại ệnh viện Y Học cổ truyền TW

3.1.1 Giới thiệu chung ề ệnh việ v B n

Bệnh viện Y học cổ truyền Trung ương là bệnh viện đầu ngành về YHCT - Trung tâm h p tác v y hợ ề ọc cổ truy n ề (YHCT) của Tổ chức y tế ế ớ th gi i t i Viạ ệt Nam B nh vi n có 34 khoa phòng vệ ệ à trung tâm được chia thành 4 kh i: lâm ốsàng, c n lâm sàng, c c trung tâm vậ á à khối các phòng ban chức năng Bệnh viện

có 500 cán b , công ch c, viên chộ ứ ức, người lao động B nh việ ện có 630 giường bệnh, có các khoa lâm sàng Nội, Ngoại, Phụ, Nội Nhi, Châm cứu dưỡng sinh, Lão, Hồi sức cấp cứu, Da liễu, Ki m so t vể á à Điều trị Ung bướu, Khám chữa

bệnh tự nguyện chất lượng cao, Khoa khám bệnh, Khoa thận tiết niệu và nam

h cọ , Khoa đa khoa ngũ quan, Khoa cơ xương khớp; với đầy đủ các trang thiết bị

hiện đại để phục vụ cho chẩn đoán, điều tr và nghiên c u khoa h c K t khi ị ứ ọ ể ừthành l p, v i chậ ớ ức năng và nhiệm vụ chính là kế thừa, phát huy và phát triển YHCT, kết hợp YHCT với YHHĐ trong điều trị và d ựphòng, b nh việ ện đã đạt đượ ấc r t nhi u thành t u trong phát tri n YHCT ề ự ể

3.1.2 H tạ ầng trang thiế ị ứt b , ng d ng CNTT t i Bụ ạ ệnh viện

Bệnh viện hiện đang có 5 tòa nhà triển khai hạ ầng hệ t thống mạng H ệ

thống mạng của Bệnh viện v khoới ảng 200 máy tính bao gồm máy bàn và một sốmáy laptop, trong đó khoảng một nửa số máy tính được phép kết nối ra ngoài Internet, m t nộ ửa chỉ được phép kết nối m ng Lanạ Trong đó có 7 máy chủ phục

v ụ các hoạt động, ứng dụng CNTT của Bệnh việ Các máy chủ chủ ếu chạy hện yđiều hành Windows Server 2012 R2 Các máy tr ạm m t s ộ ố cài windows XP, đa

s ố cài các hệ điều hành khác như Windows 7, Windows 10, hầu hết trong số đó đều cài chương trình diệt virus Kaspersky b n quy n Các thi t b mả ề ế ị ạng như Core Switch, Switch, Router, Firewall c ng (FireWall Fortigate), nguứ ồn điện d phòng ựUPS, 2 đường truy n m ng tề ạ ốc độcao…

3.2 Giải pháp xây dựng hệ ống SSO sử ụng giao thứ th d c OAuth 2.0

3.2.1 Các thuận lợi và khó khăn tại Bệnh viện

 Thu n l i: ậ ợ

- Bệnh viện đã có nền tảng cơ sở ề ạ ầng trang thiết bị, phòng máy chủ v h ttrang b ị tương đối đầy đủ

- S ự ủng hộ ủa lãnh đạo Bệnh viện cho việc phát triể ứng dụng CNTT c n trong qu n lý hành chính ả

- Hằng năm có ngân sách trong việc phát triể ứng dụng CNTT nhưng n không nhi u ề

 Khó khăn:

- Không có nhi u kinh phí cho vi c phát tri n ng d ng CNTT tề ệ ể ứ ụ ại đơn vị

- Thiếu thốn nhân lực trong việc phát triển, quản lý và duy trì hệ th ng ốCNTT

- H thệ ống phòng máy chủ ủa Bệnh viện chưa có cá nhân chuyên trách c

đảm nhi m, nhi u d ch v v h t ng t i B nh việ ề ị ụ ề ạ ầ ạ ệ ện đang phải thuê đơn vị ứ th 3

h tr ỗ ợ cài đặt máy chủ, bảo trì h th ng, nâng c p h th ng… ệ ố ấ ệ ố

- H thệ ống còn rời rạc, thiếu sự liên kết, tính năng an toàn bảo mật thông tin chưa cao, thỉnh thoảng v n b lẫ ị ỗi hệ ố th ng

3.2.2 Bài toán thực tế đặ t ra

 Bài toán th ứ nhất: Xây dựng nghiệp v ụ quản lý tập trung

- Với hình thức quản lý tập trung, điều này có nghĩa là mọi vấn đề liên quan

s ẽ được tậ trung tại một nơi và một cá nhân hay một tổ chức sẽ có trách nhiệp m đưa ra quyết định x lý và ban hành ử

Ý tưở ng đ gi i quy t bài toán ể ả ế ở đây là: Xây dựng một hệ ống độc lậ th p c ụ

tài khoản người dùng truy c p vào các hậ ệ thống khác nhau trong cùng một hệ

sinh thái của đơn vị ừ đó có thể, t nghiên c u, tri n khai nhiứ ể ều phương án bảo

m t khác nhau trên h th ng này ậ ệ ố

 Bài toán thứ hai: Nâng cao ính tr i nghi m, tính thân thi n, d s t ả ệ ệ ễ ử

dụng, tính bảo mậ thông tin cho người dùng khi sử ụng hệ ống các t d thWebsite Y t cế ủa Bệnh viện.

- Hiện nay ệnh việ chạy 2 trang website và web app chínhB n là: Trang tin

t c ứ nghiên cứu khoa học, trang phần mềm quản lý khám chữa bệnh (HIS) Ngoài

ra, B nh việ ện đang xây dựng loạt các trang website khác: trang mua bán thuốc, trang khám b nh tr c tuyệ ự ến, trang chăm sóc dinh dưỡng…