Open Stack

> On Apr 26, 2015, at 22:35, Dolph Mathews <dolph.mathews at gmail.com> wrote:
> 
> 
>> On Sunday, April 26, 2015, Jamie Lennox <jamielennox at redhat.com> wrote:
>> 
>> 
>> ----- Original Message -----
>> > From: "German Eichberger" <german.eichberger at hp.com>
>> > To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at 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: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 > 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://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> >
>> > __________________________________________________________________________
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: OpenStack-dev-request at 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-request at 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-request at 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/20150427/d528e50d/attachment.html>