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
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
