incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Koushik Das <koushik....@citrix.com>
Subject RE: [DISCUSS] Cloudstack to manage User objects in LDAP
Date Fri, 21 Dec 2012 18:07:40 GMT
Comments inline

Thanks,
Koushik

> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Friday, December 21, 2012 8:27 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [DISCUSS] Cloudstack to manage User objects in LDAP
> 
> Thanks for the reply...  follow up discussion below:
> 
> On Thu, Dec 20, 2012 at 5:20 AM, Koushik Das <koushik.das@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)?

I also don't know about the history. Looking at the code I felt that users were introduced
just to provide some means of basic authentication. If someone who developed it can provide
some insights that would help.

> 
> > 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.

That's right.
Users are used only for authentication purpose and then based on the account the authorization
happens. So once the account is established the user information is no longer required. Now
the way I see it is that CS provided a means to do authentication as there was no other means
at that time in terms of mapping the user to 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.

LDAP plugin is fine but then do you expect CS to provide plugins to do user management for
various external systems. I believe that there are already well defined tools for managing
LDAP and other such systems.

> 
> > 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.
> 

So my point is should we work towards adding support for external authentication source and
treat LDAP as one such option?

> 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.

But should CS bother about the mapping? As long as correct roles are provided things should
work fine.

>  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?

I get your point but we need to decide how to take it forward in the best possible way. Think
of a scenario where some organization wants to use CS. They already have a setup for user
accounts to access various resources within the organization. Currently if they want to reuse
the same for accessing CS there is no option other than replicating the users. The same can
apply to public clouds as well. I feel that the scenario of reusing existing user accounts
is better compared to creating them specifically for CS.

I view the plugin for managing LDAP objects more of a means to bridge the current gap as there
is an LDAP authenticator and there should be a way to create users in it. If we go ahead with
this then someone in future may come up with say XYZ authenticator and then will have to write
some user management plugin corresponding to that. This approach fits well if we are ok with
creating users always rather than reuse.

> 
> -chip

Mime
View raw message