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:b...@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.eichber...@hp.com<mailto:german.eichber...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
