我们将如何实现具有以下目标的系统：

• 为当前与第三方供应商的应用紧密集成的成千上万现有用户管理身份验证和授权(我们希望将这些用户淘汰到我们管理的东西中，并使我们的应用与之对抗，以及我们的第三方供应商与之对抗)。
• 管理链接到这些用户的个人资料信息
• 必须能够在几乎任何平台(Windows，* nix，PHP，ASP / C＃，Python / Django等)上从任意数量的Web应用程序进行访问。

这里是一些示例实现：

• LDAP / AD服务器可以管理所有内容。对所有配置文件数据使用自定义架构。一切都可以针对LDAP / AD进行身份验证，我们可以在自定义架构中存储各种ACL和配置文件数据。
• 仅将LDAP / AD用于身份验证，使用某种传统数据库(MSSQL / PostgreSQL / MySQL)或者基于文档的DB(CouchDB，SimpleDB等)将LDAP用户绑定到最强大的配置文件/授权服务器。使用LDAP进行授权，然后访问数据库以获取更多高级内容。
• 使用传统数据库(关系数据库或者文档数据库)进行所有操作。

这三个最好吗？是否还有其他符合上述目标且更易于实施的解决方案？

**我应该补充一点，几乎所有将要针对用户数据库进行身份验证的应用程序都将在我们的控制之下。仅有的几个局外人将是我们正在从中删除当前用户数据库的应用程序，也许还有其他1或者2个。没有什么比需要openID服务器更广泛的了。

同样重要的是要知道，这些用户中有许多已经拥有这些帐户5至8年，并且知道他们的登录名和密码，等等。

解决方案

回答

我们始终可以实现自己的OpenID服务器。已经有一个用于OpenID的Python库，因此应该相当容易。

当然，我们不需要接受应用程序中其他服务器授权的登录。接受仅由我们自己的服务器授权的凭据。

编辑：我发现在Django中的OpenID服务器协议的实现。

Edit2：为用户实现OpenID有一个明显的优势。他们将能够使用他们的登录名登录到StackOverflow :-)

回答

如果我们具有现有的ActiveDirectory基础结构，那将是最佳选择。对于已经设置了Windows服务器进行身份验证的公司，这将特别有利。如果是这种情况，我倾向于我们在"示例实现"中的第一个要点。

否则，这将是AD和开源LDAP选项之间的折腾。

滚动自己的身份验证架构进行单点登录可能不可行(特别是考虑到我们可能需要进行大量的文档编制和集成工作)，并且显然不要将身份验证服务器与运行于其上的任何应用程序捆绑系统(因为我们希望它能够独立于此类应用程序的负载)。

祝你好运！

回答

身份验证和授权/配置文件之间是有区别的，因此不必将两者都强制集成到一个工具中。使用LDAP进行身份验证和使用DB进行授权的第二种解决方案似乎更加健壮，因为LDAP数据由用户控制，而DB将由管理员控制。后者可能会随着时间的流逝而在结构和复杂性上发生变化，但是身份验证仅是身份验证。这些功能的分离将更易于管理。

回答

仅将LDAP / AD用于身份验证，使用某种传统数据库(MSSQL / PostgreSQL / MySQL)或者基于文档的DB(CouchDB，SimpleDB等)将LDAP用户绑定到最强大的配置文件/授权服务器。使用LDAP进行授权，然后访问数据库以获取更多高级内容。

回答

我们有大约10万个用户的不同站点，并且它们都使用普通数据库。如果大多数应用程序都可以访问数据库，则可以使用此解决方案。