4 cơ chế xác thực - p4

SINGLE SIGN-ON (SSO) LÀ GÌ, HOẠT ĐỘNG RA SAO?

Nguồn tham khảo:

https://viblo.asia/p/single-sign-on-sso-la-gi-hoat-dong-ra-sao-bWrZn4oQ5xw

Giới thiệu

Ngày nay, hầy hết các trang web đều yêu cầu xác thực người dùng thì mới có thể truy cập vào chức năng và nội dung của họ. Với sự gia tăng của số lượng các trang web, thì đương nhiên, số lượng tài khoản mà mỗi người dùng cần có sẽ tăng theo.Thử tưởng tượng bạn đang sử dụng 10 dịch vụ khác nhau, mà mỗi tài khoản để truy cập các dịch vụ này thì đều yêu cầu tối thiểu 2 thông tin cơ bản là user name và password. Chà, việc ghi nhớ hết chỗ này cũng mệt lắm đây! Vậy thì thông minh hơn một chút, là sẽ sử dụng user name và password của các dịch vụ này là y hệt nhau. Cơ mà với 10 dịch vụ, thì việc đăng nhập 10 lần là không thể tránh khỏi !!! Và vì thế, single sign-on (đăng nhập một lần) ra đời

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 (ví dụ khi đăng nhập tài khoản google thì bên youtube sẽ sử dụng tài khoản đó, hay tài khoản Zing có thể sử dụng để chơi các game của VNG..)

Ưu và nhược điểm

Một vài lợi ích có thể kể đến của single sign-on là:

·        Giảm số lượng username và pasword mà người dùng cần phải ghi nhớ

·        Giảm số lần phải nhập thông tin username và pasword

·        Rủi ro về việc lộ thông tin người dùng cũng được tiết chế lại

Tuy nhiên, một vài hạn chế không thể không kể đến:

·        Chi phí phát triển khi thông qua service thứ ba

·        Phụ thuộc vào service bên ngoài

Hệ thống nhận dạng liên kết

Hệ thống nhận dạng liên kết (Federated Identity Glossary) là nơi tập trung và liên kết thông tin người dùng. Có 4 yếu tố nền tảng cấu thành nên hệ thống này:

·        Xác thực (Authentication)

·        Phân quyền (Authorization)

·        Trao đổi thông tin người dùng (User attributes exchange)

·        Quản lí người dùng (User management)

Xác thực có nghĩa là: kiểm tra thông tin đăng nhập và tiến hàng định danh người dùng.

Phân quyền dựa trên thông tin định danh để kiểm tra quyền truy cập của user.

Trao đổi thông tin người dùng Mỗi hệ thống con sẽ cần và lưu trữ các thông tin khác nhau của người dùng, tuy nhiên sẽ có các thông tin bị lặp lại, ví dụ như tên, họ.... Do đó, cần có một nơi để tổng hợp lại các thông tin này, và trao đổi cho các hệ thống con.

Quản lí người dùng admin có thể quản lí người dùng bằng các thao tác thêm, sửa, xóa... ở các hệ thống con.

Single sign-on là một phần của hệ thống nhận dạng liên kết, có liên quan chặt chẽ với việc xác thực thông tin người dùng. Nó sẽ định danh người dùng, và sau đó chia sẻ thông tin định danh được với các hệ thống con.

Cơ chế

Một user khi đăng nhập vào hệ thống A thì domain của A sẽ lưu thông tin định danh vào cookie, để user này cũng là đã đăng nhập khi truy cập vào hệ thống B thì domain B sẽ phải đọc được cookie của A tạo ra, nhưng điều này là không thể. Với các trình duyệt hiện nay, domain chỉ có thể truy cập cookie do chính nó tạo ra.

Vì vậy, single sign-on sẽ phải chia sẻ thông tin cookie giữa các domain với nhau. Mỗi giao thức single sign-on sẽ có cơ chế chia sẻ khác nhau, nhưng điểm chung đều là tạo ra một domain trung tâm (central domain). Qua domain này, thông tin về cookie sẽ được chia sẻ đến các domain con. Ví dụ, central domain có thể tạo ra một json web token (jwt) và mã hóa nó. Khi ngươi dùng truy cập vào domain con thì sẽ được điều hướng đến domain trung tâm này, và token sẽ được trả lại và lưu ở phía trình duyệt. Sau đó, nếu người dùng tiếp tục truy cập vào domain con khác thì tương tự, cũng 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 lại là không cần thiết nữa.

Đọc xong cũng thấy khá logic, nhưng khi kéo xuống các câu hỏi bên dưới, thì mình thấy có một câu được rất nhiều vote up như thế này:

Hiểu là: brower lưu cookie kiểu gì vậy? Tôi đang hiểu là mỗi domain sẽ có 1 storage riêng trong local storage tổng để lưu cookie. Khi access đến domain1 và được redirect đến central domain xong thì sẽ có cookie lưu trong storage của domain1 và central, sau đó, với domain2 thì làm thế nào để lấy được cookie của central Mình nghĩ là câu này cũng sẽ có nhiều người thắc mắc (vì có nhiều vote up mà ) nên có một số ý hiểu mình muốn chia sẻ đó là:

·        Local storage không chia thành nhiều storage con, mà chỉ có duy nhất một local storage mà thôi, tất cả cookie đều sẽ được lưu ở một chỗ, dạng key (là domain) và value. Chỉ là, các domain sẽ chỉ có quyền access đối với data mà nó tạo ra thôi.

·        Không có chuyện các domain sử dụng cookie của nhau. Các domain sẽ tự request đến center domain và tự lưu cookie được trả ra, sau đấy, với mỗi request thì các domain sẽ tự dùng cookie mà mình có

·        Phần lớn các service SSO hiện nay (ví dụ ở đây là Auth0) có 2 cách để xử lí ở vấn đề này:

• Do tính chất của cookie, là các domain và subdomain có thể truy cập qua lại, nên central domain sẽ là dạng subdomain đối với một trong số các domain con. Ví dụ: domain con là abc.com thì auth0 sẽ tạo ra một central domain là auth0.abc.com. khi đấy, user nếu đã login ở abc.com thì sẽ có cookie lưu ở local storage mà cả abc.com và auth0.abc.com đều truy cập được. Khi đấy, nếu user login ở edf.com thì sẽ được redirect về central domain là auth0.abc.com, và sẽ có cookie, và lúc đấy user sẽ được xác thực
• Sử dụng cơ chế Cross-origin resource sharing

 

 

ENCODING , ENCRYPTION VÀ HASHING

 

Nguồn tham khảo: https://viblo.asia/p/encoding-encryption-va-hashing-gDVK2pJmlLj

Enconding

Bản chất encode thực hiện việc biến đổi data thành 1 format khác dựa trên một quy chuẩn nào đó. Ví dụ biến đổi từ chữ A sang mã bit theo bảng mã ASCii: A -> 01000001

 

• Encoding chỉ là cách thức chuyển hóa dữ liệu của các bạn thành 1 dạng khác mà có thể tiêu thụ được trên các hệ thống khác nhau.
• Encoding không hề bảo mật. Ta chỉ cần dùng đúng thuật toán encode là có thể giải mã ngược lại mà không cần một key nào

Ở phần encode này các bạn có thể tham khảo thêm về Unicode, Base64, Url Encoding,... mà được sử dụng rất nhiều cho việc encode này.

 

Encryption

Nhắc đến encryption thì chắc chắn chúng ta biết ngay nó để bảo mật dữ liệu.

So sánh với encode thông thường ở trên, khi mà ta chỉ cần dùng đúng công cụ encode để decode ngược lại là xong. Nhưng với encryption, quá trình mã hóa sẽ kèm theo 1 secret-key hay là 1 mã bảo mật mà chỉ người tạo biết được.

Do đó, để có thể giải mã, chúng ta cẩn có đủ 3 thông tin :

·        Đầu tiên chắc chắn là đoạn dữ liệu đã bị mã hóa

·        Thuật toán dùng để mã hóa

·        Cuối cùng quan trọng nhất vẫn là key mật mà người tạo đã sử dụng cho thuật toán này.

Hashing

Hashing chỉ quy trình biến đổi một chuỗi data đầu vào (input), xử lý bằng một thuật toán đặc biệt (hash function) và cho ra kết quả là dạng data khác.

Đặc điểm của hashing:

·        Với 1 đầu vào thì luôn chỉ cho ra 1 đầu ra duy nhất (Tất nhiên đấy là với 1 thuật toán tốt, trong thực tế vẫn có hash funtion cho ra cùng 1 output với 2 input khác nhau, gọi là đụng độ giá trị băm (collision))

·        Là quá trình 1 chiều, biến đổi từ input -> output chứ không làm ngược lại được.

Ý nghĩa:

·        Với tính nhất quán của input với output, nên hashing được đại diện cho sự toàn vẹn dữ liệu. Bởi với bất kì 1 thay đổi nhỏ nào của input là bạn đã có 1 output hoàn toàn khác.

·        Vì tính chất 1 chiều như vậy, hashing được dùng trong các tính năng của hệ thống mà không cần phải tương tác với dữ liệu dạng sơ khai để nhằm bảo mật .

Hơi trừu tượng phải không, mình sẽ lấy 1 ví dụ thường gặp nhất nhé. Hashing password. Khi user tạo tài khoản, thay vì lưu trữ pass trong db dạng plaintext, thì chúng ta sẽ hash chúng và lưu vào db. Và khi hash như vậy, thì ngay cả hệ thống của chúng ta sau này cũng chẳng biết đoạn hash lưu trong db kia ứng với plaintext gì. Tuy nhiên chúng ta vẫn có thể thực hiện cơ chế xác thực user như sau:

·        User login với username và pass

·        Hệ thống tìm row tương ứng trong db với username và lấy ra hashed-pass

·        Sau đó, ta dùng thuật toán tương tự, hash pass mà user vừa nhập vào rồi so sánh với hased-pass trong db. Nếu khớp thì đó chính là pass hợp lệ.

Đến đây chúng ta chắc sẽ thấy rõ điểm khác biệt giữa encryption và hashing phải không ?

·        Encryption là 1 quy trình mã hóa 2 chiều. Sau khi mã hóa, ta hoàn toàn có thể dùng secret-key để giải mã và lấy ra plain-text ban đầu.

·        Hashing không có key như vậy. Và tất nhiên nó là quy trình chỉ có 1 chiều mã hóa chứ không giải mã được.