我只是在寻找不同的意见。
我们是否认为OpenID是好的"单一登录"解决方案？

对于普通用户而言，它的工作方式似乎有些混乱，并且可能存在与"将所有鸡蛋放入同一篮子中"相关的问题。

无论如何，有没有人试图在具有许多不同应用程序(Wordpress，Elgg，Media Wiki等)的Intranet上下文中实现自己的OpenId解决方案？

我认为这可能是解决"数字身份"问题的好方法，但是我不知道它是否可以解决"一次登录并访问Intranet"问题。

意见？

解决方案

回答

我认为OpenID过于混乱和笨拙，无法强加给任何用户，而且我什至不认为它正在解决一个真实的问题。不必在我使用的每个站点上进行注册，从未使我成为一个重大问题。特别是因为它不能特别解决这个问题。当我将OpenID链接到StackOverflow时，无论如何我都必须填写额外的详细信息。它可能会对所有区别进行定期注册。

回答

好吧..我很喜欢一个简单的login-pwd组合(我可以通过Passwordmaker.org轻轻松松)。
但是作为开发人员，我可以理解，他们不想再次发明登录盘...

OpenID：

我输入我的博客网址=> Google登录=>我正在登录。

这是一个额外的水平..但是还可以。

回答

实际上，在使用StackOverflow的情况下，单独的帐户可以为我省去很多麻烦。我决定使用我的WordPress.com OpenID，因为那是我托管博客的地方，但是事实证明WordPress.com的OpenID服务存在严重问题，并且大多数时候我无法登录到StackOverflow完全没有。当然，我可以使用其他OpenID提供程序进行登录，但随后在该站点上我将具有其他身份。

我猜你可能会说WordPress.com对此负责，但是问题仍然存在。通过使用OpenID，我们将依赖于其他站点的服务来起作用。第三方网站上的任何问题实际上也会禁用网站。

作为一种替代解决方案，我尝试使用Yahoo OpenID登录，但是随后我得到了一些随机字符串作为用户名，并且正如DrPizza所指出的，无论如何我都必须编辑我的个人详细信息。

OpenID是一个不错的主意，但在当前的情况下，它仍然不是我要依靠的东西。

回答

我花了一些时间来了解OpenID(这么多提供商！)，但我真的很喜欢这个概念。将其与Gravatar捆绑在一起，重写个人资料可能会轻松得多，也许只有一两个领域。

唯一的问题是我们必须信任OpenID提供程序，但这并不是我真正要解决的问题，更像是常识。

编辑：与OpenID提供程序有问题的人应该考虑设置一个新的。我的提供商是myopenid.com，我没有遇到任何问题。我们可以设置多个角色(例如个人资料)，所以我有一个用于博客评论，一个用于这样的技术站点。

至于拥有一个新的SO配置文件，Jeff谈到了将来可以更改OpenID而又不会丢失配置文件统计信息的事情。

回答

至少在Intranet方案中，我认为Active Directory(或者类似目录)仍然是最佳选择之一。

回答

此外，SSO(如我们所述)通常意味着我只需登录一次(大概是登录到我的工作站)，然后从那里登录，我不需要在任何地方登录。

OpenID当然不能解决这个问题。例如，如果我使用OpenID登录到StackOverflow，这并不意味着我不需要使用相同的openID重新登录到另一个网站。

回答

我必须说，我绝对同意有关"普通"互联网用户过于困难的说法。我认为，即使最初的提议是在2005年，OpenID仍然可以被认为是"新的"。更多的高流量站点将它当作创建帐户的一种选择，而不是要求用户提供OpenID。

我认为，只要在创建普通用户名/密码帐户的同时提供OpenID，一般的互联网用户自然就会开始尝试并最终坚持使用OpenID。

身份验证问题与OpenID一样适用于在任何网站上进行注册。我们使用密码信任该网站(假设我们不使用密码存储程序)，因此不应将其用于OpenID。

除此之外，对于Web开发人员而言，帐户创建的标准化绝对是无价之宝。我只希望不必担心正常的创建过程，而只需放入OpenID库并将其引用到数据库即可。

回答

At least in the intranet scenario, I
  think Active Directory (or similar) is
  still one of the best options.

是的，无论如何，Active Directory在OpenId Server Provider的幕后。

为了在Intranet中开发SSO解决方案，可以使用商业选项，例如Access Manager(以前的IChain)+ Active Directory，但我不知道除了" Own OpenId Server" +"还有什么尚待开发的解决方案"之外，是否还有开放的解决方案。 LDAP。

回答

OpenID of course doesn't solve that problem. For example, if I use OpenID to sign in to StackOverflow, it doesn't mean I don't need to sign in to another website again using the same openID. -- tj9991

但这可能意味着。如果记住我们在OpenID网站上的登录(例如，通过cookie)，则实际上我们只需为访问的所有OpenID网站每个浏览器会话登录一次(或者每周一次，每月一次...) 。

浏览器支持和API甚至可以消除密码提示和页面重定向。好想法！

回答

由于所有用户都是程序员，所以这不是堆栈溢出的可用性问题，但是我想不出其他很多可以摆脱它的站点。

我认为openID会随着时间的推移而改善，并且一旦所有使用它的站点开始实现所有功能(例如自动填写关于我的东西)，它就会变得更有价值。

回答

OpenID有一个小问题。

使用OpenID无缝登录需要域之间的自动(未经验证)重定向。

这使得OpenID服务器成为第三方。如果关闭第三方Cookie，并且浏览器严格遵循RFC2965的3.3.6中的"不可验证的交易"规则，则可能导致拒绝OpenID服务器的Cookie。

Opera就是一个例子。如果我们关闭了第三方Cookie(通过将全局设置为"仅接受我访问的站点的Cookie")，则无法使用OpenID登录，因为我们要自动提交的服务器脚本(无需进行交互即可批准)会重定向将我们带到OpenID服务器，而OpenID服务器也会这样做，以使我们重新回到原来的位置。

但是，在Firefox，IE和Safari中，由于它们在多种情况下都违反了RFC2965，它们对第三方Cookie的相应阻止使我们很幸运。

在这种情况下，必须使用OpenID会对更合规的客户端造成损害。

解决方法是，在Opera中，除了接受所有炊具外，还可以转到工具->首选项->高级->网络，然后关闭自动重定向。然后，我们将能够验证并单击我们重定向到的每个链接，并且由于验证了交易，因此不会拒绝cookie。

如果我们将"自动重定向"保持在打开状态，并且两台服务器都生成一个带有链接的页面供我们单击，以便我们可以验证事务，那么它也应该起作用。但是，任何地方都无法进行任何自动重定向。

在这种情况下，仅使用用户名和密码登录即可处理第一方Cookie，这样会更好。

OpenID仍然很酷，我想Opera仅需要一个选项来允许SO和OpenID服务器之间的不可验证的交易，以便我们可以在此处使用"仅接受来自我访问的站点的cookie"。

回答

我对OpenID非常矛盾。一方面，它解决了"身份提供者发现问题"(依赖方站点如何确定将用户发送到哪里进行身份验证)。另一方面，URL对于普通用户而言非常笨拙。

我认为OpenID目前是通往Web身份解决方案之路上的一个有用的站，但肯定不是最终的目的地。

专门解决Intranet问题，OpenID可能不是正确的答案。如前所述，OpenID使我们能够找到身份提供者，而要在每个依赖方键入该URL。如果我们要在某个内部身份提供者处对所有用户进行身份验证，并且仅接受该身份提供者中的用户，则OpenID确实不会给我们带来太多好处。

我将看一下诸如CAS或者OpenSSO之类的系统，这两种系统都可以将用户重定向到登录页面，而无需输入URL。我最近在博客中写道，一家公司在短短4个月内就将OpenSSO部署到了40个Intranet应用程序中，供3000个用户使用，这些应用程序都在IIS 6.0，Apache，JBoss和Tomcat上运行。

回答

OpenID的实现需要大量的努力并且被认为是成功的，即使那样，我们也可能会受到不良身份提供者(例如Yahoo)的挫败。如果我们已经解决了用户体验问题，则OpenID可以很好地工作，但是对于大多数用户来说，糟糕的实现是极其困难的。在我看来，OpenID的最大问题是人们试图以用户意识解决问题。他们最好只提供一份OpenID提供程序列表，并让用户单击他们想要使用的提供程序。如果提供商不支持规范的2.0版，则有时需要了解提供商如何实现OpenID，但要为最终用户提供更好的总体体验。