Open Stack

Hi Brant,

Sorry, for being confusing earlier. We have operations an administrator/operator is performing on behalf of a user, e.g. “Create Loadbalancer X for user tenant-id 123”. Now we are not checking the tenant-id and are wondering how to make the operation more robust with kesyone’s help.

Thanks,
German

From: Brant Knudson [mailto:blk at acm.org]
Sent: Friday, April 24, 2015 11:43 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate teanant-id for admin operation



On Fri, Apr 24, 2015 at 11:53 AM, Eichberger, German <german.eichberger at hp.com<mailto:german.eichberger at hp.com>> wrote:
All,

Following up from the last Neutron meeting:

If Neutron is performing an operation as an admin on behalf of a user that user's tenant-id (or project-id) isn't validated - in particular an admin can mistype and create object on behalf of non existent users. I am wondering how other projects (e.g. Nova) deal with that and if there is some API support in keystone to save us a round trip (e.g. authenticate admin + validate additional user-id).

Not to long ago we got support in the auth_token middleware for a "service" token in addition to the user's token. The user token is sent in the x-auth-token header and the service token is sent in the x-service-token, and then fields from both tokens are available to the application (e.g., the user project is in HTTP_X_PROJECT_ID and the service token roles are in HTTP_X_SERVICE_ROLES). So you could potentially have a policy rule on the server for the operation that required the service token to have the 'service' role, and what neutron could do is send the original user token in x-auth-token and send its own token as the service token. This seems to be what you're asking for here.

- Brant

Thanks,
German

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150424/d069219a/attachment.html>