> On Apr 26, 2015, at 22:35, Dolph Mathews <dolph.math...@gmail.com> wrote: > > >> On Sunday, April 26, 2015, Jamie Lennox <jamielen...@redhat.com> wrote: >> >> >> ----- 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. > > +1 all the above >
As a bit of an expansion from what Jamie said, the project that is in the token is known to exist as the token validates the existence of a project before issuing a token scoped for it. >> >> 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 > __________________________________________________________________________ > 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
