24

我想更多地了解解决单点登录的不同方法及其优缺点。您是否使用过一种特定的解决方案，告诉我它有什么好处，并告诉我有哪些限制或次优部分。

以下是我想知道或不明白的细节。

SSO 是一个巨大的主题，如wikipedia 中所列。我学的越多，我的问题就越多。

首先，我不明白CAS需要令牌验证，它有什么用？

它更安全吗？我想它很容易像任何人一样受到中间人攻击。客户也应该使用 ssl 吗？

让我们变得现实，这是我们的需求：如果已经在我们的一个应用程序中登录，则自动识别/登录用户。

  • my-php-app.com
  • 我的 java-app.com
  • my-ruby-app.com

（我们有许多 webapps，用不同的语言编写）

我们希望（保留）我们自己的身份验证规则和用户存储，但可能会添加一些 Oauth2 提供程序，如 facebook-connect。我们希望它对用户来说很简单，对使用它的开发人员来说也很简单。

你会怎么做？

  • 中国科学院？
  • 开放式？我可以使用它进行集中身份验证吗？
  • 其他？还是带有 OAuth 的服务器？

在客户端，您会使用 iframe（如灯箱）来显示重定向页面吗？为什么/为什么不？

另一个与 SSO 相关的问题：Saml经常（错误地？）混入 SSO 讨论中 - 如果我这么说我明白吗

将浏览器指向 www.yetanother-myapp.com 时，saml 实现不会提供 sso（自动登录）？

我研究过的一些相关的 SO 问题：

谢谢你教育我！

4

3 回答 3

24

Oauth 旨在对应用程序进行身份验证，以让它们以用户的名义行事。例如，推特客户端可能会使用用户的帐户发布推文。它可以用于 Facebook 显示的单点登录，但这需要一些额外的工作。

比较 CAS 和 OpenID

CAS 是一个具有单一账户权限的中心化系统。OpenID 是一个分布式系统，基本上任何人都可以在其中设置身份提供者。当然，您可以限制您的消费者只接受您自己的身份提供者。

OpenID 有两个（不兼容的）标准来提供关于帐户的附加属性，公共库或多或少地支持这些属性。在标准设置中，CAS 只提供用户名。虽然 CAS 理论上确实支持属性交换，但目前只有 PHP 客户端支持。

OpenID 和 CAS 都可以自动登录。如果用户已经登录，浏览器将立即重定向回您的应用程序。然而，在简单的设置中，如果用户未登录，身份提供者将显示一个登录页面。因此，如果您想允许匿名访问您的一方，这将需要人们单击专用的登录链接。

幸运的是，OpenID 和 CAS 都允许进行透明的登录尝试。在这种模式下，登录表单不显示。浏览器会在有或没有身份验证信息的情况下立即重定向回来。换句话说：您可以在所有新用户（没有会话）访问您的站点后立即将他们重定向到身份提供者。有一个很好的图表详细解释了这一点。CAS 称之为“网关模式”，它是通过将 gateway=true 附加到登录 URL 来实现的。在 OpenID 中称为“即时模式”，URL 参数为 openid.mode=checkid_immediate

CAS 支持单点注销。OpenID 没有。

我个人的经验是，CAS 非常易于设置，并且非常可靠，具有适用于所有常见编程语言的高质量库。OpenID 有许多微小的不兼容性，因为它是一个复杂得多的系统。然而，OpenID 允许使用 Google 帐户。

答案

首先，我不明白 CAS 需要令牌验证，它有什么用？

OpenID 和 CAS 都要求您让标识提供者验证提供的令牌。否则，攻击者可能能够创建自己的令牌或使用用户在注销之前创建的令牌。

客户也应该使用 ssl 吗？

是的。

在客户端，您会使用 iframe（如灯箱）来显示重定向页面吗？为什么/为什么不？

全屏重定向是最简单的事情。我会从它开始让它工作。无论如何，许多应用程序都需要在登录后重新加载当前页面，以显示仅对登录用户可见的部分。

Iframe存在登录完成后您需要摆脱它的问题。对于 CAS，有一个关于如何将CAS 登录表单直接嵌入到应用程序的 HTML 代码中的教程。另一种选择是像 Facebook Connect 那样显示一个弹出窗口。

于 2011-05-20T21:12:58.327 回答
7

我可以回答一些关于 CAS 的问题，因为我以前使用过它们。我没有使用 OAuth 的经验，因此不会对此发表评论。

首先，我不明白 CAS 需要令牌验证，它有什么用？

CAS 用于 SSO 目的。当您有多个想要从单一来源进行身份验证的应用程序（不同 TLD 上的桌面应用程序/网络应用程序）时使用它。

它更安全吗？我注意到它是基于重定向的，因此同样受到中间人攻击，就像没有额外令牌验证步骤的“自定义”身份验证服务器一样。我错过了 CAS 中的安全性吗？

身份验证服务器使用 SSL 来防止中间人攻击。但我看不出这是 SSO/CAS 所特有的问题，因为即使应用程序正在执行自己的身份验证，您也会遇到同样的问题。也许您可以告诉我们您担心使用 CAS 设置的中间人攻击类型

令牌的目的是提供单点注销和/或超时吗？（我们不想要它，我们的用户会讨厌我们。）我一直在研究 CAS，因为有一些很棒的 Ruby 实现，但我不确定它是否是我们需要的。

令牌只是应用程序无需密码即可对您进行身份验证的一种方式。它们是与您的用户凭据相关联的短寿命/一次性使用的令牌。应用程序将令牌提供给 CAS 服务器，并且 CAS 服务器回复一个凭证（如果有与之关联的凭证）。可以实现单点注销和超时，但与拥有令牌没有直接关系。

我希望这很清楚。我试图让它成为一个高级别的解释。如果有任何不清楚的部分或您想要更多细节，请随时询问细节。

编辑：我在http://www.jasig.org/cas/proxy-authentication找到了一个更好的关于 CAS 工作原理的简单解释（页面的其余部分讨论代理身份验证。哪个更复杂，但前几段是我们在这里讨论的简单案例）

我转到我的 Portal 实例。它会将我重定向到 CAS 登录。CAS 检测到我的安全 cookie 并执行单点登录，因此我不必再次提供我的用户名和密码。CAS 将我重定向回门户。门户验证票证，将我登录到门户我看到我的默认布局填充了一些很酷的频道，告诉我外面真的很冷，新闻中有什么。

请注意，门户网站没有获得我的密码。

于 2011-05-16T11:49:06.860 回答
0

这是基于我的经验：SSO（单点登录）与两种情况有关：-i）我非常了解你（涉及两方）ii）嘿朋友，认识我的朋友（涉及三方）

所以当然，第二种情况需要重定向/转发机制，因为通常第三方只是集中的身份验证/授权服务。

现在，在实施方面，SSO 需要评估两个领域：-

a) 不同方/系统（无论是相关组织的内部/外部）如何管理用户凭证。这称为身份管理。

b) SSO 信息应如何在各方之间流动？在大多数情况下都是安全的。

我认为身份管理比确定如何安全地传递信息更重要，因为在后半部分有很多可用的加密/解密技术。在一组启用 SSO 的系统中，它是完全不同的不安全管理。

现在身份管理可以通过一个简单的用户 ID（如果它在所有参与系统上可用）、内部开发的 XML 内容、SAML 有效负载或第三方令牌来实现。我认为令牌只是一个通用术语，指的是容器以安全的方式包含用户凭据以及有关执行的某些安全程序的信息。

@Ole，上面说了所有关于 SSO 的基础知识（从我的角度来看），我认为您应该更多地关注如何在多个系统中识别用户及其角色，即在您的情况下：-您的用户存储，打开 outh2 提供程序；所以把更多的想法放在身份管理上。

一种解决方案可能是（取决于您的预算和时间），您的企业可以花费精力以标准集成技术的形式创建内部集中式身份验证接口，例如 Web 服务和这些 API 背后，您可以有任何实现：您自己的提供商或第三方 oAuth 或两者的混合。您可以在您的 API 和作为决策者的提供者层之间实现一个引擎层。例如，引擎可以具有应用程序域和相应的身份验证提供程序映射。这样，您将为其所有客户端拥有统一的身份验证界面。

Client --> In-house Central API --> Engine --> Auth provider(s) 让我举个例子：- i) 你可以有一个 Webservice 暴露，命名可能是 singleSigonService。XML 有效负载可能类似于：-

<SingleSignOnReqType>   <sourceID>XYZ</sourceID>    <source-domain>my-java-app.com</source-domain>  <user-credentials>...</<user-credentials>
        <security-credentials>...</<security-credentials> </SingleSignOnReqType>

ii) Web 服务客户端将对集中式引擎层（以任何技术实现）进行 SSO 调用，该层可能会进行验证和簿记工作，并且可能基于传入 XML 中的源域（例如 my-java-app.com）会将请求委托给 Oauth2 提供者，例如 facebook-connect。因此，您的引擎（决策者）将管理您在要求中提到的身份验证规则。

所以基本上所有的消费者应用程序都将有一个基于 Web 服务的统一接口来连接您的 SSO 解决方案。这就是我所指的内部集中式 API。

于 2011-05-19T06:04:13.247 回答