cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Huang <>
Subject RE: [DISCUSS] Cloudstack to manage User objects in LDAP
Date Tue, 08 Jan 2013 14:50:43 GMT
See inlined.

> -----Original Message-----
> From: Manikanta Kattamuri []
> Sent: Tuesday, January 08, 2013 5:30 AM
> To:
> Subject: RE: [DISCUSS] Cloudstack to manage User objects in LDAP
> Some thoughts on implementation and braindump...
> (LDAP basically is an example I have taken up, the problem are the same
> for any other products)
> Here when we are talking about LDAP are we seeing that to be an LDAP
> exclusively for ACS or any pre-existing LDAP where user creation can be
> done from other sources other than ACS?

I'm not sure I see a case for LDAP exclusively for ACS.

> Presently in code the UserManagment operations are coupled with Account
> and the acl's are given from AccountManager.
> If we need to introduce any type of usermgmt other than what cs presently
> has, then we need to de couple the account mgmt and user mgmt as
> two different services as first step. The UserService will be responsible
> for user CRUD operation based on the parameters (cs db or LDAP presently).

Why not just see user and account as one and the same in LDAP case.  In other words, you can't
introduce more than one user per account if LDAP manager is being used?

> ACS Exclusive LDAP:
> Make User Mgmt a plugin and implement LDAP adapter for it along with the
> current CS DB(default). This will be similar to user-authenticators
> plugin.
> Shared LDAP(ACS and other apps):
> With shared LDAP while user mgmt will be similar to exclusive ldap, the CS
> roles required for authorization are placed in different table than the
> user table.  This would need to be handled differently.
> 1) If a user is created by a non ACS app:
> 	- Roles will not be present in ACS and the user ops will Fail.
> 	Options:
> 		Where will we get the role info from? If it is present in
> LDAP should we sync it to CS?
> 	Changes to code:
> 		Implementation of UserServices and a sync script to map
> and sync user roles frequently

This is where I see a plugin mechanism.  The plugin provides APIs that knows how to configure
default roles for new users and APIs to deal with adding roles to users etc.  

At the end, ACS shouldn't care of roles as long as there is someone to tell ACS that operations
can be performed and objects can be accessed.  That's what the api refactoring work is pushing
ACS toward.  You can take a look at how that's done and see if what you need is already being
provided in that work.

> 2) If we move both UserInfo and Roles to LDAP
> 	- Will it be good practice to keep specific app ( here ACS) based
> info(role) in shared LDAP?
> 		This will require the other user creation points to know
> of ACS role parameter...(maybe wrong)
> 	Changes
> 		Changes to User mgmt. and even to ACL implementation (
> which is also part of accountmanager )
> We need to figure out up to what level we require LDAP in ACS  ( Just user
> info or even roles).

The API refactoring code pushed out the roles mechanism into another adapter you can implement.
 Take a look there.

> I will get the services decoupled as it looks required in anyway.
> I personally would want to follow option (2) as it will open up other
> areas that can be generalized and avoid sync/manual mgmt.
> This will decouple the code ( new security products ex spring security can
> be brought in etc... ).
> Manikanta.
> -----Original Message-----
> From: John Kinsella []
> Sent: Saturday, December 22, 2012 2:07 AM
> To:
> Subject: Re: [DISCUSS] Cloudstack to manage User objects in LDAP
> (just catching up on this thread)
> On Dec 20, 2012, at 6:56 PM, Chip Childers <>
> 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

View raw message