You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Manikanta Kattamuri <ma...@sungard.com> on 2012/12/19 06:59:41 UTC
[DISCUSS] Cloudstack to manage User objects in LDAP
Hi,
We'd like to be able to have CloudStack manage the user objects from LDAP.
The reason would, be we have a set of other service offerings for the users
of cloudstack service.
Are there any others facing this type of scenarios and any solutions or
on-going development to resolve this.
Inputs and thoughts are very much welcome.
Thanks & Regards,
Manikanta.
Re: [DISCUSS] Cloudstack to manage User objects in LDAP
Posted by Chip Childers <ch...@sungard.com>.
On Wed, Dec 19, 2012 at 12:59 AM, Manikanta Kattamuri
<ma...@sungard.com> wrote:
> Hi,
>
>
>
> We'd like to be able to have CloudStack manage the user objects from LDAP.
>
> The reason would, be we have a set of other service offerings for the users
> of cloudstack service.
>
>
>
> Are there any others facing this type of scenarios and any solutions or
> on-going development to resolve this.
>
>
>
> Inputs and thoughts are very much welcome.
>
>
>
> Thanks & Regards,
>
> Manikanta.
Mani,
Why don't you take this a bit further, and look at what it will take
to make this (1) an optional plugin and (2) what the plugin would need
to perform? If it's possible to do this, a concrete proposal for both
items to this list would be the next step (and allow for specific
discussions around how / if etc...)
-chip
Re: [DISCUSS] Cloudstack to manage User objects in LDAP
Posted by Chip Childers <ch...@sungard.com>.
On Fri, Jan 25, 2013 at 10:26 AM, Manikanta Kattamuri
<ma...@sungard.com> wrote:
> i came up with this design
> https://cwiki.apache.org/confluence/display/CLOUDSTACK/ACS+integration+with+User+
> LDAP+base
>
> can you review it..
>
> Mani.
Mani - This is more of a requirement page, than a design, but it's the
right first step. IMO, this captured the requirements discussed in
this thread well.
CC'ing Alex and Chiradeep, because I'd love their thoughts. Others too!
Re: [DISCUSS] Cloudstack to manage User objects in LDAP
Posted by Manikanta Kattamuri <ma...@sungard.com>.
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 <Al...@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 <ch...@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
>
>
RE: [DISCUSS] Cloudstack to manage User objects in LDAP
Posted by Alex Huang <Al...@citrix.com>.
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 <ch...@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
RE: [DISCUSS] Cloudstack to manage User objects in LDAP
Posted by Manikanta Kattamuri <ma...@sungard.com>.
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 <ch...@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
Re: [DISCUSS] Cloudstack to manage User objects in LDAP
Posted by John Kinsella <jl...@stratosec.co>.
(just catching up on this thread)
On Dec 20, 2012, at 6:56 PM, Chip Childers <ch...@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
Re: [DISCUSS] Cloudstack to manage User objects in LDAP
Posted by Chip Childers <ch...@sungard.com>.
On Thu, Dec 20, 2012 at 9:56 PM, Chip Childers
<ch...@sungard.com> wrote:
> What isn't solved is the one that
> we're talking about in this thread: The CS API is the primary
> mechanism for managing the entities within a cloud service, including
> the accounts and users.
Correction to the above:
What isn't solved is the one that we're talking about in this thread:
The CS API is the primary mechanism for managing the entities within a
cloud service, including the accounts and users, but the provider
wants to be able to use that user store for non-CS resources.
RE: [DISCUSS] Cloudstack to manage User objects in LDAP
Posted by Koushik Das <ko...@citrix.com>.
Comments inline
Thanks,
Koushik
> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Friday, December 21, 2012 8:27 AM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [DISCUSS] Cloudstack to manage User objects in LDAP
>
> Thanks for the reply... follow up discussion below:
>
> On Thu, Dec 20, 2012 at 5:20 AM, Koushik Das <ko...@citrix.com>
> wrote:
> > I don't think CS should allow user management for external systems.
> Currently CS supports creating accounts and each account has 1 or more
> users.
> > These users should be considered as one of the ways of authenticating to
> CS and on successful authentication the associated account is used to
> perform all operations.
>
> Yes, accounts are the current primary object used for authorization rights
> (specifically for data auth). Perhaps some history would help me understand
> this though. I'd love to hear more about the thinking around the account /
> user / domain model, because it seems like it started with accounts, and then
> domains and users were added at a later phase in response to customer
> requirements. It's actually a bit confusing as it's described right now. Are you
> able to help with some of the thinking / history around this (I'm sure the
> whole community would benefit by knowing a bit more)?
I also don't know about the history. Looking at the code I felt that users were introduced just to provide some means of basic authentication. If someone who developed it can provide some insights that would help.
>
> > CS should only deal with accounts.
>
> But it doesn't work that way already, right? Users are the authenticated
> entity, which (excluding the domain and root admins) are grouped under an
> account.
That's right.
Users are used only for authentication purpose and then based on the account the authorization happens. So once the account is established the user information is no longer required. Now the way I see it is that CS provided a means to do authentication as there was no other means at that time in terms of mapping the user to account.
>
> > Now authentication method can be the native user/password that CS
> supports or by other means like any LDAP or Google/Facebook IDs.
> > There should be some mechanism to map external users to CS accounts.
>
> I have no real disagreement here, but it's not mutually exclusive to also
> allowing CS to have a plugin that manages LDAP objects.
LDAP plugin is fine but then do you expect CS to provide plugins to do user management for various external systems. I believe that there are already well defined tools for managing LDAP and other such systems.
>
> > This can be done by some CS component but I personally feel this should
> also be outside of CS. Comments?
>
> It entirely depends on your use case, right? Today, CS solves two primary
> scenarios: no external auth source is required (for whatever reason), and an
> existing directory server exists and can be used as the target for
> authentication only. What isn't solved is the one that we're talking about in
> this thread: The CS API is the primary mechanism for managing the entities
> within a cloud service, including the accounts and users.
>
So my point is should we work towards adding support for external authentication source and treat LDAP as one such option?
> Since this isn't solved in CS today, a deployment has to pick one of the two
> functional options. With the stand-alone scenario, the accounts / users are
> stranded as CS only objects. With the LDAP authn plugin, the user
> management functions of cloudstack have limited value.
>
> Not knowing the full history / thinking, I'll offer some opinion (that I reserve
> the right to change based on what I'm able to learn in this
> thread!):
>
> 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.
But should CS bother about the mapping? As long as correct roles are provided things should work fine.
> 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.
>
>
> 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.
>
> Does my line of thinking make sense?
I get your point but we need to decide how to take it forward in the best possible way. Think of a scenario where some organization wants to use CS. They already have a setup for user accounts to access various resources within the organization. Currently if they want to reuse the same for accessing CS there is no option other than replicating the users. The same can apply to public clouds as well. I feel that the scenario of reusing existing user accounts is better compared to creating them specifically for CS.
I view the plugin for managing LDAP objects more of a means to bridge the current gap as there is an LDAP authenticator and there should be a way to create users in it. If we go ahead with this then someone in future may come up with say XYZ authenticator and then will have to write some user management plugin corresponding to that. This approach fits well if we are ok with creating users always rather than reuse.
>
> -chip
Re: [DISCUSS] Cloudstack to manage User objects in LDAP
Posted by Chip Childers <ch...@sungard.com>.
Thanks for the reply... follow up discussion below:
On Thu, Dec 20, 2012 at 5:20 AM, Koushik Das <ko...@citrix.com> wrote:
> I don't think CS should allow user management for external systems. Currently CS supports creating accounts and each account has 1 or more users.
> These users should be considered as one of the ways of authenticating to CS and on successful authentication the associated account is used to perform all operations.
Yes, accounts are the current primary object used for authorization
rights (specifically for data auth). Perhaps some history would help
me understand this though. I'd love to hear more about the thinking
around the account / user / domain model, because it seems like it
started with accounts, and then domains and users were added at a
later phase in response to customer requirements. It's actually a bit
confusing as it's described right now. Are you able to help with some
of the thinking / history around this (I'm sure the whole community
would benefit by knowing a bit more)?
> CS should only deal with accounts.
But it doesn't work that way already, right? Users are the
authenticated entity, which (excluding the domain and root admins) are
grouped under an account.
> Now authentication method can be the native user/password that CS supports or by other means like any LDAP or Google/Facebook IDs.
> There should be some mechanism to map external users to CS accounts.
I have no real disagreement here, but it's not mutually exclusive to
also allowing CS to have a plugin that manages LDAP objects.
> This can be done by some CS component but I personally feel this should also be outside of CS. Comments?
It entirely depends on your use case, right? Today, CS solves two
primary scenarios: no external auth source is required (for whatever
reason), and an existing directory server exists and can be used as
the target for authentication only. What isn't solved is the one that
we're talking about in this thread: The CS API is the primary
mechanism for managing the entities within a cloud service, including
the accounts and users.
Since this isn't solved in CS today, a deployment has to pick one of
the two functional options. With the stand-alone scenario, the
accounts / users are stranded as CS only objects. With the LDAP authn
plugin, the user management functions of cloudstack have limited
value.
Not knowing the full history / thinking, I'll offer some opinion (that
I reserve the right to change based on what I'm able to learn in this
thread!):
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.
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.
Does my line of thinking make sense?
-chip
RE: [DISCUSS] Cloudstack to manage User objects in LDAP
Posted by Koushik Das <ko...@citrix.com>.
See inline
Thanks,
Koushik
> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Wednesday, December 19, 2012 10:18 PM
> To: cloudstack-dev@incubator.apache.org
> Subject: Re: [DISCUSS] Cloudstack to manage User objects in LDAP
>
> On Wed, Dec 19, 2012 at 11:44 AM, David Nalley <da...@gnsa.us> wrote:
> > On Wed, Dec 19, 2012 at 12:59 AM, Manikanta Kattamuri
> > <ma...@sungard.com> wrote:
> >> Hi,
> >>
> >>
> >>
> >> We'd like to be able to have CloudStack manage the user objects from
> LDAP.
> >>
> >> The reason would, be we have a set of other service offerings for the
> >> users of cloudstack service.
> >>
> >>
> >>
> >> Are there any others facing this type of scenarios and any solutions
> >> or on-going development to resolve this.
> >>
> >>
> >>
> >> Inputs and thoughts are very much welcome.
> >
> >
> > Define 'manage'?
> >
>
> Create, update, delete OU's and users via LDAP calls.
I don't think CS should allow user management for external systems. Currently CS supports creating accounts and each account has 1 or more users. These users should be considered as one of the ways of authenticating to CS and on successful authentication the associated account is used to perform all operations. CS should only deal with accounts. Now authentication method can be the native user/password that CS supports or by other means like any LDAP or Google/Facebook IDs. There should be some mechanism to map external users to CS accounts. This can be done by some CS component but I personally feel this should also be outside of CS. Comments?
>
> > Do I understand this to mean you want to offer service offerings based
> > on user account in LDAP (or attributes of that account, like OU?)
> >
> > --David
> >
Re: [DISCUSS] Cloudstack to manage User objects in LDAP
Posted by Chip Childers <ch...@sungard.com>.
On Wed, Dec 19, 2012 at 11:57 AM, David Nalley <da...@gnsa.us> wrote:
> Can you confine this to an authentication plugin? (I think this might
> be a stretch - but I haven't looked at auth plugins in a while.)
Not really. The only methods inherited from DefaultUserAuthenticator
are authenticate, configure and encode. Configure doesn't configure a
user...
Re: [DISCUSS] Cloudstack to manage User objects in LDAP
Posted by David Nalley <da...@gnsa.us>.
On Wed, Dec 19, 2012 at 11:47 AM, Chip Childers
<ch...@sungard.com> wrote:
> On Wed, Dec 19, 2012 at 11:44 AM, David Nalley <da...@gnsa.us> wrote:
>> On Wed, Dec 19, 2012 at 12:59 AM, Manikanta Kattamuri
>> <ma...@sungard.com> wrote:
>>> Hi,
>>>
>>>
>>>
>>> We'd like to be able to have CloudStack manage the user objects from LDAP.
>>>
>>> The reason would, be we have a set of other service offerings for the users
>>> of cloudstack service.
>>>
>>>
>>>
>>> Are there any others facing this type of scenarios and any solutions or
>>> on-going development to resolve this.
>>>
>>>
>>>
>>> Inputs and thoughts are very much welcome.
>>
>>
>> Define 'manage'?
>>
>
> Create, update, delete OU's and users via LDAP calls.
>
Can you confine this to an authentication plugin? (I think this might
be a stretch - but I haven't looked at auth plugins in a while.)
--David
Re: [DISCUSS] Cloudstack to manage User objects in LDAP
Posted by Chip Childers <ch...@sungard.com>.
On Wed, Dec 19, 2012 at 11:44 AM, David Nalley <da...@gnsa.us> wrote:
> On Wed, Dec 19, 2012 at 12:59 AM, Manikanta Kattamuri
> <ma...@sungard.com> wrote:
>> Hi,
>>
>>
>>
>> We'd like to be able to have CloudStack manage the user objects from LDAP.
>>
>> The reason would, be we have a set of other service offerings for the users
>> of cloudstack service.
>>
>>
>>
>> Are there any others facing this type of scenarios and any solutions or
>> on-going development to resolve this.
>>
>>
>>
>> Inputs and thoughts are very much welcome.
>
>
> Define 'manage'?
>
Create, update, delete OU's and users via LDAP calls.
> Do I understand this to mean you want to offer service offerings based
> on user account in LDAP (or attributes of that account, like OU?)
>
> --David
>
Re: [DISCUSS] Cloudstack to manage User objects in LDAP
Posted by David Nalley <da...@gnsa.us>.
On Wed, Dec 19, 2012 at 12:59 AM, Manikanta Kattamuri
<ma...@sungard.com> wrote:
> Hi,
>
>
>
> We'd like to be able to have CloudStack manage the user objects from LDAP.
>
> The reason would, be we have a set of other service offerings for the users
> of cloudstack service.
>
>
>
> Are there any others facing this type of scenarios and any solutions or
> on-going development to resolve this.
>
>
>
> Inputs and thoughts are very much welcome.
Define 'manage'?
Do I understand this to mean you want to offer service offerings based
on user account in LDAP (or attributes of that account, like OU?)
--David
Re: [DISCUSS] Cloudstack to manage User objects in LDAP
Posted by Chip Childers <ch...@sungard.com>.
On Wed, Dec 19, 2012 at 12:59 AM, Manikanta Kattamuri
<ma...@sungard.com> wrote:
> Hi,
>
> We'd like to be able to have CloudStack manage the user objects from LDAP.
>
> The reason would, be we have a set of other service offerings for the users
> of cloudstack service.
>
> Are there any others facing this type of scenarios and any solutions or
> on-going development to resolve this.
>
> Inputs and thoughts are very much welcome.
>
> Thanks & Regards,
> Manikanta.
So let me add a little color to the problem Mani's talking about
above. As a cloud provider, we prefer to keep our users within an
OpenLDAP directory. Lots of reasons for this, but basically it's
because we can have different apps / services authenticating against a
common source.
CloudStack obviously has an LDAP authenticator plugin, but it comes
with the assumption that users / accounts are managed outside of
CloudStack. We'd like to be able to use the CloudStack UI / API to
manage these user objects, instead of having to stand up an isolated
tool for customers to maintain their accounts.
So I have two questions for the community:
1) Does management of objects in LDAP seem like a reasonable plugin to create?
2) Are there approaches to solving the problem described above that
don't involve creating this plugin (perhaps others have experience
with something similar)?
-chip