openstack team mailing list archive

[Vishvananda Ishaya <vishvananda@xxxxxxxxx>]

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 J.
>  
> 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.

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

"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.

Vish