Thanks for the reply... follow up discussion below: On Thu, Dec 20, 2012 at 5:20 AM, Koushik Das <koushik....@citrix.com> wrote: > I don't think CS should allow user management for external systems. Currently > CS supports creating accounts and each account has 1 or more users. > These users should be considered as one of the ways of authenticating to CS > and on successful authentication the associated account is used to perform > all operations.
Yes, accounts are the current primary object used for authorization rights (specifically for data auth). Perhaps some history would help me understand this though. I'd love to hear more about the thinking around the account / user / domain model, because it seems like it started with accounts, and then domains and users were added at a later phase in response to customer requirements. It's actually a bit confusing as it's described right now. Are you able to help with some of the thinking / history around this (I'm sure the whole community would benefit by knowing a bit more)? > CS should only deal with accounts. But it doesn't work that way already, right? Users are the authenticated entity, which (excluding the domain and root admins) are grouped under an account. > Now authentication method can be the native user/password that CS supports or > by other means like any LDAP or Google/Facebook IDs. > There should be some mechanism to map external users to CS accounts. I have no real disagreement here, but it's not mutually exclusive to also allowing CS to have a plugin that manages LDAP objects. > This can be done by some CS component but I personally feel this should also > be outside of CS. Comments? It entirely depends on your use case, right? Today, CS solves two primary scenarios: no external auth source is required (for whatever reason), and an existing directory server exists and can be used as the target for authentication only. What isn't solved is the one that we're talking about in this thread: The CS API is the primary mechanism for managing the entities within a cloud service, including the accounts and users. Since this isn't solved in CS today, a deployment has to pick one of the two functional options. With the stand-alone scenario, the accounts / users are stranded as CS only objects. With the LDAP authn plugin, the user management functions of cloudstack have limited value. Not knowing the full history / thinking, I'll offer some opinion (that I reserve the right to change based on what I'm able to learn in this thread!): 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. 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. Does my line of thinking make sense? -chip