Re: [Openstack] Federated Identity Management (bursting and zones)

Hi Jorge, Thanks for the detailed description, and sorry for the delayed response, I was at a conference this week. This clears up the terminology, but I guess I'm still not seeing what this really gives use (specifically resource groups). It seems overly complicated, but I'm probably just missing

Re: [Openstack] Federated Identity Management (bursting and zones)

We called them "Resource Groups" because we wanted to make a distinction between them and "User Groups" . We feel, we need to support both. Based on your IRC conversation, I think there seems to be a confusion between both kinds of groups so let me take a step back and explain our thinking.

Re: [Openstack] Federated Identity Management (bursting and zones)

On Thu, Apr 07, 2011 at 11:54:26AM +, Sandy Walsh wrote: > > Well, they should start off with what the request specifies. For > > the 1.1 API, this takes the for of POST /v1.1//servers/ so > > would be the owner. This could be anything depending on what > > the authenticated user has access to

Re: [Openstack] Federated Identity Management (bursting and zones)

From: Eric Day [e...@oddments.org] > Well, they should start off with what the request specifies. For > the 1.1 API, this takes the for of POST /v1.1//servers/ so > would be the owner. This could be anything depending on what > the authenticated user has access to do and what the authz system > d

Re: [Openstack] Federated Identity Management (bursting and zones)

On Wed, Apr 06, 2011 at 11:31:35AM +, Sandy Walsh wrote: > Myself and Eric were chatting a little more about this on IRC yesterday > http://paste.openstack.org/show/1108/ > > Eric made an interesting observation that we don't need to call them Resource > Groups, since they're just collection

Re: [Openstack] Federated Identity Management (bursting and zones)

I agree we should be able to specify network resource when launching an instance to get around the vlan-per-owner issue. This gets to the bigger issue of splitting out nova network as a different network-as-a-service project and enabling more functionality there (such as allow other resource types

Re: [Openstack] Federated Identity Management (bursting and zones)

Myself and Eric were chatting a little more about this on IRC yesterday http://paste.openstack.org/show/1108/ Eric made an interesting observation that we don't need to call them Resource Groups, since they're just collections of UUID's (or URI's or URN's or whatever). They could refer to Users

Re: [Openstack] Federated Identity Management (bursting and zones)

. don't allocate new instances in Zones running low on available networks? -S From: Vishvananda Ishaya [vishvana...@gmail.com] Sent: Tuesday, April 05, 2011 4:31 PM To: Sandy Walsh Cc: Eric Day; openstack@lists.launchpad.net Subject: Re: [Openstack] Fede

Re: [Openstack] Federated Identity Management (bursting and zones)

Just thought of something else to consider. There is a further issue with setting the owner to resource_group: Networking. In Vlan mode, each owner gets its own vlan and communication between the instances is easy. If users start dividing up instances into a bunch of sub-groups we will run ou

Re: [Openstack] Federated Identity Management (bursting and zones)

From: Vishvananda Ishaya [vishvana...@gmail.com] > Ok so we are aggregating at the service layer. That does make optimization a > bit easier. Especially > if the user can specify with the OnBehalfOf idea a subset of the instances he > wants to list. Yeah, previously it would have been expensi

Re: [Openstack] Federated Identity Management (bursting and zones)

On Apr 5, 2011, at 9:07 AM, Sandy Walsh wrote: > >> groups = AuthZ.get_resource_groups('alice') >> instances = set() >> for group in groups: >>instances.union(set(nova.get_instances(group))) >> return instances > > Agree that this could result in lots of little queries as written above, but

Re: [Openstack] Federated Identity Management (bursting and zones)

From: Vishvananda Ishaya [vishvana...@gmail.com] > I think account/action tuple isn't too complicated. If we decide not to use > use the resource_groups as > tags, meaning multiple can be applied to same object, then we probably need > this functionality. Or else we > will have some crazy use

Re: [Openstack] Federated Identity Management (bursting and zones)

> From: Vishvananda Ishaya [vishvana...@gmail.com] > > Ok, as I read it now, the resource groups are really a different terminology > for the same thing we were discussing before. The difference is that in this > model the resource group always ends up as the "owner" of the project. Correct, s

Re: [Openstack] Federated Identity Management (bursting and zones)

On Apr 4, 2011, at 6:46 PM, Eric Day wrote: > Hi Vish, > > On Mon, Apr 04, 2011 at 05:56:38PM -0700, Vishvananda Ishaya wrote: >> I agree that your suggestion is simpler, but I think we are too limited if >> we remove multi-membership and per-object overrides. Imagine that alice is >> an orga

Re: [Openstack] Federated Identity Management (bursting and zones)

Ok, as I read it now, the resource groups are really a different terminology for the same thing we were discussing before. The difference is that in this model the resource group always ends up as the "owner" of the project. I would still suggest that this makes some actions inside a service ve

Re: [Openstack] Federated Identity Management (bursting and zones)

Doh! I'm an idiot. Write that down. Eric, you're correct, we don't need to sync the AuthZ servers. We only need to pass the Resource Group ID's along after the user authenticates (thanks Jorge for reminding me.) This is along the lines of what you have been suggesting with different User accou

Re: [Openstack] Federated Identity Management (bursting and zones)

From: Eric Day [e...@oddments.org] > The extra cost is this introduces a new type. If we are going with an > authenticated user returning a list of accounts or account/action > tuples, then having another type for resource groups seems > excessive. It seems we only need one mapping layer here, not

Re: [Openstack] Federated Identity Management (bursting and zones)

On Tue, Apr 05, 2011 at 01:53:46AM +, Sandy Walsh wrote: > From: Vishvananda Ishaya [vishvana...@gmail.com] > > Eric: > > I agree that your suggestion is simpler, but I think we are too limited if > > we remove multi-membership and per- > > object overrides. Imagine that alice is an organizat

Re: [Openstack] Federated Identity Management (bursting and zones)

From: Vishvananda Ishaya [vishvana...@gmail.com] > Eric: > I agree that your suggestion is simpler, but I think we are too limited if we > remove multi-membership and per- > object overrides. Imagine that alice is an organization that has 10 users > and a lot of instances. If i create a group >

Re: [Openstack] Federated Identity Management (bursting and zones)

Hi Vish, On Mon, Apr 04, 2011 at 05:56:38PM -0700, Vishvananda Ishaya wrote: > I agree that your suggestion is simpler, but I think we are too limited if we > remove multi-membership and per-object overrides. Imagine that alice is an > organization that has 10 users and a lot of instances. If

Re: [Openstack] Federated Identity Management (bursting and zones)

> From: Vishvananda Ishaya [vishvana...@gmail.com] > I don't see how one would give access to an entire organization at once. We don't need to. When a user auths into the SP world we get a set of permissions for that user from MyCo. If everyone in MyCo auth'ed against the SP they would all hav

Re: [Openstack] Federated Identity Management (bursting and zones)

From: Eric Day [e...@oddments.org] > Service Provider zones could be configured to access authz.myco.com > for any authentication requests that come in for the myco.com namespace. Hmm, yes I think that might be possible (with the obvious performance concerns). My concern was that we would have

Re: [Openstack] Federated Identity Management (bursting and zones)

Eric: I agree that your suggestion is simpler, but I think we are too limited if we remove multi-membership and per-object overrides. Imagine that alice is an organization that has 10 users and a lot of instances. If i create a group called alice_shares, then I have to remember to add all of

Re: [Openstack] Federated Identity Management (bursting and zones)

I don't see how one would give access to an entire organization at once. That was the purpose of returning multiple subjects from auth in the other proposal. If I want to give everyone in the "bar" organization in my instance, the check somehow has to be able to find out that bob is a member o

Re: [Openstack] Federated Identity Management (bursting and zones)

Hi Sandy, Thanks for putting this together, it really helps to facilitate the discussion. I do have a couple concerns though with this latest design. The AuthZ services talk to each other. I don't see why this should be happening, since a zone can be configured to talk with a number of authz serv

Re: [Openstack] Federated Identity Management (bursting and zones)

Phew, ok, I've boiled down the various federated AuthZ discussions with eday, vish & jorge. I've superseded the old blueprint since the bulk of the work is clearly in the Federated AuthZ camp and not the AuthN camp. http://wiki.openstack.org/FederatedAuthZwithZones Shorter and more succinct.

Re: [Openstack] Federated Identity Management (bursting and zones)

For those of you following along at home ... there was a big IRC discussion around this: http://paste.openstack.org/show/1075/ Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entit

Re: [Openstack] Federated Identity Management (bursting and zones)

h 30, 2011 7:29 PM > To: Sandy Walsh > Cc: Jay Pipes; openstack@lists.launchpad.net > Subject: Re: [Openstack] Federated Identity Management (bursting and zones) > > I think authz is simplest if we just give it the responsibility of mapping > subjects, verbs, and objects. > > subjects ar

Re: [Openstack] Federated Identity Management (bursting and zones)

ishvananda Ishaya [vishvana...@gmail.com] Sent: Wednesday, March 30, 2011 7:29 PM To: Sandy Walsh Cc: Jay Pipes; openstack@lists.launchpad.net Subject: Re: [Openstack] Federated Identity Management (bursting and zones) I think authz is simplest if we just give it the responsibility of mapping

Re: [Openstack] Federated Identity Management (bursting and zones)

Best Regard Hugo K. Vishvananda Ishaya 於 2011/3/31 6:29 寫道： > I think authz is simplest if we just give it the responsibility of mapping > subjects, verbs, and objects. > > subjects are returned by authn. They can be users/projects/roles/groups/etc, > but are basically opaque > verbs are d

Re: [Openstack] Federated Identity Management (bursting and zones)

I think authz is simplest if we just give it the responsibility of mapping subjects, verbs, and objects. subjects are returned by authn. They can be users/projects/roles/groups/etc, but are basically opaque verbs are defined by the application: launch_instance, get_volume, get_container, etc. o

Re: [Openstack] Federated Identity Management (bursting and zones)

From: Jay Pipes [jaypi...@gmail.com] > Come to think of it, there's no reason that role A would need to have similar > privileges in zones X and Y. More likely than not, they would have different privileges, and therefore a federated authz service wouldn't really make sense. I see your point, I

Re: [Openstack] Federated Identity Management (bursting and zones)

I agree with Vish here. A common set of group names would be a good first step and allow us to federate authn without the upfront complexity of trying to also federate authz. Come to think of it, there's no reason that role A would need to have similar privileges in zones X and Y. More likely than

Re: [Openstack] Federated Identity Management (bursting and zones)

From: Vishvananda Ishaya [vishvana...@gmail.com] > So we can have a set of standard groups defined, and if Alice's AuthN returns > one of those groups, she can launch. It means we will probably have to > define some sort of openstack-compatible authn groups. True ... I'll give some thought to t

Re: [Openstack] Federated Identity Management (bursting and zones)

Not sure that AuthZ has to be federated. If AuthN can return a list of meaningful groups (something akin to roles) to AuthZ, we can isolate AuthZ to a given deployment. So we can have a set of standard groups defined, and if Alice's AuthN returns one of those groups, she can launch. It means

Re: [Openstack] Federated Identity Management (bursting and zones)

On Wed, Mar 30, 2011 at 12:44 PM, Sandy Walsh wrote: > This flow is saying "The AuthZ resource lives on your side of the fence and > I'd like to access it", but to do so Alice needs to grant permission and that > interaction seems confusing to me. Ja wohl, I don't disagree that it could well be

Re: [Openstack] Federated Identity Management (bursting and zones)

From: Jon Slenk [jsl...@internap.com] > I think that if the system used capabilities/ZBAC then there would be no such weird prompting. I see your point, but I'm assuming AuthZ has to be federated as well. We don't know about Alice, she lives in her private cloud. We have to ask her AuthZ system

Re: [Openstack] Federated Identity Management (bursting and zones)

On Wed, Mar 30, 2011 at 11:57 AM, Sandy Walsh wrote: > http://wiki.openstack.org/ZonesOauth "At this point the user will be asked to confirm the request (assuming this is the first interaction the user has had with this Zone). So, here's an authenticated user getting this seemingly random prompt

Re: [Openstack] Federated Identity Management (bursting and zones)

So, I assuming having the auth service external, this would imply one HA Auth service per business. It would span regions, data centers, zones, etc. Otherwise it gets really messy. I've started mapping out some use cases (with event trace) here http://wiki.openstack.org/ZonesOauth It's really l

Re: [Openstack] Federated Identity Management (bursting and zones)

There's prior art to OAuth from the cmdline. Anything that interacts with Launchpad's API does it. See e.g. bzr lp-propose-merge. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpa

Re: [Openstack] Federated Identity Management (bursting and zones)

one last note for completeness: http://etherpad.openstack.org/r7eSWs0b8k Thanks Vish ... that's what I was looking for. For others: https://code.launchpad.net/~anso/nova/authn_and_authz/+merge/52119

Re: [Openstack] Federated Identity Management (bursting and zones)

.html Will review. <http://plansthis.com/auth>-S From: Vishvananda Ishaya [vishvana...@gmail.com] Sent: Monday, March 28, 2011 6:21 PM To: Sandy Walsh Subject: Re: [Openstack] Federated Identity Management (bursting and zones) Some work was done in the A

Re: [Openstack] Federated Identity Management (bursting and zones)

ces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Vishvananda Ishaya [vishvana...@gmail.com] Sent: Monday, March 28, 2011 2:19 PM To: Khaled Hussein Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Federated Iden

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

Re: [Openstack] Federated Identity Management (bursting and zones)

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

Re: [Openstack] Federated Identity Management (bursting and zones)

well as well integratable with existing systems.As Sandy pointed out, we should have a summit discussion; and we want to be pragmatic otherwise this domain can get pretty wide very fast.Cheers Original Message Subject: Re: [Openstack] Federated Identity Management (bursting and

Re: [Openstack] Federated Identity Management (bursting and zones)

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 wrote:

Re: [Openstack] Federated Identity Management (bursting and zones)

On Mon, Mar 28, 2011 at 10:15 AM, Sandy Walsh 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

Re: [Openstack] Federated Identity Management (bursting and zones)

> > -1.Replicated user accounts- is the worst as it can create sync problems. > > Cheers > > > Original Message ---- > Subject: [Openstack] Federated Identity Management (bursting and zones) > From: Sandy Walsh > Date: Mon, March 28, 2011 7:15 am > To:

Re: [Openstack] Federated Identity Management (bursting and zones)

.  -1.Replicated user accounts- is the worst as it can create sync problems.Cheers Original Message Subject: [Openstack] Federated Identity Management (bursting and zones) From: Sandy Walsh <sandy.wa...@rackspace.com> Date: Mon, March 28, 2011 7:15 am To: &quo

[Openstack] Federated Identity Management (bursting and zones)

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 implem