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

Question

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

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

加分：

• 使用AX的好处是可以从中心点管理访问 - 如果应用程序要求输入字段，但OpenID提供程序不返回任何内容，则不允许您登录。这样，高级用户（也就是老板，或者更确切地说是他的秘书）可以从一个网页授予/撤销所有系统的权限。
• 我很乐意使用 myOpenId ，但如果您曾试图说服经理与外国网站分享用户，密码和权限的完整列表，那么您就知道了我得到的答案。本地服务器虽然可能不如使用谷歌那么安全，但矛盾的是它是首选的解决方案。
• LDAP不赞成，主要是因为担心你可以获得具有适当查询的完整用户列表（可能不是常规用户，但开发人员可以得到它）。不过，我不是LDAP的专家，所以如果你认为这是一个有效的选择，我正在听。
• 是的，我知道 sreg 更容易使用，但没有“application_access”属性，并且捎带另一个字段，例如“email”，听起来有点难看。

那么，你认为我在这里做对了吗？我错过了更好的解决方案吗？如果是的话，你碰巧知道一个好的OpenID提供商（使用AX扩展！）我可以安装吗？

Answer 1

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