openstack team mailing list archive

["John Purrier" <john@xxxxxxxxxxxxx>]

Agree that this is a tricky technical issue, and I agree that the issue of
management of Authn and Authz should be external to Nova and all other
OpenStack components.

 

I believe there are two fundamental problems to be solved and that we will
confuse ourselves if we try to mix them together:

 

1.       Single administrative / security domain topology. Consisting of
potentially multiple zones there is a single authority for identities and
authn/authz. Components within each zone have connectivity to the security
authority. The issue of how the singular authority is distributed/replicated
is a problem solved by the IDM (LDAP, AD, etc.).

 

This is the base topology that any private or public cloud will need to
implement. It will be overlaid on the required network topology to provide
true isolation for resources owned by an identity.

 

2.       Multiple security domain topologies. This is the federated cloud
model that OpenStack has on the strategic roadmap. Overlaid on #1, a set of
resources is identified by the #1 security authority and a virtual network
is created that all of these resources attach to. A secondary cloud can
attach to this network and treat it as an extension of its native network
(VPN, tunneling, etc.). Once this topology is established, the
administrative domain within the overlay is owned by the security domain of
the secondary cloud (opaque to the underlying host cloud). 

 

The issue of how to create connectivity between the secondary security
domain and the newly created overlay in the remote cloud is still TBD.

 

John

 

From: openstack-bounces+john=openstack.org@xxxxxxxxxxxxxxxxxxx
[mailto:openstack-bounces+john=openstack.org@xxxxxxxxxxxxxxxxxxx] On Behalf
Of Khaled Hussein
Sent: Monday, March 28, 2011 11:02 AM
To: OpenStack
Subject: Re: [Openstack] Federated Identity Management (bursting and zones)

 

I personally think that having an external Identity Management solution is
the best option. In my mind there are vare valuable benefits for having a
highly scalable, enterprise class, identity management solution on OpenStack
such as (1) Separation of concerns of Authentication and Authorization from
the core OpenStack services and (2) Providing a unified authentication and
user management system for OpenStack services (i.e. Swift, Nova, Glance,
..etc.). 

 

I think this is worthy of a summit discussion.

 

Thanks,

Khaled

On Mon, Mar 28, 2011 at 10:27 AM, <ksankar@xxxxxxxxxxxxxx> wrote:

Couple of quick thoughts:

 

IMHO, -2. Rely on external system- is the best solution. This enables the
decoupling of authorization, which then can be extended or integrated with
existing systems, as appropriate by Openstack deployments. This also can be
an instance of a federated identity management.  

 

-1.Replicated user accounts- is the worst as it can create sync problems.

 

Cheers

<k/>

-------- Original Message --------
Subject: [Openstack] Federated Identity Management (bursting and zones)

From: Sandy Walsh <sandy.walsh@xxxxxxxxxxxxx>

Date: Mon, March 28, 2011 7:15 am
To: "openstack@xxxxxxxxxxxxxxxxxxx" <openstack@xxxxxxxxxxxxxxxxxxx>

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. 

 

Nasty problem. Lots of issues and concerns with each approach. 

 

Is there anyone actively working on this who can share some info?

What is the currently sentiment in terms of an approach?

 

Summit discussion?

 

Thanks,

Sandy

 

 

 

PS> I did some scanning of the BP's and don't see anything directly
addressing this. 

https://blueprints.launchpad.net/nova/+spec/bursting

https://blueprints.launchpad.net/nova/+spec/authentication-consistency

https://blueprints.launchpad.net/nova/+spec/bexar-auth-manager-api

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@xxxxxxxxxxxxx, and delete the original message.
Your cooperation is appreciated.

  _____  


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxx, and delete the original message.
Your cooperation is appreciated.