(just catching up on this thread) On Dec 20, 2012, at 6:56 PM, Chip Childers <chip.child...@sungard.com> wrote: > We are already talking about more robust RBAC for operations. I can > only assume that the value in doing that will be better realized by > mapping the roles to users. That actually reinforces the user as > being the primary entity involved in Authz/n. We really need to > consider extending the user role assignment to the LDAP target, > instead of just using it for authentication. The same argument for > having a single directory for authentication can be applied to wanting > to use that data for actual permissions.
+1 > So if it was written as a plugin (which may not be possible today), > what would be the problem with supporting the actual management of > LDAP objects? It seems like a very natural complement to the existing > LDAP authentication plugins, allowing us to support that third use > case. > > I also really believe that we should take a strong look at figuring > out how to tie the groups that an LDAP user is assigned to the roles > that we should be working to support for functional authorization. Completely concur. We're also looking to have hierarchical support across our systems - one reason this shouldn't be within ACS is if an organization's org tree is different than Account/user. What about Account/department/user? Separation and management of privileges is a pretty big deal to us. An analogy, which may help Koushik and others: AWS has some sort of centralized authentication/authorization system for customer accounts - for the purpose of this discussion, let's say it's LDAP. I'm sure they have wonderful LDAP management systems that do nothing but that. But when I login to the AWS dashboard in a company admin account, I'm able to grant/revoke permissions to individual users, and I suspect those permissions/roles are stored within the LDAP database, not AWS specifically. Another potential use case in the future: when ACS is orchestrating storage or another service directly linked with instances and users, there may be a need to grant access to that service via LDAP (Or whatever centralized auth - AD? :) ) as well… John
