我应该推出自己的 OpenID 提供程序，还是有更好的方法？答案

【问题标题】：Should I roll my own OpenID provider, or is there a better way?我应该推出自己的 OpenID 提供程序，还是有更好的方法？
【发布时间】：2011-04-17 06:56:10
【问题描述】：

我正在为客户开发一个解决方案，该客户正在处理一个相当典型的问题：他们有许多系统在生产中，每个系统都有自己的用户和密码，导致每个用户必须记住三个或四个不同（或不）的登录名和密码，每个系统允许使用一个。此外，每个应用程序都有自己的身份验证级别（也就是说，如果您是其中的超级用户，那并不意味着您是所有应用程序的超级用户）。

到目前为止，我最好的想法是安装 OpenID 提供程序，并使用 AX（属性交换）扩展提供访问级别。不过，这很复杂，主要是因为我找不到具有上述扩展名的 OpenID 提供程序的体面实现 - 对于我在档案中读到的内容，甚至 Google 和朋友都没有做到这一点......

补充几点：

使用 AX 的好处是可以从中心点管理访问 - 如果应用程序请求一个字段，但 OpenID 提供程序没有返回任何内容，那么您就不能登录。这样，高级用户（也就是老板，或者更准确地说是他的秘书）可以从一个网页授予/撤销所有系统的权限。
我很想使用，比如说，myOpenId，但如果您曾经试图说服经理与外国网站共享用户、密码和权限的完整列表，那么您就会知道我得到的答案。本地服务器虽然可能不如使用 Google 安全，但自相矛盾的是首选解决方案。
LDAP 不受欢迎，主要是因为担心您可以通过适当的查询获得完整的用户列表（可能不是普通用户，但开发人员可以获得它）。不过，我不是 LDAP 方面的专家，所以如果您认为这是一个有效的选择，我会倾听。
是的，我知道 sreg 更容易使用，但是没有 "application_access" 属性，并且捎带另一个字段，例如 "email" em>，听起来有点难看。

那么，你认为我在这里做的事情是对的吗？我缺少更好的解决方案吗？如果是，您是否碰巧知道一个好的 OpenID 提供程序（带有 AX 扩展！）我可以安装？

【问题讨论】：

标签： openid single-sign-on

【解决方案1】：

根据您所说的要求（管理员能够撤销通过属性等传递的权限），听起来运行您自己的提供程序是最好的方法，因为公共提供程序不太可能提供您想要的灵活性。 DotNetOpenAuth 完全支持 AX 作为消费者和提供者，因此它是一个很好的起点——您还可以在其上构建所有管理员级存储和属性通信自定义。它仍然不是一个交钥匙解决方案（即，需要编码以从它们存储的任何位置“获取”AX 值），但它比尝试从头开始要好得多。大量优秀的示例和社区，主要作者活跃于 StackOverflow。

【讨论】：