Open Stack

Hey Paul,

At the Tokyo summit we discussed a general way to make it so that user
tokens were only expiration tested once. When the token hits nova for
example we can say it was validated, then when nova talks to glance it
sends both the user token (or enough data to represent the user token) and
an X-Service-Token which is the token nova validated with and we say the
presence of the X-Service-Token means we should trust that the previous
service already did enough validation to just trust it.

This is a big effort because it's going to require changing how service to
service communication works at all places.

At the moment I don't have a blueprint for this. The biggest change is
going to be making service->service communication rely on keystoneauth auth
plugins so that we can have the auth plugin control what data is
communicated rather than hack this in to every location and so far has
required updates to middleware and future to oslo.context and others to
make this easy for services to consume. This work has been ongoing by
myself, mordred and morgan (if you see reviews to switch your service to
keystoneauth plugins please review as it will make the rest of this work
easier in future).

I certainly don't expect to see this pulled off in Mitaka time frame.

For the mean time more and more services are relying on trusts, which is an
unfortunate but workable solution.

Jamie

On 18 December 2015 at 22:13, Paul Carlton <paul.carlton2 at hpe.com> wrote:

> Jamie
>
> John Garbutt suggested I follow up this issue with you.  I understand you
> may be leading the
> effort to address the issue of token expiry during a long running
> operation.  Nova
> encounter this scenario during image snapshots and live migrations.
>
> Is there a keystone blueprint for this issue?
>
> Thanks
>
> --
> Paul Carlton
> Software Engineer
> Cloud Services
> Hewlett Packard
> BUK03:T242
> Longdown Avenue
> Stoke Gifford
> Bristol BS34 8QZ
>
> Mobile:    +44 (0)7768 994283
> Email:    mailto:paul.carlton2 at hpe.com
> Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks
> RG12 1HN Registered No: 690597 England.
> The contents of this message and any attachments to it are confidential
> and may be legally privileged. If you have received this message in error,
> you should delete it from your system immediately and advise the sender. To
> any recipient of this message within HP, unless otherwise stated you should
> consider this message and attachments as "HP CONFIDENTIAL".
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151221/1bcd8c07/attachment.html>