Mailing-List: contact cloudstack-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
From: Manikanta Kattamuri <manikanta.kattamuri@sungard.com>
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>
In-Reply-To: <036CF53F-DF75-4245-8D87-E0349FE3ABEA@stratosec.co>
MIME-Version: 1.0
Thread-Index: 
 AQDVvP2GD8BatP0ZGBcoUgpWkVPaVwKD007nApdoKpABuLtIHQFq1QBWAju1rX2Z2+Z5gA==
Date: Tue, 8 Jan 2013 18:59:40 +0530
Message-ID: <bc528a1b175eeac8a8e396916d58b4eb@mail.gmail.com>
Subject: RE: [DISCUSS] Cloudstack to manage User objects in LDAP
To: cloudstack-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1

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?


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

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

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

(just catching up on this thread)

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.

+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