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.hu...@citrix.com> wrote: > See inlined. > > > -----Original Message----- > > From: Manikanta Kattamuri [mailto:manikanta.kattam...@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:j...@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.child...@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 > >
