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/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 system defines for types, but Nova doesn't care as it's just a string. Yes, this is a slight variation on our previous discussions, but I like it. What we're saying is that Instance (resource) names will be prefixed with container names and permissions will be applied to containers. It's good because it solves the problem of on behalf of. However, what I need to wrap my head around is how this would work in a federated fashion. MyCo has a container structure and SP has a container structure. We need to manage permissions on: /myco/instances/finance/ami- /myco/instances/alice/ami- /myco/instance/bob/ami-*** /sp/myco/instances/finance/ami-*** /sp/myco/instances/alice/ami-*** /sp/myco/instances/bob/ami-*** and place the permissions at the top of the tree. Or, /instances/finance/myco/ami-*** /instances/finance/SP/ami-*** and place the permissions at the /instances/finance level ... but how would these transfer across the public/private zone boundaries? (since MyCo.authz controls the permissions and SP.authz just enforces it) From an end-user perspective, does Alice or Bob need to know to manage permissions for MyCo and for the situations when the instances live with SP? I need to stew on that some more. This implies, of course, that there would be a means to chgrp() a resource in Nova across Zones. Not a big deal and pretty handy actually. Well, we may not always want to change the owner for this, we may want to simply add to the list of entities (user/groups/whatever) that can access it. Owner alone is not enough. In this scenario chgrp() would equate to a move() operation ... to move from one container to another. but I don't care enough to spend time on what we call it. :) +1 One thing to also think about is where we actually describe permissions. I mentioned this briefly in a previous thread, but I think this needs more exploration. Lets approach authz as looking at what Swift does today and expanding on it. A authenticated user in swift gets a list of 'groups' that user belongs to. This is just like what we've been talking about, except swift only has group name, not (group,action) tuples. A name in the group list can be anything, from another account, a tag, whatever. It's just a string. For now lets use 'group' and mean account/entity/whatever from above. There are then permissions on containers that specify actions for groups (think of group/action tuples on a resource). So if container X has write permission for group A, a user with group A in their list can insert objects there. The shortcoming with this model is that you need a resource to exist to assign permissions to it (for example, a container needs to be created by the account owner first). I asked Chuck and it sounds like you can't specify group A can create containers for group/account B. Not sure if I like the idea of read/write permissions vs. Rights (strings), but that's a side discussion. With Rights we could grant permission for a user to create a new container and assign Account B access to it. can_create_container, can_change_owner Or perhaps I'm missing the subtly here. In Nova, and probably other services, we want the ability to specify actions for groups when a resource doesn't exist. For example, I want to give group A the ability to create instances for group B, but there is no container resource yet. The obvious way to solve this is to do what we've been discussing and have the authz system return not just group name, but (group,action) tuples. Can't the user just create the container first and then create the instance in the container? The question now is do we restrict the types of actions that can be specified in the authz system vs per-resource for a service? If you can specify can_reboot in both the authz system and per-resource, how are ambiguities resolved? For example, the authz system may return (group A, [can_create, can_reboot]), but an instance record may contain the permission tuple (group A, can_associate_ip). What can group A really do to that instance? Is it the union, intersection, or the most specific set of actions? If we design our authz in this way, we just need to be aware and choose. I'm not clear how we ended up with permissions in two places? I thought the AuthZ would manage the tree of containers and permissions, not the services. The service would just do the permission check. Are you talking about per-resource overrides on the authz permissions? -S -Eric Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the
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/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 system defines for types, but Nova doesn't care as it's just a string. Yes, this is a slight variation on our previous discussions, but I like it. What we're saying is that Instance (resource) names will be prefixed with container names and permissions will be applied to containers. Not really. We don't have containers in Nova now, and I don't think we really need them. I just meant that owner is a required parameter when creating an instance, so the API needs to get it from somewhere (default to authenticated user, from path, json param, etc). The above could be POST /v1.1/servers just like it is today, and owner was given in the JSON of the request body. owner required just like flavor, image, etc. and place the permissions at the top of the tree. Or, /instances/finance/myco/ami-*** /instances/finance/SP/ami-*** and place the permissions at the /instances/finance level ... but how would these transfer across the public/private zone boundaries? (since MyCo.authz controls the permissions and SP.authz just enforces it) What do you mean SP.authz enforces? SP.authz should not ever be contacted when dealing with MyCO.authz users, no? This implies, of course, that there would be a means to chgrp() a resource in Nova across Zones. Not a big deal and pretty handy actually. Well, we may not always want to change the owner for this, we may want to simply add to the list of entities (user/groups/whatever) that can access it. Owner alone is not enough. In this scenario chgrp() would equate to a move() operation ... to move from one container to another. Hmm, you lost me here. :) One thing to also think about is where we actually describe permissions. I mentioned this briefly in a previous thread, but I think this needs more exploration. Lets approach authz as looking at what Swift does today and expanding on it. A authenticated user in swift gets a list of 'groups' that user belongs to. This is just like what we've been talking about, except swift only has group name, not (group,action) tuples. A name in the group list can be anything, from another account, a tag, whatever. It's just a string. For now lets use 'group' and mean account/entity/whatever from above. There are then permissions on containers that specify actions for groups (think of group/action tuples on a resource). So if container X has write permission for group A, a user with group A in their list can insert objects there. The shortcoming with this model is that you need a resource to exist to assign permissions to it (for example, a container needs to be created by the account owner first). I asked Chuck and it sounds like you can't specify group A can create containers for group/account B. Not sure if I like the idea of read/write permissions vs. Rights (strings), but that's a side discussion. I was reviewing what Swift does above, not making suggestions for Nova. In Nova, and probably other services, we want the ability to specify actions for groups when a resource doesn't exist. For example, I want to give group A the ability to create instances for group B, but there is no container resource yet. The obvious way to solve this is to do what we've been discussing and have the authz system return not just group name, but (group,action) tuples. Can't the user just create the container first and then create the instance in the container? As I mentioned above, I don't think we should introduce containers, which gets back to the issue of how to grant group-level permission without a resource (such as ability to create new resources). Switching from the swift style group list to (group,action) list solves this. The question now is do we restrict the types of actions that can be specified in the authz system vs per-resource for a service? If you can specify can_reboot in both the authz system and per-resource, how are ambiguities resolved? For example, the authz system may return (group A, [can_create, can_reboot]), but an instance record may contain the permission tuple (group A, can_associate_ip). What can group A really do to that instance? Is it the union, intersection, or the most specific set of actions? If we design our authz in this way, we just need to be aware and choose. I'm not clear how we ended up with permissions in two places? I thought the AuthZ would manage the tree of containers and permissions, not the services. The service would just do the permission check. Are you talking about per-resource overrides on the authz permissions? Yes. We could have authz for an entity
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 outside of nova be able to interact with and specify network preferences). We shouldn't let current limitations of other components that should hopefully be changing soon dictate where we need to move in the future for things like authn/authz. -Eric On Tue, Apr 05, 2011 at 12:31:22PM -0700, Vishvananda Ishaya wrote: 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 out of vlans very quickly. Network communication between the subgroups will probably be much more complicated as well. Perhaps some of this can be solved with the multinic / network refactor. If we can specify at launch which network we want the instance created in instead of keying it off of the owner's network, we might have everything we need. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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 collections of UUID's (or URI's or URN's or whatever). They could refer to Users, other Resource Groups, Instances, Projects, whatever. So, starting off, new Resources are created with the User ID as the owner. Later, when MyCo.authz passes the permission tuples to SP, they could include the UUID of the user. If the instance needed to be controlled by a group of people, the owner of the resource could be changed to be a User Group. 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 system defines for types, but Nova doesn't care as it's just a string. This implies, of course, that there would be a means to chgrp() a resource in Nova across Zones. Not a big deal and pretty handy actually. Well, we may not always want to change the owner for this, we may want to simply add to the list of entities (user/groups/whatever) that can access it. Owner alone is not enough. Eric suggested calling them Entity Groups vs Resource Groups. (aside: I find Entity is a pretty overloaded term ... perhaps Security Groups?) Security groups overlap with the network permissions names, so I'm not sure that's a good choice either. Last time I suggested entity folks preferred 'account', which is fine too. I think account still implies some context, but I don't care enough to spend time on what we call it. :) One thing to also think about is where we actually describe permissions. I mentioned this briefly in a previous thread, but I think this needs more exploration. Lets approach authz as looking at what Swift does today and expanding on it. A authenticated user in swift gets a list of 'groups' that user belongs to. This is just like what we've been talking about, except swift only has group name, not (group,action) tuples. A name in the group list can be anything, from another account, a tag, whatever. It's just a string. For now lets use 'group' and mean account/entity/whatever from above. There are then permissions on containers that specify actions for groups (think of group/action tuples on a resource). So if container X has write permission for group A, a user with group A in their list can insert objects there. The shortcoming with this model is that you need a resource to exist to assign permissions to it (for example, a container needs to be created by the account owner first). I asked Chuck and it sounds like you can't specify group A can create containers for group/account B. In Nova, and probably other services, we want the ability to specify actions for groups when a resource doesn't exist. For example, I want to give group A the ability to create instances for group B, but there is no container resource yet. The obvious way to solve this is to do what we've been discussing and have the authz system return not just group name, but (group,action) tuples. The question now is do we restrict the types of actions that can be specified in the authz system vs per-resource for a service? If you can specify can_reboot in both the authz system and per-resource, how are ambiguities resolved? For example, the authz system may return (group A, [can_create, can_reboot]), but an instance record may contain the permission tuple (group A, can_associate_ip). What can group A really do to that instance? Is it the union, intersection, or the most specific set of actions? If we design our authz in this way, we just need to be aware and choose. -Eric ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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 accounts, but without overloading Accounts and sticking to the Collection of Resources idea (as used in RBAC, SAML, etc) There is a complexity here. When we create new Resources on the SP side we need to know which Resource Group to create it on behalf of. I've put a little description of the problem here: http://wiki.openstack.org/FederatedAuthZwithZones#On_Behalf_Of The rest of the wiki has been updated to reflect these changes. -S PS I think we're close to putting a pin in this thing. 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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 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 other 10 users of alice to that group, and the instances are no longer logically grouped because they will show up at a different url or require a different set of credentials to access. This sucks from a usability perspective. I should also mention that if we are going to the trouble of making an api to create new groups anyway, it might be better to just bite the bullet and jump into multiple ownership. Sorry for the confusion, I was only addressing the extra layer of resource groups that was proposed on the wiki page. I didn't mention per-object permissions, but I agree we still need them. I realize now my example is a misleading one (and can be better solved by per-object permissions), but it was only there to show another way it could be done without resource groups as they were proposed. When you say we can't remove multi-membership, what exactly do you mean? I agree, and was not proposing that since an authentication ID can list as many account/action tuples as needed. Ah i thought the suggestion had been changed to returning only one account per id. I see that is not the case now. We still have issues with listing instances accross accounts or groups which i mentioned in my other email. The original proposal was to keep a single owner, but allow resources to be overridden individually. This gives me the freedom to give bob access to all of my instances, or some subset of them as i see fit. It avoids the extra data and complication of managing service groups. I think this is the simplest approach, but it does sacrifice the feature of managing permissions on sets of objects below the ownership level. I think we can still do this with single owner plus per-resource overrides, the override list would be one of the account ID's returned for an authenticated user, which could be returned for multiple users. There is the question of whether the per-resource override should simply be an account ID or another account/action tuple, and I'm not 100% sure. I think we could allow tuples for more fine-grained control, but would be a bit more logic to match actions and not just account IDs. If we keep tuples here and in the list returned from authentication, is this excessive or too complicated? 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 with a different resource_group owner for every single vm in their organization. The resource groups that are suggested seem like something akin to tags, where you could tag a set of resources and give access to all of them. In this scenario, the instances would still have alice as the owner, but some of them would be tagged alice_shares. These can actually be subject groups, but there has to be a mapping of resources to subjects somewhere, and i think that could actually be done in the service layer instead of the authz layer, perhaps even using instance metadata. The drawback of this method is that it essentially boils down to multiple-ownership and requires auth api additiions to allow group creation and modification. These can actually be subject groups, ... was what I was trying to say with my example. :) Wouldn't the mapping of resources to subject groups be the per-resource overrides in the service layer? I'm not sure why multiple ownership is needed. I think we need to avoid multiple ownership, since this makes many other components ambiguous (such as a canonical URL, who to bill, etc). Yes, I was agreeing with your point. Again the multilple ownership I was suggesting was single-ownership with tags that act as pseudo-owners. Canonical url can still be under the owner, but allowing to list by tag, for example, makes listing all the instances under a shared group possible without crazy aggregation schemes. Again, not sure it is worth the complexity, so if we can find a way around the listing issues and organization level roles issues that I mentioned in my other email, I'm happy to avoid it. -Eric Resource groups does feels like it could be a bit YAGNI, but we definitely need some way for sharing to occur that maintains some usability. On Apr 4, 2011, at 4:02 PM, Eric Day wrote: 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
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 user with a different resource_group owner for every single vm in their organization. That could still happen regardless. Again, I think it's easier to just update one group than run around updating tags on many instances. Yes, I was agreeing with your point. Again the multilple ownership I was suggesting was single-ownership with tags that act as pseudo-owners. Canonical url can still be under the owner, but allowing to list by tag, for example, makes listing all the instances under a shared group possible without crazy aggregation schemes. Again, not sure it is worth the complexity, so if we can find a way around the listing issues and organization level roles issues that I mentioned in my other email, I'm happy to avoid it. Perhaps I'm missing where the 'crazy aggregation' part comes in? We get a flat list of Resource Groups from MyCo and do a Select against the DB for all of them. Only MyCo AuthZ has to worry about nesting, we just have a flat list. -S 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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
the db can do all the work quite easily with some small tweaks.
return nova.get_instances(groups)
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.
I would still suggest that this makes some actions inside a service very
annoying. How does one list all of the
instances belonging to an organization, or accessible to a user? Do we push
to the client side?
I'm also not sure that it gives us useful control over something like roles.
Imagine Jon, a security adminstrator
for OrganizationA. You want him to be able to network isolate vms for
OrganizationA. How do you specify
that he can isolate any one of OrganizationAs instances?
(Jon, can_isolate, )
Is it assumed that we specify a special role and Auth is going to return a
giant list of all of the resource
groups that are in organizationA?
Either that or a wildcard for all perhaps?
(Jon, can_isolate, *)
Wildcards won't work if one provider is supporting multiple organizations (this
has been specifically requested by some clients btw, so it isn't just
astronauting), unless we support more of a regex wildcard:
(jon, can_isolate, OrganizationA.*)
That would be a cool feature, but it would require the auth service to return
groups according to a specific format. Otherwise, the giant list should
definitely work up to a certain size.
Vish
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
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 expensive to do this in the services, but now I think it's small enough that a nice little authz client library could handle it. Either that or a wildcard for all perhaps? (Jon, can_isolate, *) Wildcards won't work if one provider is supporting multiple organizations (this has been specifically requested by some clients btw, so it isn't just astronauting), unless we support more of a regex wildcard: (jon, can_isolate, OrganizationA.*) That would be a cool feature, but it would require the auth service to return groups according to a specific format. Otherwise, the giant list should definitely work up to a certain size. Makes sense. This would be the Reseller use case that comes up frequently. Sounds like the Resource Group naming is going to be just as important as Instance ID naming. -S Vish 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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 out of vlans very quickly. Network communication between the subgroups will probably be much more complicated as well. Perhaps some of this can be solved with the multinic / network refactor. If we can specify at launch which network we want the instance created in instead of keying it off of the owner's network, we might have everything we need. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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. Should address many of the issues that have arisen to date. -S 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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 of bar. Getting multiple subjects back from auth makes this easy because bob could be in a member of different subjects that would all be returned: [group:workers] [organization:bar] etc... And I can just say (organization:bar, can_halt, alice) is there a way to do this type of thing in this proposal? Vish On Apr 4, 2011, at 1:19 PM, Sandy Walsh wrote: 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. Should address many of the issues that have arisen to date. -S 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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 other 10 users of alice to that group, and the instances are no longer logically grouped because they will show up at a different url or require a different set of credentials to access. This sucks from a usability perspective. I should also mention that if we are going to the trouble of making an api to create new groups anyway, it might be better to just bite the bullet and jump into multiple ownership. The original proposal was to keep a single owner, but allow resources to be overridden individually. This gives me the freedom to give bob access to all of my instances, or some subset of them as i see fit. It avoids the extra data and complication of managing service groups. I think this is the simplest approach, but it does sacrifice the feature of managing permissions on sets of objects below the ownership level. The resource groups that are suggested seem like something akin to tags, where you could tag a set of resources and give access to all of them. In this scenario, the instances would still have alice as the owner, but some of them would be tagged alice_shares. These can actually be subject groups, but there has to be a mapping of resources to subjects somewhere, and i think that could actually be done in the service layer instead of the authz layer, perhaps even using instance metadata. The drawback of this method is that it essentially boils down to multiple-ownership and requires auth api additiions to allow group creation and modification. Resource groups does feels like it could be a bit YAGNI, but we definitely need some way for sharing to occur that maintains some usability. On Apr 4, 2011, at 4:02 PM, Eric Day wrote: 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 services directly depending on some prefix. For example, in the diagram on the wiki page, Service Provider zones could be configured to access authz.myco.com for any authentication requests that come in for the myco.com namespace. It doesn't need to touch authz.sp.com for any reason. You introduced resource groups, but I don't think we need resource groups, as those could simply be more fine-grained subject groups. In fact I think we should boil this down more to align with the previous auth discussions in that we're only dealing with 'accounts', and an account can be an owner, user, or group. For example, you could have the accounts: alice alice_shares bob When alice authenticates, you would get tuple describing alice can perform all actions for resources owned by alice and alice shares. Alice can also create resources under alice or alice_shares. When bob authenticates the tuples would allow bob to perform all actions for resources owned by bob, but also perhaps reboot resources owned by alice_shares. This model would give a great deal of flexibility and reduces the types involved to just a list of (account, actions) for each authenticated entity. Resources only need to track a single owner too, it doesn't need a list of resource groups it belong to or anything else. If believe this is much how swift already works as well. -Eric On Mon, Apr 04, 2011 at 08:19:36PM +, Sandy Walsh wrote: 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. Should address many of the issues that have arisen to date. -S 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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 to make a call back to authz.myco.com to check *every* instance. By having a pared-down set to work with we can avoid having to scan all the instances under MyCo's control. But, you are correct that we could get that pared down list from authz.myco.com just as easily as from sp.authz. Let me stew on that one some more. For example, you could have the accounts: alice alice_shares bob Yes, I thought about that more over the weekend. While it's attractive for up-front simplicity it makes account management much harder. Whenever we want to delegate a command from MyCo to SP we need to decide which account we will use to perform the operation. User account management will become just as complicated as Resource Group synchronization. -S 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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 have the same permissions on a set of instances. In other words, the Subject is implied by receiving the auth token and permissions are relative to that. -S 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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 i create a group called alice_shares, then I have to remember to add all of other 10 users of alice to that group, and the instances are no longer logically grouped because they will show up at a different url or require a different set of credentials to access. This sucks from a usability perspective. I should also mention that if we are going to the trouble of making an api to create new groups anyway, it might be better to just bite the bullet and jump into multiple ownership. Sorry for the confusion, I was only addressing the extra layer of resource groups that was proposed on the wiki page. I didn't mention per-object permissions, but I agree we still need them. I realize now my example is a misleading one (and can be better solved by per-object permissions), but it was only there to show another way it could be done without resource groups as they were proposed. When you say we can't remove multi-membership, what exactly do you mean? I agree, and was not proposing that since an authentication ID can list as many account/action tuples as needed. The original proposal was to keep a single owner, but allow resources to be overridden individually. This gives me the freedom to give bob access to all of my instances, or some subset of them as i see fit. It avoids the extra data and complication of managing service groups. I think this is the simplest approach, but it does sacrifice the feature of managing permissions on sets of objects below the ownership level. I think we can still do this with single owner plus per-resource overrides, the override list would be one of the account ID's returned for an authenticated user, which could be returned for multiple users. There is the question of whether the per-resource override should simply be an account ID or another account/action tuple, and I'm not 100% sure. I think we could allow tuples for more fine-grained control, but would be a bit more logic to match actions and not just account IDs. If we keep tuples here and in the list returned from authentication, is this excessive or too complicated? The resource groups that are suggested seem like something akin to tags, where you could tag a set of resources and give access to all of them. In this scenario, the instances would still have alice as the owner, but some of them would be tagged alice_shares. These can actually be subject groups, but there has to be a mapping of resources to subjects somewhere, and i think that could actually be done in the service layer instead of the authz layer, perhaps even using instance metadata. The drawback of this method is that it essentially boils down to multiple-ownership and requires auth api additiions to allow group creation and modification. These can actually be subject groups, ... was what I was trying to say with my example. :) Wouldn't the mapping of resources to subject groups be the per-resource overrides in the service layer? I'm not sure why multiple ownership is needed. I think we need to avoid multiple ownership, since this makes many other components ambiguous (such as a canonical URL, who to bill, etc). -Eric Resource groups does feels like it could be a bit YAGNI, but we definitely need some way for sharing to occur that maintains some usability. On Apr 4, 2011, at 4:02 PM, Eric Day wrote: 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 services directly depending on some prefix. For example, in the diagram on the wiki page, Service Provider zones could be configured to access authz.myco.com for any authentication requests that come in for the myco.com namespace. It doesn't need to touch authz.sp.com for any reason. You introduced resource groups, but I don't think we need resource groups, as those could simply be more fine-grained subject groups. In fact I think we should boil this down more to align with the previous auth discussions in that we're only dealing with 'accounts', and an account can be an owner, user, or group. For example, you could have the accounts: alice alice_shares bob When alice authenticates, you would get tuple describing alice can perform all actions for resources owned by alice and alice shares. Alice can also create resources under alice or alice_shares. When bob authenticates the tuples would allow bob to perform all actions for resources owned by bob, but also
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 called alice_shares, then I have to remember to add all of other 10 users of alice to that group, and the instances are no longer logically grouped because they will show up at a different url or require a different set of credentials to access. This sucks from a usability perspective. I should also mention that if we are going to the trouble of making an api to create new groups anyway, it might be better to just bite the bullet and jump into multiple ownership. Agree, as per my previous email. I think the effort to support multiple user accounts is no different than managing multiple resource groups. The original proposal was to keep a single owner, but allow resources to be overridden individually. [...] I think this is the simplest approach, but it does sacrifice the feature of managing permissions on sets of objects below the ownership level. The override concept give me pause. It seems like unnecessary work when the problem can be handled easier by assigning ownership to a Resource to a group vs a single user. The resource groups that are suggested seem like something akin to tags, where you could tag a set of resources and give access to all of them. In this scenario, the instances would still have alice as the owner, but some of them would be tagged alice_shares. These can actually be subject groups, but there has to be a mapping of resources to subjects somewhere, and i think that could actually be done in the service layer instead of the authz layer, perhaps even using instance metadata. The drawback of this method is that it essentially boils down to multiple- ownership and requires auth api additiions to allow group creation and modification. I like tags, they scale well. But they work best as way of representing static metadata (think bookmarks in delicio.us) ... if the tags are changing frequently then groups are easier to update (vs. running around to all instances that need tags added/removed) Resource groups does feels like it could be a bit YAGNI, but we definitely need some way for sharing to occur that maintains some usability. From my discussion with Jorge, much of this functionality is present in the existing Rackspace authz system and on the roadmap for inclusion. It is modeled on existing SAML and RBAC approaches. It should work easily with LDAP containers as well. -S 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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 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 other 10 users of alice to that group, and the instances are no longer logically grouped because they will show up at a different url or require a different set of credentials to access. This sucks from a usability perspective. I should also mention that if we are going to the trouble of making an api to create new groups anyway, it might be better to just bite the bullet and jump into multiple ownership. Agree, as per my previous email. I think the effort to support multiple user accounts is no different than managing multiple resource groups. 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 two. I'm not sure if we're agreeing with different terminology or if there are actually differences. :) What I interpreted on the wiki didn't seem to line up with how we were talking last Friday on IRC, but this could be my misunderstanding. -Eric ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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 two. Sorry, I made that confusing. Resource = Object from our previous discussion. I was using the terminology already adopted by Jorge's group. Resource Group = list of Objects. I'm not sure if we're agreeing with different terminology or if there are actually differences. :) What I interpreted on the wiki didn't seem to line up with how we were talking last Friday on IRC, but this could be my misunderstanding. Hopefully we're saying the same thing? :) I don't think this is a radically different collection than List-of-Users. -S 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Federated Identity Management (bursting and zones)
I was stewing on the suggestion of subject/verb/object tuples. There's a gotcha in the federated AuthZ situation: mapping Public and Private Objects in the tuples. Essentially, who owns the rights over the object if the object is externally managed (by, let's say, a service provider). My thoughts around how Federated AuthZ might work in Nova are updated here: http://wiki.openstack.org/ZonesOauth#Thoughts_on_Federated_AuthZ (and made some slight tweaks to map it to conventional RBAC schemes) Please burn/spindle/mutilate ... -S From: Vishvananda 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, 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. objects are the entities that actions are performed on. Then the authz system can just define how these three are mapped to create a pass/fail. There can be some magic in the rules to make this much easier: 1) the concept of an object_owner. This allows rules to match the stuff returned by authn to an owner field on the object 2) dividing groups of actions into certain roles or groups returned by authn. The obvious one here is admin, but other general roles could be defined as well. I'm not sure how we validate the roles returned by an external authn server. We don't really want Alice's admins to have full admin rights to our deploy. Perhaps some namespacing here is necessary. alice.admin vs mydeploy.admin Vish On Mar 30, 2011, at 3:10 PM, Sandy Walsh wrote: 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 was thinking at the Rights level, not Roles/Groups, and envisioning Rights like: can_boot_os=windows;linux can_boot_flavor=tiny;small;medium can_migrate_outside_zone=True maximum_ram_size=512m Certainly, we could have pre-established Rights just as we would have common Roles/groups. -S 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Federated Identity Management (bursting and zones)
Made a few notes on thoughts at the bottom. I won't replicate the notes here because it kind of requires reading through the link you supplied first. In short, I think we have some options for keeping AuthZ isolated to a given deployment and even a given service. I like this approach, because I want to minimize the number of contact points between different deployments. Vish On Apr 1, 2011, at 7:40 AM, Sandy Walsh wrote: I was stewing on the suggestion of subject/verb/object tuples. There's a gotcha in the federated AuthZ situation: mapping Public and Private Objects in the tuples. Essentially, who owns the rights over the object if the object is externally managed (by, let's say, a service provider). My thoughts around how Federated AuthZ might work in Nova are updated here: http://wiki.openstack.org/ZonesOauth#Thoughts_on_Federated_AuthZ (and made some slight tweaks to map it to conventional RBAC schemes) Please burn/spindle/mutilate ... -S From: Vishvananda 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, 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. objects are the entities that actions are performed on. Then the authz system can just define how these three are mapped to create a pass/fail. There can be some magic in the rules to make this much easier: 1) the concept of an object_owner. This allows rules to match the stuff returned by authn to an owner field on the object 2) dividing groups of actions into certain roles or groups returned by authn. The obvious one here is admin, but other general roles could be defined as well. I'm not sure how we validate the roles returned by an external authn server. We don't really want Alice's admins to have full admin rights to our deploy. Perhaps some namespacing here is necessary. alice.admin vs mydeploy.admin Vish On Mar 30, 2011, at 3:10 PM, Sandy Walsh wrote: 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 was thinking at the Rights level, not Roles/Groups, and envisioning Rights like: can_boot_os=windows;linux can_boot_flavor=tiny;small;medium can_migrate_outside_zone=True maximum_ram_size=512m Certainly, we could have pre-established Rights just as we would have common Roles/groups. -S 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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 loose just yet. Just trying to get my thoughts down on paper first. -S 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Federated Identity Management (bursting and zones)
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 seemingly random prompt ServiceProvider.DataCenter.Tower2 would like access to your Permissions. Will you grant this? Huh? That would make no sense. Even less given the fact that the user had to authenticate to get to Zone A in the first place (her credentials have already been given to the client tool). I think that if the system used capabilities/ZBAC then there would be no such weird prompting. sincerely. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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 if she can boot a new instance. 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. -S PS appreciate the feedback! 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Federated Identity Management (bursting and zones)
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 that it could well be confusing. The classic / bog standard approaches to security very much often suck pardon my lingo with respect to usability. And if we're stuck with whatever system the users want to have themselves rather than being able to impose something actually usable, there's probably not much room to improve? (But I'm a pessimist. :-) I can think of a hack attempt to bandage over the usability horribleness, but it is all just adding complexity and papering over the underlying lameness. I.e. when the Parent realizes that it has to offload to a Child, it could at least inform the user that it is doing that, and that the incoming security request is (probably?) about that. sincerely. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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 we will probably have to define some sort of openstack-compatible authn groups. Vish On Mar 30, 2011, at 12:44 PM, Sandy Walsh wrote: 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 if she can boot a new instance. 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. -S PS appreciate the feedback! 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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 was thinking at the Rights level, not Roles/Groups, and envisioning Rights like: can_boot_os=windows;linux can_boot_flavor=tiny;small;medium can_migrate_outside_zone=True maximum_ram_size=512m Certainly, we could have pre-established Rights just as we would have common Roles/groups. -S 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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. objects are the entities that actions are performed on. Then the authz system can just define how these three are mapped to create a pass/fail. There can be some magic in the rules to make this much easier: 1) the concept of an object_owner. This allows rules to match the stuff returned by authn to an owner field on the object 2) dividing groups of actions into certain roles or groups returned by authn. The obvious one here is admin, but other general roles could be defined as well. I'm not sure how we validate the roles returned by an external authn server. We don't really want Alice's admins to have full admin rights to our deploy. Perhaps some namespacing here is necessary. alice.admin vs mydeploy.admin Vish On Mar 30, 2011, at 3:10 PM, Sandy Walsh wrote: 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 was thinking at the Rights level, not Roles/Groups, and envisioning Rights like: can_boot_os=windows;linux can_boot_flavor=tiny;small;medium can_migrate_outside_zone=True maximum_ram_size=512m Certainly, we could have pre-established Rights just as we would have common Roles/groups. -S 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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, ksan...@doubleclix.net 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.wa...@rackspace.com Date: Mon, March 28, 2011 7:15 am To: openstack@lists.launchpad.net openstack@lists.launchpad.net 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. -- ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Federated Identity Management (bursting and zones)
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@lists.launchpad.net [mailto:openstack-bounces+john=openstack@lists.launchpad.net] 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, ksan...@doubleclix.net 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.wa...@rackspace.com Date: Mon, March 28, 2011 7:15 am To: openstack@lists.launchpad.net openstack@lists.launchpad.net 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
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 jaypi...@gmail.com wrote: On Mon, Mar 28, 2011 at 10:15 AM, Sandy Walsh sandy.wa...@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 Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Federated Identity Management (bursting and zones)
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 https://code.launchpad.net/~anso/nova/authn_and_authz/+merge/52119http://plansthis.com/auth http://www.mail-archive.com/openstack@lists.launchpad.net/msg01216.html Will review. http://plansthis.com/auth-S 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 ab...@rackspace.com, and delete the original message. Your cooperation is appreciated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
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://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
