incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manikanta Kattamuri <manikanta.kattam...@sungard.com>
Subject Re: [DISCUSS] Cloudstack to manage User objects in LDAP
Date Fri, 25 Jan 2013 15:26:28 GMT
i came up with this design
https://cwiki.apache.org/confluence/display/CLOUDSTACK/ACS+integration+with+User+
LDAP+base

can you review it..

Mani.


On Tue, Jan 8, 2013 at 8:20 PM, Alex Huang <Alex.Huang@citrix.com> wrote:

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message