使用CAS或OAuth进行SSO？ [英] SSO with CAS or OAuth?

问题描述

我想知道我应该使用 CAS 协议还是 OAuth +一些用于单点登录的身份验证提供程序。

I wonder if I should use the CAS protocol or OAuth + some authentication provider for single sign-on.

示例场景：

1. 用户尝试访问受保护的资源，但未通过身份验证。


2. 应用程序将用户重定向到SSO服务器。


3. 如果经过蜜蜂身份验证，则用户将从SSO服务器获得令牌。


4. SSO重定向到原始应用程序。


5. 原始应用程序针对SSO服务器检查令牌。


6. 如果令牌正常，将允许访问并且应用程序知道用户ID。


7. 用户执行注销，并同时从所有连接的应用程序中注销（单次注销）。

1. A User tries to access a protected resource, but is not authenticated.
2. The application redirects the user to the SSO server.
3. If beeing authenticated the user gets a token from the SSO server.
4. The SSO redirects to the original application.
5. The original application checks the token against the SSO server.
6. If the token is ok, access will be allowed and the application knows of the user id.
7. The user performs a log-out and is logged out from all connected application at the same time (single sign-out).

据我了解，这正是CAS发明的目的。 CAS客户端必须实现CAS协议才能使用身份验证服务。现在，我想知道要在客户端（消费者）站点上使用CAS还是OAuth。 OAuth是否可以替代CAS的那部分？是否应首选OAuth作为事实上的新标准？是否有易于使用的（不是Sun OpenSSO！）替代CAS的身份验证部分，支持用户名/密码，OpenID，TLS证书等不同方法...？

As far as I understand that is exactly what was CAS invented for. CAS clients have to implement the CAS protocol to use the authentication service. Now I'm wondering about to use CAS or OAuth at the client (consumer) site. Is OAuth a replacement for that part of CAS? Should OAuth as a new de-facto standard be preferred? Is there an easy to use (not Sun OpenSSO!) replacement for the authentication part of CAS supporting different methods like username/password, OpenID, TLS certifactes ...?

上下文：

• 不同的应用程序应依赖SSO服务器的身份验证，并应使用类似会话的内容。


• 应用程序可以是GUI Web应用程序，也可以是（REST）服务。


• SSO服务器必须提供用户ID，这对于获取有关用户（例如角色）的更多信息是必需的，电子邮件等来自中央用户信息存储的电子邮件。


• 应该可以进行单次注销。


• 大多数客户端都是用Java或PHP编写的。

• Different applications should rely on the authentication of the SSO server and should use something session-like.
• The applications can be GUI web applications or (REST) serivces.
• The SSO server must be provide a user id, which is necessary to get more information about the user like roles, email and so on from a central user information store.
• Single Sign-out should be possible.
• Most clients are written in Java or PHP.

我只是发现了WRAP ，它可以成为OAuth的后续产品。这是Microsoft，Google和Yahoo指定的新协议。

I've just discovered WRAP, which could become the OAuth successor. It is a new protocol specified by Microsoft, Google and Yahoo.

附录

我了解到，即使可以将OAuth用来实现SSO，它也不是用于身份验证的，而是仅与OpenID之类的SSO服务一起使用。

I've learned that OAuth was not designed for authentication even it could be used to implement SSO, but only together with a SSO service like OpenID.

在我看来，OpenID成为新CAS。 CAS具有一些OpenID遗漏的功能（例如单点注销），但是在特定情况下添加遗漏的部分并不难。我认为OpenID已被广泛接受，最好将OpenID集成到应用程序或应用程序服务器中。我知道CAS也支持OpenID，但是我认为CAS与OpenID无关。

OpenID seems to me to be the "new CAS". CAS has some features OpenID misses (like single sign-out), but it should not be to hard to add the missing parts in a particular scenario. I think OpenID has broad acceptance and it is better to integrate OpenID into applications or application servers. I know that CAS also supports OpenID, but I think CAS is dispensable with OpenID.

推荐答案

OpenID不是继承人，或者对于CAS，替代在意图和实现上都是不同的。

OpenID is not a 'successor' or 'substitute' for CAS, they're different, in intent and in implementation.

CAS 集中身份验证。如果希望所有（可能是内部的）应用程序要求用户登录到单个服务器（所有应用程序都配置为指向单个CAS服务器），请使用它。

CAS centralizes authentication. Use it if you want all your (probably internal) applications to ask users to login to a single server (all applications are configured to point to a single CAS server).

OpenID 去中心化身份验证。如果您希望您的应用程序接受用户登录所需的任何身份验证服务（用户提供OpenID服务器地址-实际上，用户名是服务器的URL），请使用它。

OpenID decentralizes authentication. Use it if you want your application to accept users login to whatever authentication service they want (the user provides the OpenID server address - in fact, the 'username' is the server's URL).

以上都不处理授权（无扩展名和/或自定义）。

None of the above handle authorization (without extensions and/or customization).

OAuth处理授权，但不能代替传统的'USER_ROLES表'（用户访问权限）。

OAuth handles authorization, but it is not a substitute for the traditional 'USER_ROLES table' (user access). It handles authorization for third-parties.

例如，您希望您的应用程序与Twitter集成：用户可以允许其在更新数据或发布信息时自动发推新内容。您想代表用户访问某些第三方服务或资源，而无需获取他的密码（这对用户来说显然是不安全的）。该应用程序要求Twitter进行访问，用户（通过Twitter）对其进行授权，然后该应用程序才可以访问。

For example, you want your application to integrate with Twitter: a user could allow it to tweet automatically when they update their data or post new content. You want to access some third-party service or resource on behalf of a user, without getting his password (which is obviously unsecure for the user). The application asks Twitter for access, the user authorizes it (through Twitter), and then the app may have access.

因此，OAuth是与单点登录无关（也不能替代CAS协议）。这不是您控制用户可以访问的内容。这是关于让用户来控制第三方如何访问其资源。两个非常不同的用例。

So, OAuth is not about Single Sign-On (nor a substitute for the CAS protocol). It is not about you controlling what the user can access. It is about letting the user to control how their resources may be accessed by third-parties. Two very different use-cases.

就您所描述的上下文而言，CAS可能是正确的选择。

To the context you described, CAS is probably the right choice.

[更新]

也就是说，如果您将用户的身份视为安全资源，则可以使用OAuth实施SSO。基本上就是使用GitHub注册之类的方法。可能不是协议的初衷，但是可以做到。如果您控制OAuth服务器，并限制应用程序仅对其进行身份验证，那就是SSO。

That said, you can implement SSO with OAuth, if you consider the identity of the user as a secured resource. This is what 'Sign up with GitHub' and the likes do, basically. Probably not the original intent of the protocol, but it can be done. If you control the OAuth server, and restrict the apps to only authenticate with it, that's SSO.

没有强制退出的标准方法，（CAS具有此功能）。

No standard way to force logout, though (CAS has this feature).

这篇关于使用CAS或OAuth进行SSO？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！