我们有一套专门用于我们的分销商和合作伙伴的各种networking应用程序。 有些是标准的软件包，如Alfresco，其他的是定制的网站。
全部受到login保护。 我们希望我们的用户为所有这些应用程序提供单一login。 因此，我们正在考虑设置OpenLDAP服务器来提供所有这些应用程序身份validation请求。
我们应该在哪里存储应用特定的用户权限？ 比如，谁可以使用app1，谁可以使用app2和哪个angular色？ 是否应将其存储在LDAP或应用程序数据库中？
换句话说，我们是否应该只保留LDAP来进行基本的身份/身份validation查找，并跟踪哪些人可以在每个应用程序的数据库中使用哪个应用程序？ 或者我们可以将所有这些信息存储在LDAP中（这是有道理的）？
TIA为了摆脱一些光线。
对于更细化的权限，比如“在首页上有编辑权限”，我会在应用程序级别保留这些权限，但是为了简单起见，为了简单，“具有读/写访问权限”级别权限，我将在ldap中实现该权限。
需要注意的一个问题是用户可以在某些平台上关联的组的最大数量，因此我将为应用程序组成员资格属性使用自定义名称，这样您甚至不需要考虑这一点。
使用LDAP来validation用户和应用程序数据库以确定该用户是否有权限。 你可以单独使用LDAP，但分离有好处，实际上可以简化pipe理。 这与pipe理一个区域中的用户帐户和另一个区域中的文件/文件夹权限没有区别。
把它全部放在LDAP中，就是这样。
有一件事要指出，虽然使用Active Directory可能很诱人，因为它的LDAPfunction可能不是最好的select。 与许多微软产品一样，AD如果坚持使用微软的产品，就会变得越来越好用，而当你不得不开始混淆环境时，微软就会变得越来越糟糕。 但是，微软的信誉在过去几年中在这方面有了很大的提高。 您可能遇到的最大挑战是如果您需要对AD进行架构更改以支持您的应用程序。 模式更改不一定得到Microsoft的支持，并有可能使将来的AD升级复杂化。 尽pipe平心而论，对于任何LDAP服务器都是如此，但是我认为对LDAP服务器进行架构更改更为常见。 如果您有现有的AD服务器，则可以在LDAP服务器（如Red Hat Directory Server）和AD服务器之间实现同步操作。 这可以允许您同步用户名，但保留每个服务器域中的系统特定信息。 是的，这确实给pipe理增加了一些复杂性，但总的来说，这是最灵活的方法之一。
最后，集中式身份validation由此来pipe理：
"Where do you want your pain?"