2010-01-09 32 views
157

Tôi tự hỏi mình có nên sử dụng giao thức CAS hoặc OAuth + một số nhà cung cấp xác thực để đăng nhập một lần hay không.SSO với CAS hoặc OAuth?

Ví dụ Kịch bản:

  1. người dùng cố gắng truy cập vào một tài nguyên được bảo vệ, nhưng không được chứng thực.
  2. Ứng dụng chuyển hướng người dùng đến máy chủ SSO.
  3. Nếu beeing xác thực người dùng nhận được một 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 là ok, quyền truy cập sẽ được cho phép và ứng dụng biết về 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ả ứng dụng được kết nối cùng một lúc (đăng xuất một lần).

Theo tôi hiểu đó chính xác là những gì CAS được phát minh. Khách hàng CAS phải triển khai 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? OAuth có nên là tiêu chuẩn de-facto mới được ưa thích không? Có một cách dễ dàng để sử dụng (không phải Sun OpenSSO!) Thay thế 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, OpenID, chứng chỉ TLS ...?

Bối cảnh:

  • ứ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ì đó phiên như thế nào.
  • Các ứng dụng có thể là các ứng dụng web GUI hoặc (REST) ​​serivces.
  • Máy chủ SSO phải 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ừ cửa hàng thông tin người dùng trung tâm.
  • Đăng xuất một lần có thể thực hiện được.
  • Hầu hết khách hàng được viết bằng Java hoặc PHP.

Tôi vừa mới discovered WRAP, có thể trở thành người kế thừa 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 để thực hiện SSO, nhưng 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ỏ sót (như đăng xuất một lần), nhưng không khó để thêm các phần bị thiếu trong một kịch bản cụ thể. Tôi nghĩ OpenID đã 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ĩ rằng CAS là không thể phân phối 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 tôi nhận thức được rằng đã bao phủ nó đã chỉ ra rằng đó là bất cứ nơi nào từ nhẹ đến cực kỳ khó hiểu cho người mới và người sử dụng điện như nhau. 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 trên cơ sở 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. –

+15

Không đồng ý rằng đăng xuất một lần là một sự phản đối. Tất cả phụ thuộc vào các ứng dụng được đề cập. Đối với các ứng dụng web bằng cách nào đó liên quan đến nhau, tức là google mail và lịch google, điều đó có nghĩa là nếu bạn đăng xuất một cách rõ ràng, bạn sẽ đăng xuất khỏi tài khoản kia. 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. – ashwoods

+3

Lưu ý rằng câu hỏi này ban đầu được yêu cầu 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

Trả lời

206

OpenID không phải là 'người kế thừa' hoặc 'thay thế' cho CAS, chúng khác nhau, có chủ ý và đang triển khai.

CAS tập trung xác thực 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 bạn yêu cầu người dùng đăng nhập vào một máy chủ duy nhất (tất cả các ứng dụng được cấu hình để trỏ đến một máy chủ CAS đơn).

OpenID phân cấp chứng thực. Sử dụng nó nếu bạn muốn ứng dụng của bạn 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 - trên thực tế, 'tên người dùng' là URL của máy chủ).

Không có ủy quyền xử lý nào ở trên (không có tiện ích 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 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 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 mình (điều này rõ ràng là 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 ủy quyền cho 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 thay thế cho giao thức CAS). Không phải là về số 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 các bên thứ ba truy cập. Hai trường hợp sử dụng rất khác nhau.

Với ngữ 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ể thực hiện SSO với OAuth, nếu bạn xem xét danh tính của người sử dụng như một nguồn lực bảo đảm. Đây là những gì 'Đăng ký với GitHub' và những người thích làm, về cơ bản. Có lẽ không phải là ý định ban đầu của giao thức, nhưng nó có thể được thực hiện. Nếu bạn kiểm soát máy chủ OAuth và hạn chế các ứng dụng chỉ xác thực với máy chủ đó, đó là SSO.

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

+6

Mặc dù OAuth chủ yếu là về ủy quyền, nó có thể được sử dụng như thể nó là 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 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. –

+1

Hơn nữa, như đã nói trong [Trả lời Bertl] (http://stackoverflow.com/a/10226744/535203) CAS hiện cung cấp OAuth cho cả máy khách hoặc máy chủ. –

+0

Câu trả lời thú vị! Cảm ơn bạn đã làm rõ! – emanuelcds

12

OpenID là 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 hybrid OpenID extension.

Tôi rất muốn thấy mọi người xây dựng dựa trên tiêu chuẩn có nhiều động lực (hỗ trợ nhiều hơn, dễ dàng hơn để các bên thứ ba tham gia), ngay cả khi họ không phù hợp với ứng dụng trong tầm tay . Trong trường hợp này, OAuth có động lượng chứ không phải CAS. Bạn phải có khả năng làm tất cả hoặc ít nhất gần như tất cả những gì bạn cần làm với OAuth. Tại một số đ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ó làm cho một số giao dịch đá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 trứng nước và trong thời gian chờ đợi, 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ữ khả dụng 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ó rất nhiều nhãn cầu nhìn vào các giao thức, đảm bảo chúng thực sự an toàn như chúng được cho là vậy.

40

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 phải hỗ trợ một tập heterogenous các máy chủ và các ứng dụng mà cần chứng 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.).

+4

OpenID là giao thức xác thực, OAuth là giao thức ủy quyền. – zenw0lf

3

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

Trong SSO, người dùng điện/sysadmin cấp cho người dùng cuối quyền 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ùng cấp quyền truy cập ứng dụng vào "dữ liệu" của anh ấy "Ứng dụng OAuth"

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

(2 xu của tôi)

Các vấn đề liên quan