Open Stack

I'm curious about the interactions from the user side with OAuth (cmdline)

Unless there's work underway on this already I wouldn't mind throwing a BP/spec together on how this might work (if possible).

Any objections?

-S

________________________________
From: openstack-bounces+sandy.walsh=rackspace.com at lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace.com at lists.launchpad.net] on behalf of Vishvananda Ishaya [vishvananda at gmail.com]
Sent: Monday, March 28, 2011 2:19 PM
To: Khaled Hussein
Cc: openstack at lists.launchpad.net
Subject: Re: [Openstack] Federated Identity Management (bursting and zones)

Agreed, Pluggable option 2 with a default OAuth implementation seems like the best strategy.

Vish

On Mar 28, 2011, at 9:42 AM, Khaled Hussein wrote:

I was thinking of having OAuth implementation for authorization/delegation in an external identity management solution, option 2 :). The IdM solution can be extensible to support other Identity Federation protocols as well such as SAML.

Khaled

On Mon, Mar 28, 2011 at 11:17 AM, Jay Pipes <jaypipes at gmail.com<mailto:jaypipes at gmail.com>> wrote:
On Mon, Mar 28, 2011 at 10:15 AM, Sandy Walsh <sandy.walsh at rackspace.com<mailto:sandy.walsh at rackspace.com>> wrote:
> Currently, we link Nova deployments (aka Zones) with a single admin account.
> All operations done in the child zone are done with this admin account.
> Obviously this needs to change. A simple operation such as "get_all_servers"
> should only return the servers that User X owns. In the current
> implementation, all the servers the admin account can see will be returned.
> We need some form of federated identity management. User accounts must be
> shared between homogeneous and heterogeneous deployments. ie. all private,
> all public or public/private (aka Hybrid) via Bursting.
> There are some possibilities here:
> 1. Replicate User accounts across zones. A user account would map to N child
> zone accounts ... one for each child zone. These "placeholder" accounts are
> hidden from the user and synchronized when the parent changes.
> 2. Rely on an external/shared user management service. Let the Auth/RBAC
> system sort out visibility, control, etc. This system would need to be
> publicly available to both groups in the hybrid scenario.
> 3. Continue with the admin account and filter access control/visibility in
> the parent zone.
> ... and I'm sure there are others.

4. Use OAuth?

-jay

_______________________________________________
Mailing list: https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack>
Post to     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
Unsubscribe : https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack>
More help   : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp



Confidentiality Notice: This e-mail message (including any attached or
embedded documents) is intended for the exclusive and confidential use of the
individual or entity to which this message is addressed, and unless otherwise
expressly indicated, is confidential and privileged information of Rackspace. 
Any dissemination, distribution or copying of the enclosed material is prohibited.
If you receive this transmission in error, please notify us immediately by e-mail
at abuse at rackspace.com, and delete the original message. 
Your cooperation is appreciated.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110328/7deed495/attachment.html>