Open Stack

On 05/16/2017 08:08 PM, Zane Bitter wrote:
> On 16/05/17 01:06, Colleen Murphy wrote:
>> Additionally, I think OAuth - either extending the existing OAuth1.0
>> plugin or implementing OAuth2.0 - should probably be on the table.
> 
> I believe that OAuth is not a good fit for long-lived things like an
> application needing to communicate with its own infrastructure. Tokens
> are (a) tied to a user, and (b) expire, neither of which we want. Any
> use case where you can't just drop the user into a web browser and ask
> for their password at any time seem to be, at a minimum, excruciatingly
> painful and often impossible with OAuth, because that is the use case it
> was designed for.

I think that's the key bit I was noodling over when OAuth was brought
up. OAuth is really about acting as the user that created it. But one of
the very common concerns is how "when marry in IT quits, and she did all
the automated systems, what happens?" It's actually a quite common issue
(related issue) in the small organization space that the Twitter, shared
gmail, etc was set up by one staff member, who then leaves. And then
scramble hoping that they left an email address around. Because these
entities we less concerned about long term maintenance than initial sign up.

These things have to live at a project level to handle people
disappearing, and their access being revoked. You might want to rotate
keys then anyway on these things, depending.

I think that's one of the things about why OpenStack is going to be
different here. The shared project construct and resources belonging to
projects not users. I honestly wish more internet services understood
that as a common pattern. If there is a way that naturally fits in OAuth
that I'm not aware of cool. But if not, I think it comes off the table
pretty fast.

	-Sean

-- 
Sean Dague
http://dague.net