SSO 与 CAS 还是 OAuth? [英] 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. 用户执行注销并同时从所有连接的应用程序中注销(单次注销).

据我所知，这正是 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 编写的.

我刚刚发现了 WRAP，它可能成为 OAuth 的后继者.它是微软、谷歌和雅虎指定的新协议.

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).

这篇关于SSO 与 CAS 还是 OAuth?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！