Single Sign On Solution

Với hệ thống có nhiều website và application thì việc sử dụng Single Sign On (SSO) là khá cần thiết nhằm đem lại nhiều thuận tiện cho người dùng và tăng tính năng bảo mật.
SSO chỉ được triển khai sau khi đã xây dựng được hệ thống xác thực và phân quyền. SSO có nhiệm vụ cung cấp cho người dùng quyền truy cập nhiều tài nguyên Web, Applications trong phạm vi cho phép chỉ với một lần đăng nhập (xác thực). Nói thêm về Phân quyền (Access Control), có 2 Rules chính:

• Authentication: Là quá trình để định danh một người dùng có hợp lệ hay không. (Thường thể hiện qua một form đăng nhập)
• Authorization: Là quá trình kiểm chứng một người dùng đã được xác thực có đủ quyền truy cập vào tài nguyên (mà người dùng) yêu cầu hay không. Tài nguyên yêu cầu có thể phụ thuộc vào Policy domain (cấp quyền theo domain) hoặc một policy đặc biệt nào đó (ví dụ cấp quyền theo cấp).

SSO có thể được sử dụng dưới các dạng:

1. Single Domain: Khi xác thực thành công vào domain.com, người dùng đồng thời được xác thực vào các sub-domain.domain.com tồn tại.
2. Multi Domain: Khi xác thực thành công vào facebook.com, người dùng đồng thời được xác thực vào example.com
3. Applications vs Third-Party Products: ví dụ SSO giữa Oracle Access Manager và IBM WebSphere Application Server

Ở 2 dạng đầu tiên, SSO thường sử dụng Cookie để nhận diện, webserver (hay webgate) gửi cookie đã được mã hóa cho browser đã xác thực thành công, cookie này sẽ là chìa khóa sử dụng cho các xác thực tới các tài nguyên khác hoặc cho các xác thực có cùng cấp.
Phần Cookie được mã hóa có thể bao gồm các thông tin: session, distinguished name của người dùng đã xác thực thành công, IP của client đã yêu cầu, thời điểm khởi tạo cookie, thời điểm sửa đổi cookie.. các thành phần không mã hóa của cookie có thể bao gồm: thời gian expired, domain hoạt động, SSL/ Httponly…
Thuật toán mã hóa được recommend hiện nay là AES,  bên cạnh là các thuật toán kém bền vững hơn nhưng thông dụng như MD5-salt, RC4, RC6 vẫn được sử dụng phổ biến trong các mã hóa cookie/ session.

• Single Domain SSO

Cookie Path được cấu hình để dùng chung cho mọi subdomain: .domain.com (bao gồm dấu . ở đầu)

Mô hình của Oracle® Access Manager

• Multi Domain SSO

Multi Domain SSO cho phép người dùng truy cập vào nhiều domains/hosts sau 1 lần đăng nhập. Một ứng dụng xác thực chính sẽ cung cấp các cookie hợp lệ cho mỗi domain.Chẳng hạn người dùng truy cập vào gmail.com, khi đó toàn bộ services của Google, như Google.com, Picasa, Blogspot… đều nhận diện tính xác thực cho người dùng đó.
Tuy nhiên cookie không thể được thiết đặt cho across domains do Policy bảo mật của hầu hết browser, do đó một domain chính sẽ được chọn để xác thực ở mọi quy trình, gọi chung là master domain. Với mỗi domain khác mà người dùng thực hiện quá trình xác thực, mỗi webgate của hệ thống đó sẽ redirect tới master domain.
Master domain sẽ hoạt động như quy trình của Single Domain SSO, nó chính là *proxy* để truyền tải cookie hợp lệ về cho mỗi domain có yêu cầu xác thực.

Mô hình của Oracle® Access Manager

Hoạt động

1. Ta thiết đặt master domain, login-service.domain.com.
2. Mỗi một domain nằm trong group SSO đều có script login riêng.
3. Mọi hệ thống trên mỗi domain đều sử dụng chung Session Database.
4. Khi mỗi Client yêu cầu người dùng xác thực, Webgate của nó sẽ redirects tới master domain có chứa login service. Nếu người dùng chưa đăng nhập, master domain sẽ triệu gọi script login của client để thực hiện việc login vào master domain. Khi người dùng đã xác thực, một session sẽ được tạo trong database và master domain sẽ cung cấp session id cho client yêu cầu để có thể tạo cookie theo session đó.

Notes:

• Các thuật toán mã hóa session. session id phải được dùng chung (RFC 4122)
• Master service chỉ xử lý & redirect tới những domain nằm trong whilelist
• Các domain có thể ở nhiều dạng khác nhau, login.domain.com, domain.com/service, client.abc.com…

Logout
Đây là quá trình quan trọng vì mỗi quá trình logout ở một client chỉ có hiệu lực với cookie của client đó, cần thiết đặt một timeout phù hợp cho cookie hay thiết đặt cơ chế clear cookie ở mọi domain liên quan (chậm chạp), có thể xóa luôn session ở database nhưng lưu ý session có thể tạo lại bởi tính năng Ghi nhớ đăng nhập.

Chi tiết

OAuth là gì?

Bài viết này dành cho những người chưa hiểu cơ bản về OAuth và Single Sign On.

OAuth là gì? Đó là câu hỏi không dễ đối với những người chưa từng làm việc với SSO (Single Sign On). Thực ra thì Single Sign On không liên quan gì mấy đến nội dung của OAuth. Tuy nhiên chúng hay đi liền với nhau. Vì vậy cũng phải có sự phân biệt cho khỏi nhầm lẫn.

1. Single Sign On là việc bạn có thể đăng nhập vào một website (như google.com) và sử dụng đăng nhập đó trên các website khác.
• Vì vậy SSO là một tiện ích
• Thường được sử dụng trên các website liên quan mật thiết đến nhau
• Tiện ích SSO có nhiều phương pháp để thực hiện, SAML là một trong các phương pháp đó
2. OAuth là phương pháp chia sẻ tài nguyên giữa các ứng dụng mà không phải đưa ra “giấy thông hành” là username và password.
• Do đó, OAuth là một phương pháp
• Thường được sử dụng trên các website … chả liên quan gì nhau (thực ra là có liên quan đấy, nhưng về mặt bản chất chúng có thể hoạt động mà chẳng cần gì đến nhau, việc kết nối là để xin chút tài nguyên thôi).

Ngoài ra, bạn cũng phải phân biệt giữa hai từ Authorization và Authentication. Từ thứ 2 đơn giản là “đăng nhập” hay không, còn từ thứ nhất là “có quyền” hay không. Cần chú ý chúng khác nhau nhiều lắm, đôi khi bạn chẳng cần “đăng nhập” bạn cũng có thể “có quyền”. Ý của tôi ở đây là Authentication thường liên quan đến việc bạn phải “đăng nhập” vào hệ thống. Còn Authorization tức “có quyền” trên tài nguyên hệ thống hay không thì bạn phải yêu cầu chủ thể của tài nguyên cho phép bạn.

Nói vậy thì hơi lan man, bạn có thể bỏ qua đừng suy nghĩ gì về đoạn giải thích như đánh đố trên.

Xin được đi chi tiết hơn về OAuth, nội dung của nó thì không mới, các hãng lớn như Google, Aol, Yahoo… đều có các phương pháp Authorization của riêng mình. Nhưng nó khiến các bên thứ ba khó khăn khi tích hợp với họ. Vì vậy họ họp nhau lại để tạo ra chuẩn Open Authorization.

1. Bắt đầu với Authorization, cụ thể là OAuth bạn phải phân biệt được những bên liên quan như sau

• Client: là ứng dụng (chú ý là một ứng dụng, có thể là ứng dụng Desktop, cũng có thể là website của bạn như http://www.youbrainy.com
  ), muốn có quyền sử dụng tài nguyên của Server
• Server: là một ứng dụng khác,  chẳng hạn như google.com.
• You: chính bạn, bạn có tài nguyên trên Server và bạn muốn cho Client quyền sử dụng nó

Tóm lại: OAuth là phương pháp để Client sử dụng được tài nguyên của You bên phía Server

2. Phân biệt hai loại OAuth

• 2-legged OAuth: là kiểu Authorization trong đó vai trò của You và Client là như nhau. Tức là Client chính là You của Server. Đó là kịch bản Client-Server thông thường.
• 3-legged OAuth: là kiểu Authorization trong đó You và Client là phân biệt. Client muốn You chia sẻ tài nguyên đã có bên phía Server.

3. Cách OAuth hoạt động

3.1. 2- legged OAuth

1. Client đăng ký sử dụng dịch vụ với Server
2. Server cho Client
• CONSUMER_KEY
• CONSUMER_SECRET_KEY
3. Client sử dụng các keys trên để thực hiện Authorization

3.2. 3- legged OAuth

1. Client đăng ký sử dụng dịch vụ với Server
2. Server cho Client
• CONSUMER_KEY
• CONSUMER_SECRET_KEY
3. You có tài nguyên ở Server
4. You sử dụng dịch vụ ở Client, Client yêu cầu You cho phép khai thác tài nguyên của You ở Server
5. Client yêu cầu Server gửi REQUEST_TOKEN cho You
6. Client chuyển You đến Server Authentication
7. You đăng nhập vào Server, Server hỏi You có muốn chia sẻ quyền khai thác dữ liệu cho Client hay không
8. You đồng ý, Server chuyển You về Client kèm theo ACCESS_TOKEN
9.  Client sử dụng ACCESS_TOKEN để thực hiện thao tác trên các tài nguyên của You thuộc Server

4. Chú ý khi cài đặt với PHP

1. Các trang tích hợp OAuth phần lớn hỗ trợ thư viện để bạn có thể dễ dàng cấu hình OAuth
2. Nếu trong tình huống xấu, bạn chính là người cung cấp dịch vụ và muốn cung cấp mã nguồn tích hợp OAuth với dịch vụ của bạn. Thì bạn phải code rùi. Tất nhiên đây là trường hợp chủ động
3. Nếu bên cung cấp dịch vụ ỉm đi, không cho bạn cái gì sất. Bạn phải code phần client chẳng hạn. Bạn nên tìm hiểu các thư viện sẵn có để học hỏi. Như Zend_OAuth chẳng hạn.

5. Tài liệu

http://oauth.net/core/1.0/

Chi tiết

Single Sign On Solution

Với hệ thống có nhiều website và application thì việc sử dụng Single Sign On (SSO) là khá cần thiết nhằm đem lại nhiều thuận tiện cho người dùng và tăng tính năng bảo mật.

SSO chỉ được triển khai sau khi đã xây dựng được hệ thống xác thực và phân quyền. SSO có nhiệm vụ cung cấp cho người dùng quyền truy cập nhiều tài nguyên Web, Applications trong phạm vi cho phép chỉ với một lần đăng nhập (xác thực). Nói thêm về Phân quyền (Access Control), có 2 Rules chính:

• Authentication: Là quá trình để định danh một người dùng có hợp lệ hay không. (Thường thể hiện qua một form đăng nhập)
• Authorization: Là quá trình kiểm chứng một người dùng đã được xác thực có đủ quyền truy cập vào tài nguyên (mà người dùng) yêu cầu hay không. Tài nguyên yêu cầu có thể phụ thuộc vào Policy domain (cấp quyền theo domain) hoặc một policy đặc biệt nào đó (ví dụ cấp quyền theo cấp).

SSO có thể được sử dụng dưới các dạng:

1. Single Domain: Khi xác thực thành công vào domain.com, người dùng đồng thời được xác thực vào các sub-domain.domain.com tồn tại.
2. Multi Domain: Khi xác thực thành công vào facebook.com, người dùng đồng thời được xác thực vào example.com
3. Applications vs Third-Party Products: ví dụ SSO giữa Oracle Access Manager và IBM WebSphere Application Server

Ở 2 dạng đầu tiên, SSO thường sử dụng Cookie để nhận diện, webserver (hay webgate) gửi cookie đã được mã hóa cho browser đã xác thực thành công, cookie này sẽ là chìa khóa sử dụng cho các xác thực tới các tài nguyên khác hoặc cho các xác thực có cùng cấp.

Phần Cookie được mã hóa có thể bao gồm các thông tin: session, distinguished name của người dùng đã xác thực thành công, IP của client đã yêu cầu, thời điểm khởi tạo cookie, thời điểm sửa đổi cookie.. các thành phần không mã hóa của cookie có thể bao gồm: thời gian expired, domain hoạt động, SSL/ Httponly…

Thuật toán mã hóa được recommend hiện nay là AES,  bên cạnh là các thuật toán kém bền vững hơn nhưng thông dụng như MD5-salt, RC4, RC6 vẫn được sử dụng phổ biến trong các mã hóa cookie/ session.

• Single Domain SSO

Cookie Path được cấu hình để dùng chung cho mọi subdomain: .domain.com (bao gồm dấu . ở đầu)

Mô hình của Oracle® Access Manager

• Multi Domain SSO

Multi Domain SSO cho phép người dùng truy cập vào nhiều domains/hosts sau 1 lần đăng nhập. Một ứng dụng xác thực chính sẽ cung cấp các cookie hợp lệ cho mỗi domain.Chẳng hạn người dùng truy cập vào gmail.com, khi đó toàn bộ services của Google, như Google.com, Picasa, Blogspot… đều nhận diện tính xác thực cho người dùng đó.

Tuy nhiên cookie không thể được thiết đặt cho across domains do Policy bảo mật của hầu hết browser, do đó một domain chính sẽ được chọn để xác thực ở mọi quy trình, gọi chung là master domain. Với mỗi domain khác mà người dùng thực hiện quá trình xác thực, mỗi webgate của hệ thống đó sẽ redirect tới master domain.

Master domain sẽ hoạt động như quy trình của Single Domain SSO, nó chính là *proxy* để truyền tải cookie hợp lệ về cho mỗi domain có yêu cầu xác thực.

Mô hình của Oracle® Access Manager

Hoạt động

1. Ta thiết đặt master domain, login-service.domain.com.
2. Mỗi một domain nằm trong group SSO đều có script login riêng.
3. Mọi hệ thống trên mỗi domain đều sử dụng chung Session Database.
4. Khi mỗi Client yêu cầu người dùng xác thực, Webgate của nó sẽ redirects tới master domain có chứa login service. Nếu người dùng chưa đăng nhập, master domain sẽ triệu gọi script login của client để thực hiện việc login vào master domain. Khi người dùng đã xác thực, một session sẽ được tạo trong database và master domain sẽ cung cấp session id cho client yêu cầu để có thể tạo cookie theo session đó.

Notes:

• Các thuật toán mã hóa session. session id phải được dùng chung (RFC 4122)
• Master service chỉ xử lý & redirect tới những domain nằm trong whilelist
• Các domain có thể ở nhiều dạng khác nhau, login.domain.com, domain.com/service, client.abc.com…

Logout

Đây là quá trình quan trọng vì mỗi quá trình logout ở một client chỉ có hiệu lực với cookie của client đó, cần thiết đặt một timeout phù hợp cho cookie hay thiết đặt cơ chế clear cookie ở mọi domain liên quan (chậm chạp), có thể xóa luôn session ở database nhưng lưu ý session có thể tạo lại bởi tính năng Ghi nhớ đăng nhập.

Chi tiết