简单的 SSO - 使用自定义身份验证 - CAS 或某些 Oauth 或 openid 服务器？
我想了解更多关于 解决 Single 的不同方法 登录及其优缺点。您是否使用过一种特定的解决方案，请告诉我它的优点以及局限性或次优部分。
下面 是我想要的细节 知道或者不明白。
SSO 是一个很大的话题，维基百科中列出。我学得越多，我的问题就越多。
首先，我不明白CAS进行令牌验证的必要性，它有什么好处？
它更安全吗？我猜它很容易受到中间人攻击。客户端也应该使用 ssl 吗？
让我们面对现实，这就是我们的需求：如果已经登录我们的应用之一，则自动识别/登录用户。
- my-php-app.com
- my-java-app.com
- my-ruby-app.com
（我们有许多 Web 应用程序，用不同的语言编写）
我们希望（保留）我们自己的身份验证规则和用户存储，但可能会添加一些Oauth2 提供商，如 facebook-connect。我们希望它对于用户来说非常简单，对于使用它的开发人员来说也非常简单。
你会怎么办？
- CAS？
- 开放ID？我可以使用它进行集中身份验证吗？
- 其他？或者有 OAuth 的服务器？
在客户端，您会使用 iframe（例如灯箱）来显示重定向页面吗？为什么/为什么不？
另一个与 SSO 相关的问题：Saml 经常（错误地？）混合到 SSO 讨论中 - 如果我这样说，我能理解吗
saml 实现不会提供 指向时的 sso（自动登录） 浏览器访问 www.yetanother-myapp.com？
我研究过的一些相关的SO问题：
- SSO with CAS or OAuth? - 他的需求描述不是我想要的，他描述 CAS...
- OpenID 作为单点登录选项？ - 好吧，我不确定我从中学到了什么 它。
谢谢你教育我！
I'd like to know more about the
different ways of solving Single
Sign-On and their pros and cons. Have you worked with one particular solution, tell me what's good about it and tell me what the limitations or suboptimal parts are.Below
are the details of what I'd like to
know, or don't understand.
SSO is a huge topic, as listed in the wikipedia. The more I learn the more questions I have.
First of all, I don't understand the need for token verifications of CAS, what is it good for?
Is it more secure? I guess it's vulnerable to man-in-the-middle attack like any. Should clients also use ssl?
Let's get real, this is our need: Automaticaly recognize/sign-in user if already logged in at one of our apps.
- my-php-app.com
- my-java-app.com
- my-ruby-app.com
(we have many webapps, written in different languages)
We want (to keep) our own authentication rules and users store, but might add some Oauth2 provider, as facebook-connect. We want it dead simple for the users and simple for developers using it.
What would you do?
- CAS?
- Openid? Can I have centralized authentication with it?
- Other? Or a server with OAuth?
On the client side, would you use an iframe, like lightbox, to show the redirected page? Why/Why not?
Yet another SSO related question: Saml is often (wrongly?) mixed into the SSO discussions - do I understand if I say that
a saml implementation would not provide
sso (autologin) when pointing the
browser to www.yetanother-myapp.com?
Some related SO questions I've studied:
- SSO with CAS or OAuth? - His need description is not what I want, he describes CAS...
- OpenID as a Single Sign On option? - Well, I'm not sure what I learned from it.
Thanks for educating me!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Oauth 旨在对应用程序进行身份验证，让它们以用户的名义进行操作。例如，Twitter 客户端可以使用用户的帐户发布推文。正如 Facebook 所示，它可以用于单点登录，但这需要一些额外的工作。
CAS 和 OpenID 的比较
CAS 是一个具有单一帐户权限的集中式系统。 OpenID 是一个分布式系统，基本上任何人都可以设置身份提供商。当然，您可以限制您的消费者仅接受您自己的身份提供商。
OpenID 有两个（不兼容的）标准来提供有关帐户的附加属性，公共库或多或少都支持这些属性。在标准设置中，CAS 仅提供用户名。虽然 CAS 理论上确实支持属性交换，但目前只有 PHP 客户端支持< /a>.
OpenID和CAS都可以自动登录。如果用户已经登录，浏览器将立即重定向回您的应用程序。然而，在简单的设置中，如果用户未登录，身份提供商将显示登录页面。因此，如果您想允许匿名访问您的一侧，则需要人们单击专用的登录链接。
幸运的是，OpenID 和 CAS 都允许透明登录尝试。在此模式下，不显示登录表单。无论是否有身份验证信息，浏览器都会立即重定向回来。换句话说：您可以在所有新用户访问您的网站后立即将他们重定向到身份提供商（无需会话）。有一个漂亮的图表解释了这一点详细。 CAS 称之为“网关模式”，它是通过在登录 URL 后附加 gateway=true 来实现的。在 OpenID 中称为“立即模式”，URL 参数为 openid.mode=checkid_immediate
CAS 支持单点退出。 OpenID 没有。
我个人的经验是，CAS 非常容易设置，并且非常可靠，具有适用于所有常见编程语言的高质量库。 OpenID 有许多微小的不兼容性，因为它是一个复杂得多的系统。然而，OpenID 允许使用 Google 帐户。
答案
OpenID 和 CAS 都要求您让身份提供商验证提供的令牌。否则，攻击者可能能够创建自己的令牌或使用用户在注销之前创建的令牌。
是的。
完整的屏幕重定向是最简单的事情。我会从那开始让它发挥作用。许多应用程序都需要在登录后重新加载当前页面，以便显示仅对登录用户可见的部分。
Iframe 存在一个问题，您需要在登录完成后将其删除。对于 CAS，有一个教程，介绍如何直接嵌入 CAS 登录表单到应用程序的 HTML 代码中。另一种选择是像 Facebook Connect 那样显示一个弹出窗口。
Oauth is designed to authenticate application to let them act in the name of a user. For example a twitter client may post tweets with the account of a user. It can be used for single sign on as Facebook shows, but this requires a bit of additional work.
Comparing CAS and OpenID
CAS is a centralized system with one account authority. OpenID is a distributed system where basically anyone can setup an identity provider. Of course you can limit your consumer to only accept your own identity provider.
OpenID has two (incompatible) standards to provide additional attributes about the account, which are supported more or less by the common libraries. In the standard setup CAS only provides the username. While CAS does support attribute exchange in theory, at the moment only the PHP client supports it.
Both OpenID and CAS can do automatic login. If the user is already logged in, the browser will be redirected back to your application immediately. In a simple setup the identity provider, however, will display a login page, if the user is not logged in. So if you want to allow anonymous access to your side, this will require people to click a dedicated login link.
Luckily both OpenID and CAS allow a transparent login attempt. In this mode, the login form is not shown. The browser is redirected back immediately with or without authentication information. In other words: You can redirect all new users (without a session) to the identity provider as soon as they visit your site. There is a nice diagram explaining this in detail. CAS calls it "gateway mode" and it is achieved by appending gateway=true to the login URL. In OpenID it is called "immediate mode" and the URL parameter is openid.mode=checkid_immediate
CAS supports single sign out. OpenID does not.
My personal experience is that CAS is very easy to set up and very reliable with high quality libraries for all common programming languages. OpenID has many tiny incompatibilities as it is a much more complex system. OpenID, however, allows the usage of Google accounts.
Answers
Both OpenID and CAS require you to let the identify provider verify the provided token. Otherwise an attacker may be able to create his own token or use a token that was created by a user before he logged out.
Yes.
A full screen redirect is the most simple thing to do. I would start with that to get it working. Many application require a reload of the current page after login anyway in order to show parts that are only visible to logged in users.
An Iframe has the issue that you need to get rid of it once the login was completed. For CAS there is a tutorial on how to directly embed the CAS login form into the HTML code of the application. Another alternative is to show a pop up window like Facebook Connect does.
我可以回答一些关于 CAS 的问题，因为我以前使用过它们。我没有 OAuth 经验，因此不会对此发表评论。
CAS 用于 SSO 目的。当您有多个应用程序（不同 TLD 上的桌面应用程序/网络应用程序）想要从单一来源进行身份验证时，可以使用它。
身份验证服务器使用 SSL 来防止中间人攻击。但我不明白这是 SSO/CAS 特有的问题，因为即使应用程序正在执行自己的身份验证，您也会遇到同样的问题。也许您可以告诉我们您担心 CAS 设置会发生哪种类型的 MitM 攻击
令牌只是应用程序在无需密码的情况下对您进行身份验证的一种方式。它们是与您的用户凭据关联的生命周期短/一次性使用的令牌。应用程序向 CAS 服务器提供令牌，CAS 服务器会回复一个凭证（如果有与之关联的凭证）。可以实现单点注销和超时，但与拥有令牌没有直接关系。
我希望这一点很清楚。我试图对其进行高层次的解释。如果有任何不清楚的部分或者您想了解更多细节，请随时询问细节。
编辑：我在 http://www.jasig.org 找到了关于 CAS 如何工作的更好的简单解释/cas/proxy-authentication （页面的其余部分讨论代理身份验证。这更复杂，但前几段是我们在这里讨论的简单情况）
I can answers some of the question regarding CAS as I have used them before. I've no experience with OAuth and therefore wont comment on it.
CAS is used for SSO purposes. Its used when you have multiple applications(desktop apps/webapps on different TLD) that want to do authentication from a single source.
Authentication servers uses SSL to prevent MitM attacks. But I don't see how this a problem specific with SSO/CAS since you would have the same problem even if the app is doing its own authentication. Maybe you can tell us what kind of MitM attacks are you worried about with the CAS setup
The tokens are just a way for the application to authenticate you without having your password. They are short lifespan/single used token that is associated to your user credentials. The application provide the token to the CAS server and the CAS server reply with a credential, if any is associated with it. Single signout and timeout is possible to implement but not directly tied to having the tokens.
I hope this is clear. I tried to make it a high level explanation. Feel free to ask for specifics if theres any part that is not clear or you want more specifics about.
EDIT: I found a better put simple explanation of how CAS works at http://www.jasig.org/cas/proxy-authentication (The rest of the page talks about proxied authentication. Which is more complex but the first few paragraph is the simple case we are talking about here )
这是根据我的经验：
SSO（单点登录）与两种场景相关：-
i) 我很了解你（涉及两方）
ii）嘿朋友，见见我的朋友（涉及三方）
当然，第二种情况需要重定向/转发机制，因为通常第三方只是集中式身份验证/授权服务。
现在，在实施方面，SSO 需要评估两个方面：
a) 不同方/系统（无论是相关组织的内部/外部）如何管理用户凭证。这称为身份管理。
b) SSO 信息应如何在各方之间流动？当然在大多数情况下都是安全的。
我认为身份管理比确定如何安全地传递信息更重要，因为对于后者，有很多可用的加密/解密技术。在一组启用 SSO 的系统中，唯一不同的是身份管理。
现在身份管理可以通过一个简单的用户ID（如果它在所有参与系统上可用），或通过内部开发的XML内容，或SAML有效负载，或第三方令牌来实现。我认为令牌只是一个通用术语，指的是以安全方式包含用户凭据的容器以及有关所执行的某些安全程序的信息。
@Ole，在上面说了有关 SSO 的基础知识（从我的角度来看）之后，我认为您应该更多地关注用户和用户如何使用 SSO。他们的角色在多个系统中被识别，即在您的情况下：-您的用户商店、开放的 outh2 提供商；因此，要更多地考虑身份管理。
一种解决方案可能是（取决于您的预算和时间），您的企业可以花费精力以标准集成技术的形式创建内部集中式身份验证接口，例如 Web 服务，并且在这些 API 背后，您可以拥有任何实现：您自己的提供商或第三方 oAuth 或两者的混合。您可以在 API 和决策者提供者层之间实现一个引擎层。例如，引擎可以具有应用程序域和相应的身份验证提供者映射。
这样您就可以为所有客户端提供统一的身份验证界面。
客户-->内部集中式API -->发动机-->身份验证提供商
让我给你举个例子：-
i) 您可以公开一个 Web 服务，名为 singleSigonService。 XML 有效负载可能类似于：-
ii) Web 服务客户端将对集中式引擎层（以任何技术实现）进行 SSO 调用，该引擎层可以执行验证和簿记工作，并且可以基于源域（例如 my-java- app.com）传入的 XML 会将请求委托给 Oauth2 提供商，例如 facebook-connect。因此，您的引擎（决策者）将按照您在要求中提到的方式管理身份验证规则。
因此，基本上所有消费者应用程序都会有一个基于统一 Web 服务的 SSO 解决方案接口。这就是我所说的内部集中式 API。
This is based on my experience:
SSO (Single sign on) is related to two scenarios:-
i) I know you very well (two parties involved)
ii) Hey friend, meet my friend (three parties involved)
So ofcourse, 2nd scenario need a redirect/forward mechanism because usually third party is only centralized authentication/authorization service.
Now, implementation wise, SSO requries two areas to be evaluated:-
a) how different parties/systems(whether internal/external to organisation in question) are managing user credentials. This is called Identity management.
b) how SSO information should flow between parties? Ofcouse securly in most of scenario.
I think Identity management is more crucial than determining how-to-pass-information-securly because for latter part there are lot of encryption/decryption techniques available. It is indetity management which is unqiuely different in one set of SSO enabled systems.
Now Identity management can be implemented by a simple userID(if it is available on all participating systems),or by in-house developed XML content, or SAML payload,or a third party token. I think token is just a generic term referring to container containing user credentials in secured manner and also information about some security procedures performed.
@Ole, having said all above about basics of SSO (from my perspective), I think you should concentrate more on how users & their roles are identified across multiple systems i.e. in your case:- your users store, open outh2 provider; so put more thinking on identity management.
One solution could be (depending upon your budget and time), your enterprise can spend effort on creating in house centralized authentication interface in form of standard integration technologies for e.g. web service and behind those API, you can have any implementation: your own provider or third party oAuth or mixed of both. You can implement an engine layer in between your API and provider layer which is decision maker. For e.g. engine can have application domain and corresponding auth provider mapping.
This way you will have uniform authentication interface for all of its clients.
Client --> In-house centralized API --> Engine --> Auth provider(s)
let me give u an example:-
i) you can have a Webservice exposed , named may be singleSigonService. XML payload may be like:-
ii) A web service Client would make SSO call to centralized engine layer (implemented in any technology), which may do validations and bookkeeping stuff and may be based on source-domain (for e.g. my-java-app.com) in incoming XML would delegate the request to Oauth2 provider such as facebook-connect. So your engine, the decision maker, would manage authentication rules as you mentioned in your requirement.
So basically all consumer applications will have an unified web service based interface to your SSO solution.This is what I refer to In-house centralized API.