----- Original Message ----- > From: "German Eichberger" <german.eichber...@hp.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@lists.openstack.org> > Sent: Saturday, 25 April, 2015 8:55:23 AM > Subject: Re: [openstack-dev] [Neutron][Keystone] [Nova] How to validate > teanant-id for admin operation > > > > 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
Not to speak for Brant, but i think the confusion here is why you are doing this. From my perspective you should never be in a position where the admin has to enter a raw project id like that. I think the problem here is the assumption of an all powerful admin user, and i'd encourage you to change your policy files to scrap that idea. A role is granted on a project and this project is mentioned in the token. If there is some role that is provided that lets you perform operations outside of the project id specified in that token please file a bug and i'd consider marking it a security issue. The X-Service-Token concept will allow for the combination of a user token and a service token to authenticate an action, so the user can ask for an action to be performed on it's behalf via a service - and in which case the user's project id is communicated via the token. In lieu of all this the quick answer is no. If you are taking a project id from the command line and you want to validate its existence then you have to ask keystone, but you should always be getting this information from a token. Jamie > > 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 > 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://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 > __________________________________________________________________________ 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
