CHƯƠNG 1: GIỚI THIỆU CƠ CHẾ ĐĂNG NHẬP MỘT LẦN 1. Tổng quan về Single sign-on 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 hệ thống, ứng dụng trong 1 phiên làm việc. Hình 1: Tổng quan về Single sign-on Trước khi có SSO, để truy cập vào ứng dụng, hệ thống người dùng phải nhập tài khoản và mật khẩu. Điều này khiến trải nghiệm người dùng không tốt, tốn thời gian, tăng nguy cơ mất bảo mật… Do đó hệ thống, website có sử dụng SSO sẽ đem lại nhiều thuận tiện cho người dùng, tăng tính bảo mật.
Ví dụ: Với các dịch vụ của Google cung cấp: Gmail, Youtube, Drive, Scholar, CHPlay. người dùng phải nhập thông tin tài khoản của dịch vụ để xác thực khi muốn truy cập, sử dụng. Với SSO người dùng chỉ cần sử dụng 1 tài khoản Google 3 để có thể đăng nhập và sử dụng tất cả các dịch vụ, ứng dụng của google. Điều đó thực sự mang lại trải nghiệm tốt cho người dùng.
Hình 2: Một số dịch vụ của Google Đă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. Quá trình đăng nhập gồm 2 bước Xác thực và Ủ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 như: username/password, thẻ từ, faceId… Ủy quyền ( Authorization): Là quá trình kiểm tra sau khi người dùng đã được xác thực có quyền truy cập vào tài nguyên hay không? 1. Tổng quan về 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, đối tượng nào đó. Xác thực cho phép xác định người dùng hiện tại là ai, họ có mặt hay không? Một giao thức xác thực đầy đủ có thể sẽ có các thông tin định danh về người dùng : mã định danh duy nhất người dùng (ID), tên người dùng, ngày sinh, email… 4 1.
Các phương thức xác thực 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 [13] Hình 3: Phân loại các phương thức xác thực Xác thực theo tri thức Đây là phương thức sử dụng thông dụng 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ử dụng mã số cá nhân (PINs). Đối với mạng Internet không đảm bảo về an ninh, để xác thực thường sử dụng Digital Certificates and Digital Signatures. Xác thực theo sự sở hữu Xác thực theo sự sở hữu dựa vào những gì mà người dùng có (các đối tượng vật lý như: Thẻ…).
Tuy nhiên nhược điểm của phương thức này là thẻ không chứng minh được quyền sở hữu vì nó có thể dễ dàng bị đánh cắp hoặc sao chép. Vì vậy việc sử dụng phương pháp này đi kèm mã PIN sẽ bảo mật hơn nhiều so với việc dùng thẻ hay mã PIN đơn lẻ. 5 Xác thực theo sinh trắc học Đây là 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 vật lý đã được chứng minh là có thể xác thực: Vân tay, võng mạc, khuôn mặt, giọng nói, loại máu… Phương thức này đem lại hiệu quả bảo mật rất cao vì nó không dễ dàng bị đánh cắp hoặc chia sẻ. Tuy nhiện phương thức này không được sử dụng phổ biến và chủ yếu đượ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ì: - Tốn kém về chi phí phần cứng, phần mềm chuyên dụng - Xâm phạm về quyền riêng tư.
- Nguy cơ về bảo mật khi thông tin có thể bị phân tích, đánh cắp làm cho việc xác thực không còn đáng tin cậy 1. Các giao thức xác thực 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 hiện nay là giao thức: OAuth2, Open Id, Saml2 vì chúng tuân theo chuẩn chung và có nhiều ưu điểm. 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 ( Relying Parties hoặc RP) sử dụng dịch vụ của bên thứ 3. Nó giảm được việc phải thiết lập riêng logic signup/login cho mỗi website, cho phép các người dùng có thể đăng nhập tới nhiều webstie ko hề liên quan tới nhau mà ko cần phải có những định danh và password riêng cho mỗi website [6]. Phiên bản mới nhất của OpenID là OpenID Connect 6 Cách thức hoạt động Các thành phần chính: - Relying Party (RP): Là một trang web hay ứng dụng muốn xác nhận người dùng. - OpenID Provider: Chịu trách nhiệm phát hành Identifers và thực hiện xác thực người dùng.
Khi Website A sử dụng OpenID để xác thực người dùng quy trình được diễn ra theo các bước như sau: + Website A chuyển tiếp người dùng về một URL của OpenID Provider để đăng nhập. + Nếu đăng nhập thành công OpenID Provider sẽ chuyển tiếp người dùng về RP, kèm thông tin người dùng đã xác thực. + Website A thực hiện xác thực người dùng mà không cần phải thực hiện đăng nhập vì tin tưởng kết quả trả về của OpenId Provider 1. OAuth2 Khái niệm OAuth2 là một chuẩn mở để ủy quyền/phân 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 (ủy quyền - authorization) để có một giải pháp bảo mật hoàn chỉnh hơn.
OpenID Connect (OIDC) được tạo ra vào đầu năm 2014 và OAuth2 hoàn toàn độc lập, chứ không phải một phần của OIDC. 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ác token được tạo ra bởi một nhà cung cấp nhận dạng (Identity Provider) cho các ứng dụng bên thứ ba, với sự chấp thuận của người dùng [2]. 7 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 access_token. - Client (Application): Một ứng dụng yêu cầu tài nguyên được bảo vệ thay mặt cho resource owner và với sự chứng thực của tài nguyên đó. - Authorization Server : Máy chủ phát hành access token cho client sau khi xác thực thành công resource owner và nhận được ủy quyền.
Hình 4: Cách thức hoạt động của OAuth2 Quy trình hoạt động diễn ra như sau: 1.Application yêu cầu ủy quyền để truy cập vào Resource Server thông qua User 2. Nếu User ủy quyền cho yêu cầu trên, Application sẽ nhận được giấy ủy quyền từ phía User (dưới dạng một token string nào đó chẳng hạn) 8 3. Application gửi thông tin định danh (ID) của mình kèm theo giấy ủy quyền của User tới Authorization Server. 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 Application access_token.
Đến đây quá trình ủy quyền hoàn tất. Để truy cập vào tài nguyên (resource) từ Resource Server và lấy thông tin, Application sẽ phải đưa ra access_token để xác thực. 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. SAML Khái niệm SAML (Security Assertion Markup Language) là “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 - SP) 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ụ đó [4].
Cách thức hoạt động Các thành phần chính [4] - 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 đó. 9 Hình 5: Cách thức hoạt động của SAML Bước 1: Người dùng thực hiện 1 yêu cầu login tới Service Provider.
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ử dụng browser (nếu người dùng đang đă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) để redirect (http post) về cho SP sử dụng (kết quả trả về này 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ó). 10 Khóa công khai của IdP cũng giống như nói ở trên, có thể lấy 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 sẽ tiếp tục dùng khóa công khai của chính mình để giải mãi SAML Assertions đã được mã hóa từ phía IdP.
+ Lấy các 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, và trả về cho người dùng thông báo thành công (hay điều hướng người dùng tới các tài nguyên mong muốn) 1. Nguyên lý hoạt động của Single sign-on Mô hình nguyên lý hoạt động của Single sign-on [3] Hình 6: Cách thức hoạt động của Single sign-on 1. Người dùng lần đầu truy cập domain1. Domain1 redirect về trang login AuthServer để xác thực người dùng.