Open Stack

On Tue, May 3, 2016 at 1:46 PM, Clint Byrum <clint at fewbar.com> wrote:

> Excerpts from Morgan Fainberg's message of 2016-05-03 11:13:38 -0700:
> > On Tue, May 3, 2016 at 10:28 AM, Monty Taylor <mordred at inaugust.com>
> wrote:
> >
> > > On 05/03/2016 11:47 AM, Clint Byrum wrote:
> > >
> > >> Excerpts from Monty Taylor's message of 2016-05-03 07:59:21 -0700:
> > >>
> > >>> On 05/03/2016 08:55 AM, Clint Byrum wrote:
> > >>>
> > >>>>
> > >>>> Perhaps we have different perspectives. How is accepting what we
> > >>>> previously emitted and told the user would be valid sneaky or wrong?
> > >>>> Sounds like common sense due diligence to me.
> > >>>>
> > >>>
> > >>> I agree - I see no reason we can't validate previously emitted
> tokens.
> > >>> But I don't agree strongly, because re-authing on invalid token is a
> > >>> thing users do hundreds of times a day. (these aren't oauth API Keys
> or
> > >>> anything)
> > >>>
> > >>>
> > >> Sure, one should definitely not be expecting everything to always work
> > >> without errors. On this we agree for sure. However, when we do decide
> to
> > >> intentionally induce errors for reasons we have not done so before, we
> > >> should weigh the cost of avoiding that with the cost of having it
> > >> happen. Consider this strawman:
> > >>
> > >> - User gets token, it says "expires_at Now+4 hours"
> > >> - User starts a brief set of automation tasks in their system
> > >>    that does not use python and has not failed with invalid tokens
> thus
> > >>    far.
> > >> - Keystone nodes are all updated at one time (AMAZING cloud ops team)
> > >> - User's automation jobs fail at next OpenStack REST call
> > >> - User begins debugging, wasting hours of time figuring out that
> > >>    their tokens, which they stored and show should still be valid,
> were
> > >>    rejected.
> > >>
> > >
> > > Ah - I guess this is where we're missing each other, which is good and
> > > helpful.
> > >
> > > I would argue that any user that is _storing_ tokens is doing way too
> much
> > > work. If they are doing short tasks, they should just treat them as
> > > ephemeral. If they are doing longer tasks, they need to deal with
> timeouts.
> > > SO, this:
> > >
> > >
> > > - User gets token, it says "expires_at Now+4 hours"
> > > - User starts a brief set of automation tasks in their system
> > >    that does not use python and has not failed with invalid tokens thus
> > >    far.
> > >
> > > should be:
> > >
> > > - User starts a brief set of automation tasks in their system
> > > that does not use python and has not failed with invalid tokens thus
> > > far.
> > >
> > > "Get a token" should never be an activity that anyone ever consciously
> > > performs.
> > >
> > >
> > This is my view. Never, ever, ever assume your token is good until
> > expiration. Assume the token might be broken at any request and know how
> to
> > re-auth.
> >
> > > And now they have to refactor their app, because this may happen again,
> > >> and they have to make sure that invalid token errors can bubble up to
> the
> > >> layer that has the username/password, or accept rolling back and
> > >> retrying the whole thing.
> > >>
> > >> I'm not saying anybody has this system, I'm suggesting we're putting
> > >> undue burden on users with an unknown consequence. Falling back to
> UUID
> > >> for a while has a known cost of a little bit of code and checking junk
> > >> tokens twice.
> > >>
> > >
> > Please do not advocate "falling back" to UUID. I am actually against
> making
> > fernet the default (very, very strongly), if we have to have this
> > "fallback" code. It is the wrong kind of approach, we already have
> serious
> > issues with complex code paths that produce subtly different results. If
> > the options are:
> >
> > 1) Make Fernet Default and have "fallback" code
> >
> > or
> >
> > 2) Leave UUID default and highly recommend fernet (plus gate on fernet
> > primarily, default in devstack)
> >
> > I will jump on my soapbox and be very loudly in favor of the 2nd option.
> If
> > we communicate this is a change that will happen (hey, maybe throw an
> > error/make the config option "none" so it has to be explicit) in Newton,
> > and then move to a Fernet default in O - I'd be ok with that.
> >
> > >
> > > Totally. I have no problem with the suggestion that keystone handle
> this.
> > > But I also think that users should quite honestly stop thinking about
> > > tokens at all. Tokens are an implementation detail that if any user
> thinks
> > > about while writing their app they're setting themselves up to be
> screwed -
> > > so we should make sure we're not talking about them in a primary way
> such
> > > as to suggest that people focus a lot of energy on them.
> > >
> > > (I also frequently see users who are using python libraries even get
> > > everything horribly wrong and screw themselves because they think they
> need
> > > to think about tokens)
> > >
> >
> > Better communication that tokens are ephemeral and should not assume to
> > work always (even until their expiry) should be the messaging we use.
> It's
> > simple, plan to reauth as needed and handle failures.
>
> This is not what the documentation says, so yeah, we need to actually
> tell users that expires_at is an upper bounds, because right now it
> says:
>
>  The date and time when the token expires.
>
>  The date and time stamp format is ISO 8601:
>
>  CCYY-MM-DDThh:mm:ss±hh:mm
>
>  For example, 2015-08-27T09:49:58-05:00.
>
>  The ±hh:mm value, if included, is the time zone as an offset from UTC.
>  In the previous example, the offset value is -05:00.
>
>  A null value indicates that the token never expires.
>
>
Ok this here is a major issue we need to fix. a token with a null expires
will *not* validate.


> http://developer.openstack.org/api-ref-identity-v3.html
>
> Perhaps "The latest date and time when the token expires. Tokens may be
> revoked or expired before this time and any use of tokens should be
> prepared to reauthenticate to keystone and obtain a new token at any
> time upon encountering a 401 error code from any service."
>
>
++ Lets fix this ASAP.


> I am not suggesting, btw, that users would explicitly think about getting
> tokens. I just think a user would read the docs as they are now, and
> reasonably think that they could expect tokens to be around a stable
> amount of time, and would be annoyed that they weren't. Obviously people
> would like to not think about that, and that's fine, but let's actually
> tell users how the API works if we're going to do that.
>
> BTW, I'd submit a patch, but I can't find the api-ref/source for the
> identity API. :-P
>
>
The docs are too spread out. Sadly the API Ref has been neglected and..
well.. yes what you said.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160503/0b616b5d/attachment.html>