我想知道是否应该使用CAS协议或OAuth +某些身份验证提供程序进行单点登录.
示例场景:
用户尝试访问受保护资源,但未经过身份验证.
应用程序将用户重定向到SSO服务器.
如果通过身份验证,则用户从SSO服务器获取令牌.
SSO重定向到原始应用程序.
原始应用程序根据SSO服务器检查令牌.
如果令牌没问题,将允许访问,并且应用程序知道用户ID.
用户执行注销并同时从所有连接的应用程序注销(单点注销).
据我所知,这正是CAS发明的.CAS客户端必须实现CAS协议才能使用身份验证服务.现在我想知道在客户(消费者)网站上使用CAS或OAuth.OAuth是CAS的那部分的替代品吗？OAuth作为新的事实上的标准应该优先考虑吗？是否有一个易于使用的(不是Sun的OpenSSO!)更换为CAS支持不同的方法,如用户名/密码,OpenID的,TLS certifactes认证部...？
语境:
不同的应用程序应该依赖于SSO服务器的身份验证,并且应该使用类似会话的东西.
应用程序可以是GUI Web应用程序或(REST)服务.
SSO服务器必须提供用户标识,这是从中央用户信息存储获取有关用户的更多信息(如角色,电子邮件等)所必需的.
单签出应该是可能的.
大多数客户端都是用Java或PHP编写的.
我刚刚发现WRAP,它可能成为OAuth的继任者.这是微软,谷歌和雅虎指定的新协议.
附录
我了解到OAuth不是为验证而设计的,即使它可用于实现SSO,但只能与OpenID等SSO服务一起使用.
OpenID在我看来是"新CAS".CAS具有OpenID未命中的一些功能(如单点注销),但在特定场景中添加缺失部分并不困难.我认为OpenID已被广泛接受,最好将OpenID集成到应用程序或应用程序服务器中.我知道CAS也支持OpenID,但我认为CAS对OpenID来说是可有可无的.
OpenID不是CAS的"后继者"或"替代者",它们在意图和实施方面都是不同的.
CAS 集中了身份验证.如果您希望所有(可能是内部)应用程序要求用户登录到单个服务器(所有应用程序都配置为指向单个CAS服务器),请使用它.
OpenID 分散了身份验证.如果您希望应用程序接受用户登录他们想要的任何身份验证服务(用户提供OpenID服务器地址 - 实际上,'username'是服务器的URL),请使用它.
以上都不处理授权(没有扩展和/或定制).
OAuth处理授权,但它不能替代传统的"USER_ROLES表"(用户访问权限).它处理第三方的授权.
例如,您希望应用程序与Twitter集成:用户可以在更新数据或发布新内容时自动发送推文.您希望代表用户访问某些第三方服务或资源,而无需获取其密码(这对用户来说显然是不安全的).该应用程序要求Twitter访问,用户授权(通过Twitter),然后该应用程序可以访问.
因此,OAuth不是单点登录(也不是CAS协议的替代品).它与您无法控制用户可以访问的内容有关.它是关于让用户控制第三方如何访问他们的资源.两个非常不同的用例.
根据您描述的背景,CAS可能是正确的选择.
[更新]
也就是说,如果您将用户的身份视为安全资源,则可以使用OAuth实施SSO.这就是"与GitHub注册"和基本上喜欢做的事情.可能不是协议的初衷,但可以做到.如果您控制OAuth服务器,并限制应用程序仅对其进行身份验证,那就是SSO.
但是没有强制注销的标准方法(CAS具有此功能).
我倾向于这样想:
如果您控制/拥有用户身份验证系统并且需要支持需要集中身份验证的异构服务器和应用程序,请使用CAS.
如果要支持来自您不拥有/支持的系统(即Google,Facebook等)的用户身份验证,请使用OAuth.
OpenID是一种身份验证协议,OAuth和OAuth WRAP是授权协议.它们可以与混合OpenID扩展组合使用.
I'd strongly prefer to see people building on top of standards that have a lot of momentum (more available support, easier to get third parties involved), even if they aren't an exact fit for the application at hand. In this case, OAuth has the momentum, not CAS. You ought to be able to do all or at least nearly all of what you need to do with OAuth. At some later point in the future, OAuth WRAP should simplify things further (it makes some worthwhile trade-offs by using a bearer token and pushing encryption down to the protocol layer), but it's still in its infancy, and in the meantime, OAuth will probably do the job just fine.
Ultimately, if you choose to use OpenID and OAuth, there are more libraries for more languages available to you and to anyone else who needs to integrate with the system. You also have a lot more eyeballs looking at the protocols, making sure they really are as secure as they're supposed to be.
旧帖子,但这可能有用:
CAS 3.5将支持oAuth作为客户端和服务器.请参阅:https://wiki.jasig.org/display/CASUM/OAuth
对我来说，SSO和OAuth之间的真正区别是授予而不是身份验证，因为实现OAuth的服务器显然具有身份验证（您必须登录到google，openId或facebook才能使OAuth与客户端应用一起发生）
在SSO中，高级用户/系统管理员会在“ SSO应用程序”上预先授予最终用户对应用程序的访问权限。在OAuth中，最终用户在“ OAuth应用程序”上向最终用户授予对其“数据”的应用程序访问权限
我看不到为什么不能将OAuth协议用作SSO服务器的一部分。只需从流程中取出授权屏幕，然后让OAuth服务器从后备数据库中查找授权即可。
京公网安备 11010802040832号 | 京ICP备19059560号-6 