SSO với CAS hoặc OAuth?


184

Tôi tự hỏi liệu tôi nên sử dụng giao thức CAS hoặc OAuth + một số nhà cung cấp xác thực cho đăng nhập một lần.

Kịch bản ví dụ:

  1. Người dùng cố gắng truy cập tài nguyên được bảo vệ nhưng không được xác thực.
  2. Ứng dụng chuyển hướng người dùng đến máy chủ SSO.
  3. Nếu xác thực ong, người dùng sẽ nhận được mã thông báo từ máy chủ SSO.
  4. SSO chuyển hướng đến ứng dụng gốc.
  5. Ứng dụng gốc kiểm tra mã thông báo đối với máy chủ SSO.
  6. Nếu mã thông báo ổn, quyền truy cập sẽ được cho phép và ứng dụng biết id người dùng.
  7. Người dùng thực hiện đăng xuất và đăng xuất khỏi tất cả các ứng dụng được kết nối cùng một lúc (đăng xuất một lần).

Theo như tôi hiểu thì đó chính xác là những gì CAS đã phát minh ra. Các máy khách CAS phải thực hiện giao thức CAS để sử dụng dịch vụ xác thực. Bây giờ tôi đang tự hỏi về việc sử dụng CAS hoặc OAuth tại trang web của khách hàng (người tiêu dùng). OAuth có phải là sự thay thế cho phần đó của CAS không? Có nên ưu tiên OAuth như một tiêu chuẩn thực tế mới? Có một sự thay thế dễ sử dụng (không phải Sun OpenSSO!) Cho phần xác thực của CAS hỗ trợ các phương thức khác nhau như tên người dùng / mật khẩu, chứng chỉ OpenID, TLS ...?

Bối cảnh:

  • Các ứng dụng khác nhau nên dựa vào xác thực của máy chủ SSO và nên sử dụng một cái gì đó giống như phiên.
  • Các ứng dụng có thể là ứng dụng web GUI hoặc serivces (REST).
  • Máy chủ SSO phải được cung cấp id người dùng, cần thiết để có thêm thông tin về người dùng như vai trò, email, v.v. từ kho lưu trữ thông tin người dùng trung tâm.
  • Đăng xuất một lần nên có thể.
  • Hầu hết các máy khách được viết bằng Java hoặc PHP.

Tôi mới phát hiện ra WRAP , có thể trở thành người kế vị OAuth. Nó là một giao thức mới được chỉ định bởi Microsoft, Google và Yahoo.

Phụ lục

Tôi đã học được rằng OAuth không được thiết kế để xác thực thậm chí nó có thể được sử dụng để triển khai SSO, mà chỉ cùng với một dịch vụ SSO như OpenID.

OpenID dường như là "CAS mới". CAS có một số tính năng OpenID bỏ lỡ (như đăng xuất một lần), nhưng không khó để thêm các phần còn thiếu trong một kịch bản cụ thể. Tôi nghĩ OpenID có sự chấp nhận rộng rãi và tốt hơn là tích hợp OpenID vào các ứng dụng hoặc máy chủ ứng dụng. Tôi biết rằng CAS cũng hỗ trợ OpenID, nhưng tôi nghĩ CAS có thể phân phối được với OpenID.


6
Đăng xuất một lần là một tính năng chống. Tất cả các nghiên cứu người dùng mà tôi biết rằng đã đề cập đến nó đã chỉ ra rằng nó ở bất kỳ nơi nào từ nhẹ đến cực kỳ khó hiểu cho người mới và cả người dùng quyền lực. Cá nhân tôi phải sử dụng một hệ thống sử dụng đăng xuất một lần hàng ngày và tôi thấy nó vô cùng khó chịu. Nó gần như không bao giờ là hành vi tôi muốn.
Bob Aman

16
Đừng đồng ý rằng đăng xuất một lần là một chất chống đông. Tất cả phụ thuộc vào các ứng dụng trong câu hỏi. Đối với các ứng dụng web bằng cách nào đó liên quan đến nhau, ví dụ như google mail và lịch google, điều đó có nghĩa là nếu bạn đăng xuất rõ ràng khỏi cái này, thì bạn sẽ đăng xuất cái khác. Trong trường hợp với các ứng dụng không có "mối quan hệ" rõ ràng, tôi đồng ý với Bob.
tro gỗ

6
Lưu ý rằng câu hỏi này ban đầu được hỏi trước khi OAuth 2.0 được giới thiệu, vì vậy thông tin liên quan đến OAuth có thể không còn chính xác nữa.
Andrew

Câu trả lời:


238

OpenID không phải là 'người kế thừa' hay 'người thay thế' cho CAS, chúng khác nhau, về ý định và cách thực hiện.

CAS tập trung xác thực. Sử dụng nó nếu bạn muốn tất cả các ứng dụng (có thể là nội bộ) của mình yêu cầu người dùng đăng nhập vào một máy chủ (tất cả các ứng dụng được định cấu hình để trỏ đến một máy chủ CAS).

OpenID phân cấp xác thực. Sử dụng nó nếu bạn muốn ứng dụng của mình chấp nhận người dùng đăng nhập vào bất kỳ dịch vụ xác thực nào họ muốn (người dùng cung cấp địa chỉ máy chủ OpenID - thực tế, 'tên người dùng' là URL của máy chủ).

Không có sự cho phép nào ở trên (không có phần mở rộng và / hoặc tùy chỉnh).

OAuth xử lý ủy quyền, nhưng nó không thay thế cho 'bảng USER_ROLES' truyền thống '(quyền truy cập của người dùng). Nó xử lý ủy quyền cho các bên thứ ba.

Ví dụ: bạn muốn ứng dụng của mình tích hợp với Twitter: người dùng có thể cho phép ứng dụng tự động tweet khi họ cập nhật dữ liệu hoặc đăng nội dung mới. Bạn muốn truy cập một số dịch vụ hoặc tài nguyên của bên thứ ba thay mặt cho người dùng mà không nhận được mật khẩu của anh ta (điều này rõ ràng không an toàn cho người dùng). Ứng dụng yêu cầu Twitter truy cập, người dùng cho phép nó (thông qua Twitter) và sau đó ứng dụng có thể có quyền truy cập.

Vì vậy, OAuth không phải là về Đăng nhập một lần (cũng không phải là sự thay thế cho giao thức CAS). Đây không phải là về việc bạn kiểm soát những gì người dùng có thể truy cập. Đó là về việc cho phép người dùng kiểm soát cách tài nguyên của họ có thể được truy cập bởi các bên thứ ba. Hai trường hợp sử dụng rất khác nhau.

Đối với bối cảnh bạn mô tả, CAS có lẽ là lựa chọn đúng đắn.

[cập nhật]

Điều đó nói rằng, bạn có thể triển khai SSO bằng OAuth, nếu bạn xem danh tính của người dùng là tài nguyên được bảo mật. Đây là những gì 'Đăng ký với GitHub' và về cơ bản là thích. Có lẽ không phải là mục đích ban đầu của giao thức, nhưng nó có thể được thực hiện. Nếu bạn điều khiển máy chủ OAuth và hạn chế các ứng dụng chỉ xác thực với nó, đó là SSO.

Không có cách tiêu chuẩn nào để buộc đăng xuất, mặc dù (CAS có tính năng này).


11
Mặc dù OAuth chủ yếu là về ủy quyền, nó có thể được sử dụng như thể một máy chủ xác thực trung tâm. Giống như cách tài khoản Google OAuth được nhiều trang web (bao gồm cả SO) sử dụng để xác thực mà không thực sự sử dụng bất kỳ dịch vụ nào từ nhà cung cấp OAuth.
Amir Ali Akbari

1
Hơn nữa, như đã nói trong Bertl trả lời CAS hiện cung cấp OAuth cả dưới dạng máy khách hoặc máy chủ.
Anthony O.

3
Bây giờ câu trả lời này có còn phù hợp khi OAuth 2.0 tồn tại không? Ý kiến ​​của bạn đã thay đổi như thế nào với OAuth 2.0?
Andrew

6
OAuth 2.0 vẫn là một giao thức ủy quyền và không phải là giao thức xác thực nhưng người ta có thể xây dựng trên OAuth 2.0 để tạo giao thức xác thực, đó là những gì Facebook / LinkedIn đã làm; tiện ích mở rộng được chuẩn hóa duy nhất của OAuth 2.0 cung cấp xác thực là OpenID Connect, là sự kế thừa được chỉ định của OpenID
Hans Z.

48

Tôi có xu hướng nghĩ về nó theo cách này:

Sử dụng CAS nếu bạn kiểm soát / sở hữu hệ thống xác thực người dùng và cần hỗ trợ một bộ máy chủ và ứng dụng không đồng nhất cần xác thực tập trung.

Sử dụng OAuth nếu bạn muốn hỗ trợ xác thực người dùng từ các hệ thống mà bạn không sở hữu / hỗ trợ (ví dụ: Google, Facebook, v.v.).


6
OpenID là một giao thức xác thực, OAuth là một giao thức ủy quyền.
zenw0lf

13

OpenID là một giao thức xác thực, OAuthOAuth WRAP là các giao thức ủy quyền. Chúng có thể được kết hợp với phần mở rộng lai OpenID .

Tôi rất muốn thấy mọi người xây dựng dựa trên các tiêu chuẩn có nhiều động lực (hỗ trợ sẵn có hơn, dễ dàng tham gia của bên thứ ba hơn), ngay cả khi họ không phù hợp chính xác cho ứng dụng. Trong trường hợp này, OAuth có động lượng, không phải CAS. Bạn phải có thể làm tất cả hoặc ít nhất là gần như tất cả những gì bạn cần làm với OAuth. Vào một thời điểm sau này trong tương lai, OAuth WRAP sẽ đơn giản hóa mọi thứ hơn nữa (nó tạo ra một số sự đánh đổi đáng giá bằng cách sử dụng mã thông báo mang và đẩy mã hóa xuống lớp giao thức), nhưng vẫn còn trong giai đoạn sơ khai, và trong khi đó, OAuth có lẽ sẽ làm tốt công việc

Cuối cùng, nếu bạn chọn sử dụng OpenID và OAuth, có nhiều thư viện hơn cho nhiều ngôn ngữ có sẵn cho bạn và cho bất kỳ ai khác cần tích hợp với hệ thống. Bạn cũng có nhiều nhãn cầu hơn khi nhìn vào các giao thức, đảm bảo rằng chúng thực sự an toàn như chúng được yêu cầu.


8

Đối với tôi, sự khác biệt thực sự giữa SSO và OAuth là cấp, không phải xác thực vì máy chủ thực hiện OAuth rõ ràng xác thực (bạn phải đăng nhập vào google, openId hoặc facebook để OAuth xảy ra với ứng dụng khách)

Trong SSO, người dùng / sysadmin cấp quyền cho người dùng cuối cùng truy cập vào ứng dụng trước trên "ứng dụng SSO" Trong OAuth, người dùng cuối cấp quyền truy cập ứng dụng vào "dữ liệu" của anh ta trên "ứng dụng OAuth"

Tôi không thấy lý do tại sao giao thức OAuth không thể được sử dụng như một phần của máy chủ SSO. Chỉ cần đưa ra màn hình cấp từ luồng và để máy chủ OAuth tra cứu cấp từ db hỗ trợ.


7

Bài cũ, nhưng điều này có thể hữu ích:

CAS 3.5 sẽ hỗ trợ oAuth là Máy khách và Máy chủ. Xem: https://wiki.jasig.org/display/CASUM/OAuth


3
Đối với những người xem điều này và có thể nhầm lẫn, CASđề cập ở đây là máy chủ CAS thay vì giao thức CAS .
Ng Sek Long
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.