cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chip Childers <chip.child...@sungard.com>
Subject Re: [DISCUSS] Cloudstack to manage User objects in LDAP
Date Fri, 21 Dec 2012 02:56:51 GMT
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)?

> 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

Mime
View raw message