Hi all, As you might already know, today (July 14th) we had a meeting over the phone aimed at discussing authentication and authorization for Quantum. Me (Salvatore Orlando), Dan Wendlandt, Josh Wilmes and Mark Voelker attended the meeting.
This email is the very first action agreed during this meeting, as we decided to move the discussion to the Netstack mailing list; now that we have it, it makes sense to use it for all the discussion concerning architecture and design for NetStack projects. Before delving into the details of the authorization model in terms of roles and actions which should be authorized for each role, we agreed that we first need to address the problem of verifying the correct ownership of objects managed by quantum. For instance when a user configured for a specific tenant plugs an interface, we need to verify at least that: a) The tenant owns the network where the interface is being plugged; b) The tenant owns the interface being plugged into the network, ie the VM instance where the interface has been configured belongs to the tenant. This implies that a concept of "object ownership" is required; however, in this specific case ownership should be verified across several services, as the network is defined by Quantum, whereas the interface is defined by nova-compute. For this reason it would be good if the identify service (possibly Keystone) would be able to provide this information. There is an interesting e-mail thread on Keystone (look for "OpenStack Identity: Keystone API Proposal" on Openstack ML) in which some members of the community were wondering whether Keystone could provide some form of authorization as well. At the moment authorization is entirely performed in service modules. Ziad was proposing to support per-service roles in tenants (e.g.: quantum:networkadmin, nova:netadmin). Keystone can return which roles are defined for a given token and a service, so that Quantum would then be able to verify that the user performing the plug-interface operation has ownership rights both on the network and the interface. Therefore the next action agreed in the meeting is to follow-up the discussion on the Openstack ML in order to understand how keystone could solve the "object ownership" problem. We also agreed that we will be using Keystone for the first implementation of AuthN/AuthZ in Quantum, as it is a modular service which enables several protocols. At the moment it support basic and token-based authentication; OpenID support is in progress, and there have been talks around LDAP support as well. Any thoughts? Regards, Salvatore
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
