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/owner/servers/ so
owner would be the owner. This could be anything depending on what
the authenticated user has access to do and what the authz
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/owner/servers/ so
owner would be the owner. This could be anything depending on what
the authenticated user has access
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
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 collections of
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
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 organization
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 user
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
the db
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 expensive
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
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.
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 of
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
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
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 have
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 i
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
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 organization that
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
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
subjects
: [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
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
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
On Wed, Mar 30, 2011 at 11:57 AM, Sandy Walsh sandy.wa...@rackspace.com 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
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
On Wed, Mar 30, 2011 at 12:44 PM, Sandy Walsh sandy.wa...@rackspace.com 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
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
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
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.
.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.wa...@rackspace.com
Date: Mon, March 28, 2011 7:15 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
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
one last note for completeness:
http://etherpad.openstack.org/r7eSWs0b8k
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
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 :
34 matches
Mail list logo
