Open Stack

Hi,

You could call GET project/project_id and verify that the project really
exists in Keystone. But again by doing that you would be increasing load on
Keystone server. When UUID tokens are being used, an additional call is
needed to verify the token. If you add another call to this then it would
be too much for Keystone server. So none of the other components as of now
do this i.e. verify the existence of the project. I don't know if there are
any plans to address this.


Cheers,
Ajaya

On Sat, Apr 25, 2015 at 4:25 AM, Eichberger, German <
german.eichberger at hp.com> wrote:

>  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> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150427/9b9f3db0/attachment.html>