Comment 72 for bug 2004555

following melwitt, comment #70

> Hm. I wonder if we could instead only check whether the user
> requesting has the "service" role (if "service" in
> RequestContext.roles) or is a member of the "service" project? And
> leave the service_token part out of it.

I'm afraid that if we try to figure out the source of the request
ourselves somehow, we'll be subject to some kind of request forgery
exploit. I think sticking with the service_token is the safest course
of action. The upside is that all the concerned services use the
keystone middleware that supports send_service_token, so other than
configuring each service correctly, there's no software upgrade or
anything involved.

> Technically a deployment could give any project or role to their
> service users (and omit any) ... so I'm not sure whether it's
> reasonable to assume any of the project names or role names or user
> names.

I agree with you completely here, and for the reasons you state, we
won't be able to provide a script to do this automatically. We'll
have to provide clear documentation of how to configure this correctly.
But the plus side is that while the send_user_token stuff may not be
configured at a site, the must be some kind of service user configured
for each service (at least I think so?), and we can refer to the config
options by name in explaining what to do to configure send_user_token
and make the policy file changes.