Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of Alex.Huang@citrix.com
 designates 66.165.176.63 as permitted sender)
From: Alex Huang <Alex.Huang@citrix.com>
To: "cloudstack-dev@incubator.apache.org"
	<cloudstack-dev@incubator.apache.org>
Date: Tue, 8 Jan 2013 06:50:43 -0800
Subject: RE: [DISCUSS] Cloudstack to manage User objects in LDAP
Thread-Topic: [DISCUSS] Cloudstack to manage User objects in LDAP
Thread-Index: 
 AQDVvP2GD8BatP0ZGBcoUgpWkVPaVwKD007nApdoKpABuLtIHQFq1QBWAju1rX2Z2+Z5gIAAKFuA
Message-ID: 
 <B1DF26ECC0458748AC97CECE2DA98D41012FA385ED3F@SJCPMAILBOX01.citrite.net>
References: <8f24a63bd05f81720db9736015de0f3b@mail.gmail.com>
 <CAKprHVaFi_8FDT60dwSJ4-Z-U5UEvR=_WwpJr8o7sBzPP+EBkA@mail.gmail.com>
 <CA+96GG6LVYsKLMG7Yht6dU=R332iQhOuDYM5rr0GWe3ZDLdV0A@mail.gmail.com>
 <2529883E7B666F4E8F21F85AADA43CA7010C8EB1BDA2@BANPMAILBOX01.citrite.net>
 <CA+96GG4my_iN7_ZtrYTG=y3kuJuvJYgzNoiBmJXiam2C9D+pWA@mail.gmail.com>
 <036CF53F-DF75-4245-8D87-E0349FE3ABEA@stratosec.co>
 <bc528a1b175eeac8a8e396916d58b4eb@mail.gmail.com>
In-Reply-To: <bc528a1b175eeac8a8e396916d58b4eb@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

See inlined.

> -----Original Message-----
> From: Manikanta Kattamuri [mailto:manikanta.kattamuri@sungard.com]
> Sent: Tuesday, January 08, 2013 5:30 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: RE: [DISCUSS] Cloudstack to manage User objects in LDAP
>=20
> Some thoughts on implementation and braindump...
>=20
> (LDAP basically is an example I have taken up, the problem are the same
> for any other products)
>=20
> 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.

>=20
>=20
> 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 oth=
er words, you can't introduce more than one user per account if LDAP manage=
r is being used?

>=20
> 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.
>=20
> Shared LDAP(ACS and other apps):
> With shared LDAP while user mgmt will be similar to exclusive ldap, the C=
S
> roles required for authorization are placed in different table than the
> user table.  This would need to be handled differently.
>=20
> 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 know=
s how to configure default roles for new users and APIs to deal with adding=
 roles to users etc. =20

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 a=
t how that's done and see if what you need is already being provided in tha=
t 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 )
>=20
> We need to figure out up to what level we require LDAP in ACS  ( Just use=
r
> info or even roles).

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

>=20
> I will get the services decoupled as it looks required in anyway.
>=20
> I personally would want to follow option (2) as it will open up other
> areas that can be generalized and avoid sync/manual mgmt.
>=20
> This will decouple the code ( new security products ex spring security ca=
n
> be brought in etc... ).
>=20
> Manikanta.
>=20
> -----Original Message-----
> From: John Kinsella [mailto:jlk@stratosec.co]
> Sent: Saturday, December 22, 2012 2:07 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [DISCUSS] Cloudstack to manage User objects in LDAP
>=20
> (just catching up on this thread)
>=20
> On Dec 20, 2012, at 6:56 PM, Chip Childers <chip.childers@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.
>=20
> +1
>=20
> > 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.
>=20
> Completely concur.
>=20
> 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.
>=20
> An analogy, which may help Koushik and others:
>=20
> 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 admi=
n
> 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.
>=20
> Another potential use case in the future: when ACS is orchestrating
> storage or another service directly linked with instances and users, ther=
e
> may be a need to grant access to that service via LDAP (Or whatever
> centralized auth - AD? :) ) as well.
>=20
> John