Hi Vish, Please see my comments inline.
From: Vishvananda Ishaya [mailto:vishvana...@gmail.com] Sent: 18 July 2011 17:36 To: Salvatore Orlando Cc: Ziad Sawalha; openstack@lists.launchpad.net Subject: Re: [Openstack] OpenStack Identity: Keystone API Proposal Below: On Jul 18, 2011, at 3:28 AM, Salvatore Orlando wrote: Hi, I'm jumping in this thread to understand whether there's a chance KeyStone can implement some use cases around the concept of object ownership. I apologise if this email turns out to be a bunch of nonsense; unfortunately I don't have a strong AAA background :). As pointed out several times in this thread, this is something which should be enforced in the service: once a request comes in, the AA middleware validates the token and retrieves user identity with Keystone, using it to verify whether the user owns the objects on which the request operates. However, sometimes requests operate on objects defined in different services; for instance in the Quantum service (L2 networking), the operation for plugging an interface on a port operate on the following resources: - The network and the port, defined in quantum - The interface being plugged, defined in nova The AA middleware needs to verify that the user 'owns' all these resources, in order to ensure, for instance, that a tenant does not plug another tenant's interface in his own network. As this process involves resources defined in two distinct services, I was wondering whether Keystone could help in any way, by exposing APIs for registering/unregistering/listing object ownership relationships. These relationships could be stored in the form <service-name>:<object-uuid> and associated to the appropriate Keystone object, tenant or user. AA middleware in services such as Quantum could query Keystone for the list of objects owned by a given user/tenant in a service or for establishing whether a user/tenant owns specific object(s). Would it be reasonable to expect to have something like that in Keystone? Object ownership is a bit of a nebulous concept. Instead each service should define particular actions. For example: <role> can_attach_port <port_id> <role> can_plug_interface <interface> The system can go through and do checks on each particular action in the context of a subject (role), predicate (action), and object (object). In my mind, the most bang for the buck is to think of the subject as a role (or list of roles). In this model, authn is responsible for mapping a token to user / tenant / roles and authz is responsible for mapping roles / actions / objects. Agreed. A model where authZ is defined in terms of <subject><predicate><object> rules is where we ultimately want to end up. Now it is possible to define some shared cases where your authz mapping could use wildcard matching. For example *, can_attach_port, 75 -> any role can attach to port 75 admin, can_plug_interface, * -> an admin can plug into any interface. You can create more control by allowing the authz system to group objects in the same way that roles can "group" tenants, for example: big_tenant, can_attach_ports, (owned_by_big_tenant) -> allow anyone with the big_tenant role to attach to any port owned by big_tenant If I get your last example correctly, "(owned_by_big_tenant)" is something that should be enforced in the authZ middleware for the service. Which is fine in many cases, and it should work even for the use case I was mentioning (plugging interface into Quantum networks). However, IMHO this kind of use case is a bit more convoluted, as the user/tenant/role mapped to the auth token needs to satisfy both a predicate for the interface (likely to be defined in nova) and the network (defined in quantum), so the rules should be something like: 1) nova: tenant_X_user, can_manage_interface, {<interface-id> | *} 2) quantum: tenant_X_user, can_plug_interface, {<network-id> | *} If the identity service would provide a way to manage this rules, then the authZ middleware for the specific service could implement the logic for enforcing them, without having to query other services for deciding whether a user/tenant is authorized to perform an operation or not. I think Ziad's proposal for service-specific roles goes into this direction. "ownership" is an implicit grouping of objects by "owner". The most general case would allow objects to be grouped in arbitrary ways, but I think the majority of use cases are solved by allowing very specific grouping according to owner_id This is how we implemented it in the authn / authz branch of many moons ago, and it seemed to provide enough flexibility. Are you referring to the authN/authZ middleware which is now part to the Openstack API? In that case I could use this as a reference for implementing our middleware. 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
