Provide a user-friendly way of authorizing desktop, GUI launchpadlib applications

Leonard and I discussed this with Jonathan Lange, Launchpad product strategist, today.

- We do still want to support being an openid consumer. (This is practically less important to us than other goals, but it is planned and desired nonetheless.)

- This means that, yes, the fake browser approach is doomed. We need to communicate this.

- We are in favor of the "management" desktop application that gets the one-time LP credentials. As of our current thinking, we would expect to support this with three parts.
  * We would create and expose an API for the management desktop application to use to control the access of other programs.
  * We would create a special standalone type of access for a user to grant to the management application. The management application would need this type of access to use the API discussed above.
  * We would make a special webpage for this management desktop application to send the user to for granting this kind of access. The webpage would want to be particularly careful in its language, warning the user what is going on.

- I am marking this as a low priority, but if an Ubuntu developer begins work on the management desktop application, in coordination with Jonathan and other interested parties, we will raise the priority.

"...if an Ubuntu developer begins work on the management desktop application, in coordination with Jonathan and other interested parties, we will raise the priority."

To be clear, coordinating with Jonathan should be sufficient as a first step; I believe he will know the other people that need to be involved.

I just had a chat w/ Rodney Dawes. Here's the summary:
  * ubuntuone-login is a desktop app that does openid dance once and is used to grant permissions to other apps. (the "management" application described above)
  * lucid+1 would be a good time for factoring out some common code
  * We should talk about it at the lucid+1 UDS
  * jml will talk w/ statik about arranging that

Edited IRC transcript:

<jml> I'd like to talk about desktop-based auth* for launchpad at some point
<jml> it sounds like something that is at least vaguely aligned w/ ubuntu one
<jml> but it's also not something that's particularly urgent right now
<dobey> jml: didn't leondardr do some work for that with launchpadlib already?
<jml> dobey, yes, he did.
<jml> dobey, we're going to break it :)
<jml> (his work is a fake browser, this will cease to work when Launchpad consumes openid from providers other than Canonical)
<dobey> jml: yeah, openid pretty much is going to require a web page if we don't control both ends of the connection :-/
<jml> dobey, leonardr & gary are suggesting having a particular desktop application that is specially privileged to grant permissions for other desktop apps
<jml> dobey, so this special application will require a web-based openid login
<jml> the first time, that is, until credentials are invalidated
<jml> but other apps can use it to have a non-web authorization process.
<dobey> jml: that's pretty much exactly what ubuntuone-login is doing
<jml> dobey, see! I knew there was something we had in common :)
<dobey> jml: i would be quite happy for the majority of it to be moved out and made more generic, in the M cycle
<jml> dobey, the M cycle is when we'd be getting around to this, so that works well
<jml> dobey, I wonder what we'd have to do to just be able to use it unmodified
<dobey> jml: well it currently is only set up to get an oauth token for one.ubuntu.com, not launchpad
<dobey> jml: so I guess that's a problem. we also want to have subscription/etc... UI for ubuntu one
<dobey> which launchpadlib shouldn't have to deal with normally
<jml> dobey, by "subscription", you mean something involving people paying money, right?
<dobey> jml: i mean people agreeing to the Ubuntu One TOS, and possibly paying money to upgrade to the paid plan
<dobey> jml: though I suppose new account creation will need to rquire some TOS agreement for LP too perhaps, which would fit in a similar UI
<jml> dobey, we don't have a TOS right now. asking people to sign the COC might be a good idea though.
* jml sniggers
<dobey> jml: not sure how it would all fit together, but perhaps we can get it on the list of blueprints to discuss in Brussels?
<jml> dobey, yeah, that sounds like it would be awesome

I am very willing to work on the client side if someone is ready to work on the server side. I'll be available in IRC to talk about it.

Thanks for volunteering, Martin. Can you follow up with Jonathan to coordinate this work?

Just a few other points:

It's pretty common for other OpenID-accepting sites to also give users the option to create a password, so there are multiple credentials associated with their account. Accepting OpenID doesn't necessarily mean that external apps can't do username/password authentication.

Desktop apps and browsers are in practice running in the same security domain. There are good reasons to avoid people giving their username/password to other web apps but this doesn't apply to desktop apps.

People already do run Launchpad clients from text-only servers and from non-Ubuntu desktops. So anything that _requires_ having a special client side app is also doomed.

istm that leaving open the option to send an http-authenticated request with username and password to create a token, without needing to fake a browser, would be useful.

Good points.

We're never going to require a special client-side app. The browser-based authentication that has worked from the beginning will continue to work. (For a text-only server you'll have to set up a credential ahead of time and copy it over.) The point of the client-side app is to reduce the number of times the average user has to authenticate using their browser.

"the option to send an http-authenticated request with username and password to create a token" -- how do you envision this working? Is there already a standard for this? Maybe the username is your OpenID identity URL and the password is the one you got from your OpenID provider? Does Launchpad send the password to the identity URL to verify it?

The way openid works means you can't have the consumer giving the password to the id provider. It breaks the trigon of trust.

Although you could have an openid service based on something other than a password, we were talking about ssh and pgp keys in IRC. But other things are just as valid.

OK, I agree that the consumer (in this case, Launchpad) shouldn't handle the provider password. Given that, I don't see any way to let the end-user "send an http-authenticated request [to Launchpad] with username and password to create a token." I can come up with standards that would let Launchpad receive an unauthenticated assertion that you own a particular OpenID URL, and redirect you to a URL on the provider's site that lets you prove it, without a web browser getting involved; but do any such standards exist?

I'm not aware of any standards that do, but I'm happy to ask a few communities I'm involved with such as the django community.

If we set a simple standard for ssh over http authentication, then we'd effectively have a single sign on for non-browser activities, you can do your uploads or your oauth through the same mechanism. All that would be required then is a better way to upload such keys.

On 26 March 2010 01:16, Leonard Richardson
<email address hidden> wrote:
> "the option to send an http-authenticated request with username and
> password to create a token" -- how do you envision this working?

Launchpad already accepts http digest auth for requests. (Or did
last time I tried.) So I think you just need (handwaving)

  https://sabdfl:<email address hidden>/~sabdfl/+make_oauth_token?access=write_private

to return an oauth token the application can then use. This is easy
for text-mode clients or clients that can't or don't want to do a
browser-based oauth dance. Obviously it only works for accounts that
actually have a password but many currently do.

We could also, as doctormo suggests, have you do

  ssh <email address hidden> make-oauth-token --access=write-private

but I think that would be harder to implement, and also harder for
non-unixy users to use. (Setting a password on an account is easier
and more familiar than making an ssh key.) But we could do both.

> Is
> there already a standard for this?
> Maybe the username is your OpenID
> identity URL and the password is the one you got from your OpenID
> provider? Does Launchpad send the password to the identity URL to verify
> it?

Ah, you're thinking of something different, which would be for
Launchpad to somehow proxy through to their original OpenID provider.
I agree that would be a bit weird and dangerous.

--
Martin <http://launchpad.net/~mbp/>

So, it sounds like we can do all sorts of cool things if the user defines authentication credentials that are held *by Launchpad*, but if the authentication credentials are held by an arbitrary OpenID provider, all we can do is redirect their browser (HTTP being the lowest common denominator) to the OpenID provider and use the normal OpenID protocol. We can improve on that only by coming up with new standards and getting others to adopt them. Does that sound right? Am I missing something?

That sounds about right, I'd have said "...can do all sorts of cool _and_ uncomplicated things..."

Also add the additional possibility of having an openid provider that we redirect to that is designed for non web browser interactions.

If you were designing an OpenID provider for non-browser interactions, what would you design? (Feel free to point me to the advertising material of an existing OpenID provider.)

Keeping our current authentication-through-the-browser story, augmented with a desktop application that can have the browser authentication happen once, and handle permissions by proxy afterwards, is an approach that works with the current state of the art for OpenID and OAuth. I believe it will be reasonable and sufficient for our use cases.

Leading an initiative for a non-browser OpenID protocol is interesting but, given all the other work we have on our plate, a "Won't Fix." I'm also generally not interested in non-OpenID-based authentication at this time.

If/when there's an existing OpenID-based initiative to provide this, I'm happy to reconsider the idea.

Gary, agreed that that's a WONTFIX, I'm just curious what it would look like.

> Leading an initiative for a non-browser OpenID protocol is interesting but, given all the other work we have on our plate, a "Won't Fix."

I agree.

>Keeping our current authentication-through-the-browser story, augmented with a desktop application that can have the browser authentication happen once, and handle permissions by proxy afterwards, is an approach that works with the current state of the art for OpenID and OAuth. I believe it will be reasonable and sufficient for our use cases.

From Leonard's comment in #7 it seems like the only reason to do this is so that the user gets a "do you want to allow this" in a GUI window rather than in a browser. That seems like an extremely marginal improvement to me, so I don't think this is worth the complexity. It does not increase security and it doesn't help people on non-Ubuntu or non-GUI platforms. But there's no point having an extended argument about whether it's Low or Wishlist. Maybe this bug should be retitled?

If I was going to work on this (which I probably won't) I'd improve launchpadlib so it can do the "please authenticate now" in a gui dialog and automatically detect when the form's been submitted (like some other gnome oauth clients), or I would do user:password authentication as in #11. But they can be separate bugs, also wishlist :)

> That seems like an extremely marginal improvement to me.

And to me, but bug 387297 illustrates that desktop developers consider it a big improvement.

Just to be clear, are we talking about:
  1. Enabling a desktop application that would handle authentication and would be another way for users to allow third-party apps to access their LP data, or
  2. Enabling clients to add extra SSH keys, GPG keys etc through the webservice in a way that doesn't compromise security, or
  3. Something else entirely

Thanks,
jml

> That seems like an extremely marginal improvement to me.

Leonard & Pool: The problem is that programmers are used to jumping through multiple logical streams of thought in order to get a job done. Plus most of them understand what's going on with OAuth. I don't object to the web browser being used in application workflow for my own benefit, but because of what it represents to a designed workflow. Disfiguring things in ways that a desktop user will not understand and will not want to proceed with.

I did a test of 12 users at the SETC to find out what they though of a web browser popping up. It disrupted and confused not only the target app, but existing browser sessions the user was in.

There might not be security gains (to be honest I think you guys go too far and assume too much of users) I plead with you to think of solutions to the design problems. I want a solution that is not complex, that you will agree to implement, that doesn't involve the web browser and that other developers will be happy to use.

The only thing coming close that I can see is a special OAuth tool (cli and desktop based) that checks your ssh keys and creates for you a set of keys if you don't have them and uploads the public key. Allowing each desktop application hence to gain access through that key.

Otherwise just re-enable password authentication.

jml, we are talking about #1. Something like the desktop authorization clients packaged in Leonov, Ground Crontol, and ubuntu-dev-utils, but which actually works now and which will continue to work when Launchpad is an OpenID relying party.

I'm willing to consider _any_ client- and server-side design that will not require end-users to get Launchpad-specific credentials in addition to their OpenID provider credentials. I am as certain as I can be that this means opening their web browser at least once.

If we write a client-side tool that uploads your public SSH key to Launchpad, how does Launchpad know which Launchpad account owns that key? The user would have to be logged in to Launchpad through some other mechanism. This requires opening their web browser and sending them through the normal Launchpad login process where they log in to their OpenID provider.

On Mon, 29 Mar 2010 18:23:48 -0000, Leonard Richardson <email address hidden> wrote:
> jml, we are talking about #1. Something like the desktop authorization
> clients packaged in Leonov, Ground Crontol, and ubuntu-dev-utils, but
> which actually works now and which will continue to work when Launchpad
> is an OpenID relying party.
>
> I'm willing to consider _any_ client- and server-side design that will
> not require end-users to get Launchpad-specific credentials in addition
> to their OpenID provider credentials. I am as certain as I can be that
> this means opening their web browser at least once.

I don't know of any existing protocols that would allow this to be done
in a way that would support any OpenID provider that Launchpad did.

Have the implementers of at least the GUI apps considered e.g. embedding
webkit in a GTK window without the controls etc., which would reduce the
jarring effect of opening a webbrowser?

Thanks,

James

Jonathan: yes, option 1 ("Enabling a desktop application that would handle authentication and would be another way for users to allow third-party apps to access their LP data").

Martin Owens: I believe you are arguing that some variant of option 1 might be designed in such a way to be much better than a marginal improvement from the perspective of non-programmer end-users. If so, I agree. However, I don't really matter in that regard.

As I've said before, I'm willing, even happy, to push its priority up if it gains enough steam among the developers of launchpadlib-based desktop applications.

Note that re-enabling password authentication is not an option at this time--within a week, we won't even have access to the passwords.

Here's what I think needs to happen for all interested parties.

- identify each other (all launchpadlib users for user-facing desktop GUI apps)
- advance your ideas and work with the Launchpad team and the other developers to come up with a plan that gets buy-in both from the Launchpad team (for design of the server-side changes) and the other developers (so that the Launchpad priority is raised).
- Pursue more formal buy-ins. This would be the time to get the DUX team involved, for instance.

At the moment, the only workable option I've heard is "option 1."

I'll close with some random thoughts.

Martin Owens, maybe it would be helpful to sketch out a more concrete picture of your desired user interaction, as you try to sell this idea to other devs? From my perspective, we need to have a one-time browser approval of the auth-management desktop application. Maybe an embedded browser would be possible, and an improvement from the desktop perspective over launching a browser in a separate window? Then it might be nice for a given application to be able to ask the auth-management desktop application for one or more specific permissions, so that the user has to think less (e.g., instead of radio buttons to decide what permissions the program has, there's simply a description of the requested permissions and "yes" or "no"). The importance of the auth-management application in subsequent authentication requests is that it deliver the Launchpad security descriptions clearly and authoritatively, so showing that would be essential in a sketch.

Another thought: the client-side application itself would be something that Launchpad supports, rather than develops, so whether it would be limited to Ubuntu or developed cross-platform is only something of indirect importance to me. That said, on the one hand, we are primarily about supporting Ubuntu and its development, so being limited to that platform does not strike me as a significant disadvantage in many cases. On the other hand, the client-side application could certainly be developed cross-patform, if the developers so desired.

On 30 March 2010 06:20, Gary Poster <email address hidden> wrote:
> Note that re-enabling password authentication is not an option at this
> time--within a week, we won't even have access to the passwords.

Wow. That seems like a fairly extreme implementation of openid
compared to other web services; most will still let you use a
username:password if you want. But if that's already agreed, so be
it.

--
Martin <http://launchpad.net/~mbp/>

> That seems like a fairly extreme implementation of openid
> compared to other web services; most will still let you use a
> username:password if you want.

The Launchpad Login service will still let you use a username:password, but it really has nothing to do with Launchpad--we don't administer it or have access to its data. Any more than, once you can log into Launchpad using your MySpace OpenID, we'll have access to your MySpace password.

On 30 March 2010 22:58, Leonard Richardson
<email address hidden> wrote:
>> That seems like a fairly extreme implementation of openid
>> compared to other web services; most will still let you use a
>> username:password if you want.
>
> The Launchpad Login service will still let you use a username:password,
> but it really has nothing to do with Launchpad--we don't administer it
> or have access to its data. Any more than, once you can log into
> Launchpad using your MySpace OpenID, we'll have access to your MySpace
> password.

Yes, obviously we don't want people proxying random passwords through Launchpad.

The case I'm describing is that other apps implement a hybrid of

A- one site-specific username paired with
B- zero or more openid urls from any provider, in which case you must
authenticate directly against that provider, plus
C- optionally a site-specific password - this may be backed by an
site-specific openid server but this is an implementation detail

The advantage of supporting C is that there are some cases such as
handhelds or text-mode servers where creating and then using a
site-specific password is in fact the best tradeoff for some users.
istm that is quite useful for Launchpad api clients compared to
manually generating and copying around tokens. identi.ca is a good
example of this approach, see https://identi.ca/main/login.

Perhaps this is just a transitional phase and eventually option C will
go out of fashion. And if this is already architecturally impossible
I don't think it's important to reinstate it.

--
Martin <http://launchpad.net/~mbp/>

Martin: Ground Control is now working again, I've taken to using the embedded python webkit to get it authenticated and then let the normal behind the scenes take care of the authorisation.

Glad it's working, but this is an opportunity too. If we can develop an openid provider that launchpad can tie to using the uploaded ssh keys, then ground control can actually be the enabler, it can make ssh keys and tie a user's desktop to their account and after some refinement and development manage that access.

Any third party tools would then have access via the ssh key openid provider, all they'd need is ground control's configuration as an soft account configuration dependency. (users with existing key pairs wouldn't need it) All the code is there ont he desktop side, we'd just need server support.

Fixed in stable r11850 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/11850>.

Since I've marked this fixed, I should explain what we actually did. We made it so that launchpadlib authorizes the entire desktop session at once, not individual applications. So you still have to use the web browser, but any given user will only see the web browser step once.