Giới thiệu về Single Sign On

Mở đầu bài viết bằng cụm từ khóa tìm kiếm mà hầu hết các bạn lần đầu nghe về SSO sẽ search trên google...


Single Sign On là gì?

Đầu tiên là khái niệm về Single Sign On theo Wikipedia

Theo Wikipedia Single Sign On là một thuật ngữ của việc kiểm soát truy cập nhiều hệ thống liên quan. Với việc sử dụng thuật ngữ này cho phép người dùng đăng nhập với một ID và mật khẩu duy nhất để có thể truy cập vào một hệ thống hay nhiều hệ thống kết nối với nhau mà không cần sử dụng nhiều tên đăng nhập và mật khẩu khác nhau của từng hệ thống.

Một ví dụ điển hình cho việc ứng dụng thuật ngữ này là Google, Google sử dụng cho những sản phẩm của họ như: Gmail, YouTube, Google Maps... Điều này được thực hiển bởi một "dịch vụ trung tâm" (trong trường hợp Google là https://accounts.google.com).

Khi bạn đăng nhập lần đầu tiên, cookie được khởi tạo ở "dịch vụ trung tâm", sau đó khi bạn truy cập vào hệ thống thứ hai thì trình duyệt sẽ chuyển hướng tới trung tâm nhưng bạn đã có cookie khi đăng nhập từ trước nên điều đó có nghĩa là bạn đã đăng nhập thành công vào các hệ thống còn lại.

Ngược lại, Single Sign Off là thuật ngữ mà theo đó khi người dùng đăng xuất khỏi hệ thống sẽ chấm dứt quyền truy cập vào các hệ thống còn lại.

Mô hình xác thực NON-SSO

Theo mô hình xác thực NON-SSO ở trên, khi user đăng nhập thành công vào domain1.com thì chỉ là "đã đăng nhập" trên domain1.com và chưa chuyển sang trạng thái "đã đăng nhập" trên domian2.com. Nếu muốn đăng nhập vào domain2.com user cũng phải thực hiện các thao tác đăng nhập như thường lệ. 

Nhìn vào kiến trúc ở trên chúng ta có thể đưa ra giải pháp "chia sẻ thông tin session giữa các domain". Nhưng có một vấn đề là trình duyệt phải tuân theo chính sách bảo mật same origin policy.

Mô hình thể hiện chính sách bảo mật same origin policy

Nói sơ qua về same origin policy cho những bạn chưa biết, nội dung của chính sách này là chỉ những người tạo mới có quyền truy cập các cookie (hay bất kỳ dữ liệu lưu trữ cục bộ nào). Nói cách khác, domain A không thể truy cập các cookie từ domain B và ngược lại. Đây chính là vấn đề mà SSO giải quyết: chia sẻ thông tin session trên nhiều domain khác nhau.

Chúng ta có thể hiểu một cách đơn giản hơn: Khi người dùng đăng nhập vào một hệ thống, thì họ "đã" đăng nhập vào các hệ thống liên quan.

Với số lượng các website và dịch vụ tăng lên, thì một hệ thống đăng nhập tập trung (centralized login system) trở nên cần thiết hơn bao giờ hết.

Sớm hay muộn thì các team phát triển web hay các hệ thống microservice cũng sẽ phải đối mặt với vấn đề như sau:

- Team của bạn phát triển một hệ thống/ một website và deploy nó trên tên miền A

-  Một team khác (hoặc chính team của bạn) phát triển một hệ thống/ một website và deploy nó trên tên miền B

Lúc này, vấn đề đặt ra là khi người dùng đăng nhập vào domain A thì họ cũng sẽ tự động đăng nhập vào domain B và ngược lại.

Mô hình hoạt động của SSO

Các giao thức SSO chia sẻ thông tin session theo nhiều cách khác nhau, nhưng những thứ cơ bản thì giống nhau đó là: có một central domain (domain trung tâm) để 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ụ, center domain có thể tạo một JSON Web Token đã được ký (được mã hóa sử dụng JWE). Token này có thể được truyền tới client và được sử dụng để xác thực người dùng cho domain hiện tại cũng như bất kỳ domain nào khác. Token có thể truyền tới domain gốc bằng cách điều hướng và 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 ký, thì nó không thể bị chỉnh sửa bởi bất kỳ client nào.

Sử dụng domain trung tâm để xác thực

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.

Các giao thức khác nhau

Nếu bạn đã đọc về SSO online, chắc chắn bạn sẽ biết rằng có rất nhiều cách để triển khai SSO như: OpenID Connect, Facebook Connect. SAML, Microsoft Account (trước kia là Passport),… Lời khuyên của chúng tôi là chọn bất kỳ cái nào mà bạn cảm thấy đơn giản và dễ dàng nhất để thực hiện. Ví dụ, SAML tập trung sâu vào các doanh nghiệp, vì thế trong một số trường hợp nó là lựa chọn hợp lý nhất. Nếu bạn cần kết hợp nhiều hơn một giải pháp, đừng lo lắng: có nhiều framewok cho phép kết hợp nhiều giải pháp SSO khác nhau. Một trong số các framework đó là AuthO.

Lợi ích mà SSO mang lại

Trước khi có đăng nhập một lần (SSO), 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 rõ ràng có thể tốn nhiều thời gian, đặc biệt là trong môi trường doanh nghiệp, nơi mà thời gian là tiền bạc nhưng thời gian là lãng phí bởi vì nhân viên phải đăng nhập mỗi khi họ truy cập vào một hệ thống mới từ máy tính của họ. SSO thường được thực hiện thông qua một mô-đun xác thực phần mềm riêng biệt hoạt động như một cửa ngõ vào tất cả các ứng dụng yêu cầu đăng nhập. Các  mô-đun xác thực người sử dụng và sau quản lý truy cập vào các ứng dụng khác. Nó hoạt động như một kho dữ liệu chung cho tất cả các thông tin đăng nhập được yêu cầu.

Ví dụ: Một ví dụ về một module SSO là hệ thống của Google khi mà người dùng chỉ cần đăng nhập 1 lần thì họ có thể sử dụng các dịch vụ của Google hay Yahoo mà không đòi hỏi đăng nhập 1 lần nữa như Gmail, Google Plus, Youtube….. Trong khi SSO là rất tiện lợi, một số nhận thấy nó như là một vấn đề an ninh của riêng mình. Nếu hệ thống SSO bị tổn thương, một kẻ tấn công có quyền truy cập không giới hạn cho tất cả các ứng dụng chứng thực của các module SSO.SSO thường là một dự án lớn cần lập kế hoạch cẩn thận trước khi thực hiện.

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

Có phải khi sử dụng SSO là vấn đề bảo mật được cải thiện ?

Đăng nhập một lần ( SSO ) là một con dao hai lưỡi. SSO tự nó không 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 người sử dụng thuận tiện.

Như hệ thống của công ty, với mỗi một yêu cầu mật khẩu riêng của mình, SSO giúp giảm bớt gánh nặng phải dành thời gian đăng nhập vào từng hệ thống riêng. Nhưng đồng thời, nếu SSO bị tổn thương, nó mang lại cho tin tặc khả năng truy cập vào toàn bộ hệ thống sử dụng SSO. Mặt khác, SSO có những lợi ích nhiều hơn những rủi ro nó mang lại. Vì vậy, mặc dù SSO không phải là biện pháp bảo mật tối ưu nhất, nhưng nó có thể đóng góp tích cực vào một chương trình bảo mật thông tin doanh nghiệp.

Hệ thống SSO thường dựa trên các ứng dụng phức tạp hệ thống quản lý như IBM Tivoli, hoặc dựa trên phần cứng thiết bị từ hãng Imprivata Inc (1 hãng cung cấp giải pháp SSO nổi tiếng). Kết quả là, hệ thống SSO có thể tập trung xác thực trên các máy chủ đặc biệt. Họ làm điều này bằng cách sử dụng các máy chủ chuyên dụng để giữ các module SSO. Các máy chủ hoạt động như SSO người gác cổng, đảm bảo tất cả các xác thực đi đầu tiên thông qua máy chủ SSO, sau đó đi dọc theo các chứng chỉ đã được lưu trữ để xác thực các ứng dụng cụ thể đã đăng ký với hệ thống SSO. Hệ thống đòi hỏi phải lập kế hoạch cụ thể và chi tiết để kiểm toán để ngăn chặn truy cập độc hại hơn so với các hệ thống SSO làm(Có nghĩa là nếu được đầu tư về phẩn cứng thích hợp thì nó sẽ tăng bảo mật). Ngoài ra, hệ thống SSO thường có lưu trữ an toàn hơn các thông tin xác thực và các khóa mã hóa, làm cho chúng 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ông ty. Nó thường 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.

Các yếu tố cần xem xét trước khi triển khai SSO là gì?

Đăng nhập một lần (SSO) có thể là một giải pháp cho tình hình của bạn, nhưng tất cả phụ thuộc vào hoàn cảnh của đơn vị triển khai, đặc biệt là nhu cầu bảo mật và ngân sách. SSO có ưu điểm và những rủi ro của nó.

Hai ưu điểm chính là:

• Thuận tiện: Người sử dụng chỉ cần đăng nhập 1 lần để sử dụng nhiều ứng dụng.
• Bảo mật: Bởi vì chỉ có một đăng nhập một lần, SSO có thể loại bỏ những rủi ro vốn có trong việc ghi nhớ nhiều username/password.

Hai rủi ro chính là:

• Bảo mật: Nếu một kẻ xâm nhập làm tổn hại tài khoản của người dùng hoặc mật khẩu, kẻ xâm nhập có thể có rộng rãi và dễ dàng truy cập vào rất nhiều ứng dụng.
• Chi phí: triển khai SSO có thể tốn kém, cả về chi phí để mua và nguồn nhân lực để triển khai. Hai yếu tố SSO là tốt nhất, nơi truy cập được cấp dựa trên sự kết hợp đối với những gì người sử dụng biết (mật khẩu hoặc mã PIN)