我只是在寻找不同的意见。您认为 OpenID 是一个很好的“单点登录”解决方案吗?
对于普通用户来说,它的工作方式似乎有点令人困惑,并且可能存在与“将所有鸡蛋放在同一个篮子中”相关的问题。
无论如何,有没有人尝试在有许多不同应用程序(Wordpress、Elgg、Media Wiki、..)的 Intranet 上下文中实现他自己的 OpenId 解决方案?
我认为这可能是解决“数字身份”问题的一个很好的解决方案,但我不知道它是否适用于“登录一次并浏览 Intranet”问题。
意见?
我只是在寻找不同的意见。您认为 OpenID 是一个很好的“单点登录”解决方案吗?
对于普通用户来说,它的工作方式似乎有点令人困惑,并且可能存在与“将所有鸡蛋放在同一个篮子中”相关的问题。
无论如何,有没有人尝试在有许多不同应用程序(Wordpress、Elgg、Media Wiki、..)的 Intranet 上下文中实现他自己的 OpenId 解决方案?
我认为这可能是解决“数字身份”问题的一个很好的解决方案,但我不知道它是否适用于“登录一次并浏览 Intranet”问题。
意见?
此外,SSO(正如您所提到的)通常意味着我只需要登录一次(大概是我的工作站),然后从那里开始,我不需要在任何地方登录。
OpenID 当然不能解决这个问题。例如,如果我使用 OpenID 登录 StackOverflow,并不意味着我不需要使用相同的 openID 再次登录另一个网站。
我不得不说,我绝对同意关于“普通”互联网用户太难的说法。我认为 OpenID 仍然可以被认为是“新的”,即使最初的提议是在 2005 年提出的。更多的高流量网站将其作为创建帐户的一种选择,而不是要求用户提供 OpenID。
在我看来,只要与 OpenID 一起提供正常的用户名/密码帐户创建,普通互联网用户自然会开始尝试并最终坚持使用 OpenID。
身份验证问题与在任何网站上注册一样适用于 OpenID。您使用密码信任网站(假设您不使用密码存储程序),因此不应将其用于 OpenID。
除此之外,帐户创建的标准化对于 Web 开发人员来说绝对是奶油肉汁。我只是希望不必担心正常的创建过程,而只需放入 OpenID 库并将其引用到数据库即可。
我花了一段时间才理解 OpenID(这么多提供商!),但我真的很喜欢这个概念。将其与 Gravatar 联系起来,重写您的个人资料会更加轻松 - 可能是一两个字段。
唯一的问题是您必须信任您的 OpenID 提供者——但这并不是我所说的问题,更像是常识。
编辑:对 OpenID 提供者有问题的人应该考虑设置一个新的。我的提供商是 myopenid.com,我没有遇到任何问题。您可以设置多个角色(如个人资料),因此我有一个用于博客评论,一个用于像这样的技术网站。
至于拥有一个新的 SO 配置文件,Jeff 说过能够更改您的 OpenID 而不会在未来丢失您的配置文件统计信息。
OpenID 有一个小问题。
使用 OpenID 无缝登录需要在域之间进行自动(未经验证)重定向。
这使得 OpenID 服务器成为第 3 方。如果您关闭第 3 方 cookie 并且您的浏览器严格遵循 RFC2965 3.3.6 中的不可验证交易规则,这可能会导致 OpenID 服务器的 cookie 被拒绝。
这方面的一个例子是 Opera。如果您关闭第 3 方 cookie(通过将全局设置为“仅接受来自我访问的站点的 cookie”),您将无法使用 OpenID 登录,因为您提交的服务器脚本会自动(无需您的交互来批准)重定向您访问 OpenID 服务器,OpenID 服务器也会执行相同的操作来让您返回。
但是,您在 Firefox、IE 和 Safari 中幸运的是,它们相应地阻止了 3rd 方 cookie,因为它们在多种情况下违反了 RFC2965。
在这种情况下必须使用 OpenID 会对更合规的客户端造成损害。
作为一种解决方法,在 Opera 中,除了接受所有 cookie 之外,您还可以转到工具 -> 首选项 -> 高级 -> 网络并关闭自动重定向。然后,您将能够验证并单击您被重定向到的每个链接,并且不会因为交易经过验证而拒绝 cookie。
如果您保持自动重定向,并且两台服务器都生成一个带有链接的页面供您单击,它也应该可以工作,以便您可以验证交易。但是,任何地方都不能有任何自动重定向。
在这种情况下,仅使用用户名和密码登录会更好。
OpenID 仍然很酷,我猜 Opera 只需要一个选项来允许 SO 和您的 OpenID 服务器之间进行无法验证的交易,以便您可以在此处使用“仅接受来自我访问的站点的 cookie”。
有人可以简要解释单点登录的最佳答案吗?我想使用 openid 作为 SSO很好地解释了 OpenID 和 SSO 的不同之处:
单点登录是指在一个地方登录并在其他位置自动对您进行身份验证。OpenID 是关于将身份验证委托给 OpenID 提供者,因此您可以使用一组凭据有效地登录多个站点。
同一篇文章也对原始问题给出了很好的答案:
您可以使用 OpenID 作为 SSO 的身份验证方案,但这是偶然的。
我对 OpenID 很矛盾。一方面,它解决了“身份提供者发现问题”(依赖方站点如何确定将用户发送到何处进行身份验证)。另一方面,对于普通用户来说,URL 非常笨拙。
我认为 OpenID 目前是通往 Web 身份解决方案道路上的有用一站,但肯定不是最终目的地。
专门解决您的 Intranet 问题,OpenID 可能不是正确的答案。正如我上面提到的,OpenID 为您提供了定位身份提供者的能力,代价是在每个依赖方都输入该 URL。如果您要在某个内部身份提供商处对所有用户进行身份验证,并且只接受来自该身份提供商的用户,那么 OpenID 确实不会为您带来太多好处。
我会查看诸如CAS或OpenSSO之类的系统,它们中的任何一个都会将用户重定向到登录页面,而无需输入 URL。我最近写了一篇关于一家公司在短短 4 个月内为 3000 个用户推出了 OpenSSO 到 40 个 Intranet 应用程序的博客,这些应用程序在 IIS 6.0、Apache、JBoss 和 Tomcat 上运行。
我认为 OpenID 过于混乱和笨拙,无法强制任何用户使用,我什至不相信它正在解决一个真正的问题。必须在我使用的每个网站上注册从来没有让我觉得这是一个主要问题。特别是因为它并没有特别解决这个问题;当我将我的 OpenID 链接到 StackOverflow 时,无论如何我都必须填写额外的详细信息。它可能有一个常规的注册过程来处理它所产生的所有差异。
嗯.. 我会喜欢一个简单的登录密码组合(我会通过 Passwordmaker.org 轻而易举地通过)。但是作为开发人员,我可以理解他们不想再次重新发明登录轮......
开放标识:
我输入我的博客网址 => 谷歌登录 => 我在。
这是一个额外的水平..但没关系。
OpenID 当然不能解决这个问题。例如,如果我使用 OpenID 登录 StackOverflow,并不意味着我不需要使用相同的 openID 再次登录另一个网站。-- tj9991
不过,这可能意味着。如果您在 OpenID 站点上的登录被记住(例如,通过 cookie),那么您实际上只需要在每个浏览器会话中登录一次(或每周一次、每月一次……)您访问的所有 OpenID 站点.
浏览器支持和 API 甚至可以取消密码提示和页面重定向。很好的主意!
实际上,在 StackOverflow 的情况下,单独的帐户会为我省去很多麻烦。我决定使用我的 WordPress.com OpenID,因为那是我托管博客的地方,但事实证明 WordPress.com 的 OpenID 服务存在严重问题,而且大多数时候我无法登录 StackOverflow一点也不。当然,我可以使用不同的 OpenID 提供者进行登录,但随后我将在站点上拥有不同的身份。
我想您可能会说 WordPress.com 应该为此负责,但问题仍然存在。通过使用 OpenID,您将依赖另一个站点的服务来运行。第三方网站上的任何问题实际上也会禁用您的网站。
作为替代解决方案,我尝试使用我的 Yahoo OpenID 登录,但随后我得到了一些随机字符串作为用户名,正如 DrPizza 已经指出的那样,无论如何我都必须编辑我的个人详细信息。
OpenID 是一个好主意,但在当前的情况下,我仍然不能依赖它。
至少在 Intranet 场景中,我认为 Active Directory(或类似的)仍然是最好的选择之一。
至少在 Intranet 场景中,我认为 Active Directory(或类似的)仍然是最好的选择之一。
是的,无论如何,Active Directory 都隐藏在 OpenId Server Provider 的幕后。
为了在 Intranet 中开发 SSO 解决方案,有商业选项,例如 Access Manager(前 IChain)+Active Directory,但我不知道除了“自己的 OpenId 服务器”之外是否还有开放的解决方案+“一些很酷的东西尚未开发”+ LDAP。
这不是堆栈溢出的可用性问题,因为无论如何所有用户都是程序员,但我想不出许多其他网站可以摆脱它。
我认为 openID 会随着时间的推移而改进,一旦所有使用它的网站开始实现所有功能(比如自动填充关于我的东西),它就会更有价值。
OpenID 实现需要付出很多努力并被认为是成功的,即使这样,您也可能会受到不良身份提供者(例如 Yahoo)的阻挠。如果您已经解决了用户体验问题,OpenID 可以很好地工作,但是对于大多数用户来说,糟糕的实现是非常困难的。在我看来,OpenID 最大的问题是人们试图用用户意识来解决这个问题。他们最好只提供一个 OpenID 提供者的列表,然后让用户点击他们想要使用的那个。如果提供者不支持规范的 2.0 版,这有时需要了解提供者如何实施 OpenID,但会为最终用户提供更好的整体体验。