Launchpad should support OpenID

It looks like what we want for allowing people to authenticate against Launchpad. It seems complicated enough to support our requirements, and not much more so. I think we should run with this rather than reinvent it badly. It would be good if others can have a look over the specs to double check my opinion when people have the time.

Looks good to me, based on the high-level descriptions. I haven't fully absorbed all the details.

What URL would we be proposing as the magic URL? The obvious choice seems to be https://launchpad.net/people/$person.name. We'd "just" need to add the appropriate <link rel="openid.server" ...>. And actually implement the OpenID server, of course ;)

We should authenticate https://launchpad.net/people/$person.name and probably provide the openid interface at https://launchpad.net/people/+openid

We add the <link rel="openid.server"...> to the person page, implement the openid server, and then I can put the relevant <link rel="openid.server"...> and <link rel="openid.delegate"...> into my homepage and delegate my identity to launchpad, which will make me very happy.

Of course, openid relies on the user being sensibly logged into the authenticating site, so we should seriously prioritise getting the longer-lived sessions working before we publicise any openid service.

Daniel Silverstone wrote:

> Of course, openid relies on the user being sensibly logged into the
> authenticating site, so we should seriously prioritise getting the
> longer-lived sessions working before we publicise any openid service.

Why? You just present a login screen and redirect back when they are
authenticated.

Or did I miss or assume something I shouldn't have when I skimmed the spec?

--
Stuart Bishop <email address hidden> http://www.canonical.com/
Canonical Ltd. http://www.ubuntu.com/

Nope, but consider me, a standard "luser" of the OpenID service provided by Launchpad.

This morning, I go to view my livejournal friends list and it sends me to launchpad to log in in order to authenticate. I log in and view my friends list, all is well.

Now, at four in the afternoon, I go to look again. Livejournal decides it wants to re-check my authentication and bounces me back to launchpad. If launchpad has remembered my login, all is well, otherwise I have to log back in again, which is annoying.

Now consider I authenticate in the morning for livejournal, then a while later I attempt to use my openid on another site. By this time launchpad has forgotten because our sessions are too shoddy right now, and I have to authenticate to launchpad again.

All in all, OpenID is meant to make it easier to use the web, not more annoying. As launchpad's session handling stands right now, it'd annoy me more than it'd make me happy.

Daniel Silverstone wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/1169
>
> Comment:
> Nope, but consider me, a standard "luser" of the OpenID service provided
> by Launchpad.
>
> This morning, I go to view my livejournal friends list and it sends me
> to launchpad to log in in order to authenticate. I log in and view my
> friends list, all is well.
>
> Now, at four in the afternoon, I go to look again. Livejournal decides
> it wants to re-check my authentication and bounces me back to launchpad.
> If launchpad has remembered my login, all is well, otherwise I have to
> log back in again, which is annoying.
>
> Now consider I authenticate in the morning for livejournal, then a while
> later I attempt to use my openid on another site. By this time launchpad
> has forgotten because our sessions are too shoddy right now, and I have
> to authenticate to launchpad again.
>
> All in all, OpenID is meant to make it easier to use the web, not more
> annoying. As launchpad's session handling stands right now, it'd annoy
> me more than it'd make me happy.

Ok - so this is all a seperate issue.

--
Stuart Bishop <email address hidden> http://www.canonical.com/
Canonical Ltd. http://www.ubuntu.com/

Bug #676 is about persistent logins.

The Python library appears to have moved to http://www.openidenabled.com/openid/libraries/python

Considering Mark's recent comments on his blog ( http://www.markshuttleworth.com/archives/74 ) about needing to register to post bug reports with individual projects' Bugzillas, how come launchpad still hasn't implemented OpenID ?

As a means to allow foreign (unregistered) users to post bug reports, and to allow launchpad to be used to log into foreign bug trackers to report bugs, this would be ideal.

I know you launchpad developers are working your asses off on many high priority issues. I just want to add some weight to the request for launchpad as an OpenID server. Good for the entire Ubuntu ecosystem, especially local community efforts like the one I participate in, ubuntu-be.org. Thanks!

I think it's more important to provide a consumer than a provider. There are lots and lots of providers out there, too many actually. OpenID desperately needs consumers. If launchpad acted as a consumer it would be a good thing for OpenID. I think most people who know what OpenID is already have an account somewhere.

Provider is good, consumer is better.

I agree with Mark that an especially good use case for launchpad as an openid provider is to support authentication to loco team web sites and services. It seems particularly unfortunate to ask loco members to get not only a launchpad id, but also to sign up with the local team's web site in order to modify content, post pictures, etc. I'd love to see, e.g. the Colorado Local Team be able to accept launchpad openids.

Once we do that, it would also be nice to be able to query launchpad to find out if the user is a team member. Is there any simple API to do that, or would we have to scrape the +members page?

To find out the member of a team, you can use the RDF for a team, e.g.: https://launchpad.net/~bzr/+rdf

I'd like to bump this again and get it up the tree for consideration.

As a developer of a third party project, I intend to use OpenID as the logon mechanism - since it means I don't have to track passwords. It is pretty straightforward in Rails. However if I use launchpad bug tracker then that is another logon that my users need before they can tell me what the problem is. it would be really useful to unify the two.

Something simple like associating an OpenId with an account would do, as long as the launchpad URLS responded correctly to an option like ?openid_url=http://openid.provider and skipped the login procedure.

I've been remiss in updating this bug. My apologies. We are actively looking into this feature request.

Hi, I wanted to give all you subscribers some additional details, especially since many of you pinged me today on irc.

We're working towards Launchpad providing OpenID but we don't want to announce anything official until we have something that we can offer everyone to use.

We're starting with some evaluations. Specifically, we've been working on connecting Launchpad to services that Canonical is directly involved in. We want to ensure our code is robust and we also want to gradually scale up it's usage and evaluate it's performance.

The next stage is allowing people to use their Launchpad OpenID with any OpenID enabled services. We expect to be announcing that before the end of the year, but can't say exactly when as we are still performing the above mentioned evaluations.

I just want to support samy idea, that right now, we need a consumer.
Lets beta/priv test it and then work on a provider.

As I've said before, I think launchpad as an openid provider would be helpful for use by relatively low-risk sites like bug trackers and loco team web sites.

But note the many associated security and privacy risks, as documented at
by Stefan Brands in "The problem(s) with OpenID"
 http://www.idcorner.org/?p=161

Launchpad should test and document ways to lessen the risks of phishing and of cross-site scripting attacks and note the privacy issues. And I don't see much benefit in having launchpad accept openids from other providers since the security exposure can be pretty big.

And launchpad may also want to consider being a provider for much more secure systems like InfoCard for riskier scenarios

 http://www.identityblog.com/

Also, see a proposal for Ubuntu supporting the client side of InfoCard at
  https://wiki.ubuntu.com/IdentitySelector

"And I don't see much benefit in having launchpad accept openids from other providers since the security exposure can be pretty big."

What does this mean? I've read Stefan's article, I'm familiar with the issues, I want to know what "security exposure" you are concerned with in the Launchpad application in particular. I'm a little confused, because you start your comment by saying it would be "helpful for relatively low-risk sites like bug trackers", and my primary use of Launchpad so far has been as a bug tracker.

On Wed, Sep 12, 2007 at 09:31:38PM -0000, Kevin Turner wrote:
> "And I don't see much benefit in having launchpad accept openids from
> other providers since the security exposure can be pretty big."
>
> What does this mean? I've read Stefan's article, I'm familiar with the
> issues, I want to know what "security exposure" you are concerned with
> in the Launchpad application in particular. I'm a little confused,
> because you start your comment by saying it would be "helpful for
> relatively low-risk sites like bug trackers", and my primary use of
> Launchpad so far has been as a bug tracker.

Ahh - yes that would be a common experience - thanks for the feedback.

But launchpad can be used for far more than bug tracking - e.g. users
can register new pgp and ssh keys to be used for software
modifications, which I assume could lead to trojan software being made
available in repositories. Administrators can change the membership
of security-related teams, and there are probably other similar
exposures (I'm no launchpad expert though....)

Any site that accepts openids needs a policy and method for deciding
which openid providers to trust for what. In the use case I'm most
interested in it is easy - I can configure my own loco team's web site
to only trust launchpad for openid.

Even for bug tracking you want to know if you can trust the email
address, so you can reliably send bug updates without being accused of
spamming. Otherwise what is to prevent someone from authenticating
with a fake openid and spamming their favorite target?

Is there a reliable trust clearinghouse for openid providers? Where
e.g. launchpad could do some lookups and determine if the provider
could be trusted to provide reliable email addresses from folks who
wouldn't spam the bug reports? I suppose in that case launchpad could
allow users with openids to do low-risk stuff, but that would increase
complexity and thus risk significantly, I bet.

I suggest verifying email addresses and OpenID identifiers independently. An OpenID provider is really only authoritative for the OpenID identifier; any other data you receive from it is really only a convenience to save the user from having to re-type it.

I'd argue against relying on a clearinghouse for OpenID providers. You trust the developer to manage their SSH key and their GPG keys, why not trust that they have sane management practices for their OpenID as well?

On Wed, 2007-09-12 at 23:21 +0000, Kevin Turner wrote:
> I'd argue against relying on a clearinghouse for OpenID providers. You
> trust the developer to manage their SSH key and their GPG keys, why not
> trust that they have sane management practices for their OpenID as well?

I agree here.

In the end the people who have PGP keys already know about security and
are quite aware of phishing. Even more so are the people who actually
know about SSH keys and how to manage those.

Everyone can get bitten by security and each and every system is
vulnerable to some sort of attack, especially to social attacks. We
shouldn't discriminate a system because the users can make mistakes.

Even still i see the problem with PGP and SSH keys. Maybe something like
a low security / high security model could be established. You can log
in to low security mode with your OpenID where you are unable to add SSH
and PGP keys or modify e-mail addresses (possibly not be able to edit
user details at all) but you would be able to file bugs and otherwise
work with launchpad. For high security mode you would still have to log
in with a password.

That would still bring some the benefits of both worlds.

- s

--
Sami Haahtinen <email address hidden>

On Thu, 2007-09-13 at 04:41 +0000, Sami Haahtinen wrote:
> Maybe something like a low security / high security model could be
> established. You can log in to low security mode with your OpenID
> where you are unable to add SSH and PGP keys or modify e-mail
> addresses (possibly not be able to edit user details at all) but you
> would be able to file bugs and otherwise work with launchpad. For high
> security mode you would still have to log in with a password.

I agree that it's a good idea for the application to treat user details
with special care, especially credentials like e-mail addresses which
can be used to re-claim your account, or public keys which may grant you
access elsewhere. However, if there is a password that I use _only when
adding ssh keys_, which is to say, once a year on average, I am _never_
going to remember it.

I believe this sort of model is what extensions like the OpenID Provider
Authentication Policy Extension[1] are meant to work with, but I'm not
sure if that's quite the right thing to address the concern here. Nor
am I sure if this is the proper forum to debate the merits of various
OpenID extensions.

1:
http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-01.html

I must say I'm against any kind of descrimination.
So you trust the user is able to keep is password secure but not is OpenID?
I use it 'cause I want to get reed of my passwords, and logint to my OpenID with a SSL cert via HTTPS (SSL) so its much more secure then me entering
my passord in most sites that I use.

On Fri, 2007-09-14 at 20:17 +0000, BUGabundo wrote:
> I must say I'm against any kind of descrimination.
> So you trust the user is able to keep is password secure but not is
> OpenID?
> I use it 'cause I want to get reed of my passwords, and logint to my
> OpenID with a SSL cert via HTTPS (SSL) so its much more secure then me
> entering
> my passord in most sites that I use.

I think the main concern with OpenID is that you need one slip and you
loose your OpenID account and since most providers keep logs of sites
you log in to, it is quite straightforward to see where you could keep
important data.

As with single passwords one would have to guess which sites the user
visits and hope that those sites use the same passwords.

Problem is the same, but the scale of the damage is worse with OpenID.
While it is true that it isn't really a problem in the OpenID protocol
itself it poses a security problem to launchpad users. A single
compromised account could potentially lead to catastrophic scenarios.

Personally I use SSL login and verisign OpenID helper for firefox which
makes things quite safe for me (it makes me login before i submit the
form). This isn't the case for everyone and sadly it takes just one..

Many sites will have to do this kind of evaluation for the level of
trust for OpenID. OpenID is a convenience thing after all.

--
Sami Haahtinen <email address hidden>

Launchpad as an OpenID provider doesn't open any security problems. Go for it.

I'd very much like to be able to see a consumer implementation too, but IMHO the provider authentication policy extension documents a sufficient level of additional trust.

In fact, that would allow us to implement stronger security in launchpad, without ourselves handling the nitty gritty details of mailing yet another one time password generator keyfob to everybody -- after all, people like me, who want/need the additional security, already have one. ;-)

For the record, the provider authentication policy extension only has value when there is a pre-existing trust relationship between the relying party and OpenID provider.

I can set up my own OpenID provider and have it assert that it authenticated me with physical two-factor authentication when it does not in fact do so. Any site that acts on that assertion without knowing the details of my OP is broken.

That isn't to say that the extension is useless -- If I have a reason to trust the OP, then it makes a lot of sense to act on the PAPE information where appropriate.

Oh dear. MPT, what dark hole did you dig that python library URL out of? I thought I scoured all references to that site off the web long ago. http://openidenabled.com/python-openid/ , please.

I didn't add or change the URL, just the text around it.

For the community: Our OpenID implementation that we are testing is based on OpenID 1.1. We've decided to upgrade to OpenID 2.0. When we open up OP services, we'll do so as a 2.0 OP. We're still on track for December/January for a limited pilot. We will most likely use the Launchpad Beta Test team during the pilot. If you are so inclined, you may join this team now. Keep in mind that beta testers run our cutting-edge code and it may has some rough edges. If you are interested, please see https://help.launchpad.net/JoiningLaunchpadBetaTesters

Joey, thanks for the good news.

What is the launchpad policy on reuse of launchpad ids? It is easy to change your id now, but I'm not sure if you can change it to one that someone else has previously used and then dropped. I assume that in such cases launchpad remains internally consistent.

But obviously in a world which lets people login to other sites via openid, there is a much bigger risk that those openids will end up on an Access Control List (ACL) out there somewhere which doesn't get updated when the id changes hands.

So if launchpad ids can be recycled now, will that have to change? At least for ids that have been used for openid login?

Neal: this is something that we've been considering, and will need to address before general availability.

That said, it probably isn't that great an idea to change your user ID much after you've started using Launchpad because it breaks existing bookmarks.

The general availability of Launchpad as an OP (provider) to the community is now being tracked as https://blueprints.edge.launchpad.net/launchpad/+spec/ssov2-open-op

Hi Gang,

Pursuant to my previous post I wanted to let you all know that due to the holidays and our upgrade to OpenID 2.0 (which is in progress this cycle), we're delaying general availability of Launchpad as an open OP until our March release. We are doing this so we can further test the new code before it goes live to the world. We are still considering having the Launchpad Beta Test team beta test this functionality but have not decided on an exact date yet. I'll keep you posted.

Joey

hey Joey, not even and Alpha we could try??
Even Google's Blogger now allow OpenID.

--
BUGabundo :o)
(``-_-´´) http://Ubuntu.BUGabundo.net
Linux user #443786 GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net

"OpenID for Ubuntu Sites" is getting a lot of attention on Ubuntu brainstorm (http://brainstorm.ubuntu.com/idea/9/).

Can someone give an update on progress, and when OpenID support is likely to land in Launchpad? (ok, bad choice of words!)

Hi Folks,

A little update for you on OpenID.

We've upgraded internally to support OpenID 2.0 as I previously indicated we would do. We're preparing to announce a beta test of OpenID as early as next week. There are some loose ends we'd like to correct first. One is that we currently expose a user's account name as the OpenID url for 1.1. We'd like to replace that with a more private ID number. This would affect only a few sites that I know off (e.g. wordpress plugin, pibb.com). The related effort is to then display a user's OpenID URL privately on their person page. (e.g. https://launchpad.net/~rinchen ) such that only the user will know their OpenID URL. For OpenID 2.0 sites, a more generic login.launchpad.net url will be available in the future.

I've created a stub in the help wiki which we'll complete once we have all the user visible items in place: https://help.launchpad.net/openid This will be included on the beta announcement so you don't have to bookmark it.

There are more things we'd like to do with OpenID but don't have room to schedule them at this time. We'll look at these again around the July timeframe to see if we can fit them into the schedule.

For a list of all of the OpenID related bugs (most of which are in fact enhancement requests), you can search on the openid tag:

https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=openid

well, not sure if it is a bug, but it doesnt work on this set of tests:
http://openidenabled.com/resources/openid-test/diagnose-server/

Hi,

On Tue, Mar 25, 2008 at 11:55 AM, Fernando Pereira <email address hidden> wrote:
> well, not sure if it is a bug, but it doesnt work on this set of tests:
> http://openidenabled.com/resources/openid-test/diagnose-server/

This won't work for anyone unless you're in a special group until we release it.

It currently does not respond with the OpenID 2.0 format (but that does work).
It currently does work with OpenID 1.1 except for checkid intermediate
and I've asked about that.

Thanks for the pointer.

Joey

On Tuesday 25 March 2008 18:41:41 Joey Stanford wrote:
> This won't work for anyone unless you're in a special group until we release it.
> Joey

Can I be on that 'alpha' group so I can do a few extra tests, including delegation tests, that I already currently use?

--
BUGabundo :o)
(``-_-´´) http://Ubuntu.BUGabundo.net
Linux user #443786 GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net

Hi,

> Can I be on that 'alpha' group so I can do a few extra tests, including
> delegation tests, that I already currently use?

As mentioned above, we'll be putting this into beta very soon (as in,
in the next few days). If you join the beta team, you will have
access to this once we turn it on. We'd really appreciate any
feedback on the feature once you get to use it.

Thanks,

Joey

On Wednesday 26 March 2008 15:24:02 Joey Stanford wrote:
> If you join the beta team, you will have access to this once we turn it on.
> Joey

I'm on LP beta team.
I'll reply as soon I have the time to give it a try.
Most of the tests, will be done by direct tests to the login portal, and delegation and login on OpenID enable sites (blogger, WP, pibb, etc)

--
BUGabundo :o)
(``-_-´´) http://Ubuntu.BUGabundo.net
Linux user #443786 GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net

The beta announcement for OpenID was sent out today. Yippee!

it seems to works only on Production.
No edge not even on staging.
I've made a few test and I'm able to login

On Wed, Apr 2, 2008 at 12:24 PM, Fernando Pereira <email address hidden> wrote:
> it seems to works only on Production.
> No edge not even on staging.
> I've made a few test and I'm able to login

Thanks. We're aware of both issues from reports today. It seems it's
a configuration issue and we should have those fixes in tonight and
those systems will update overnight. When we look at all of these
systems, we can see the URLs which is why it didn't come up in our
testing.

=Flock is a social web browser, a GPL fork of Firefox integrated with many social sites like Flickr, del.icio.us, etc. It also has tools for writing your blog.=
a perfect "open-id" webbrowser?

A quick update on this topic. Based on the feedback we've received, it's clear that most users don't like the current implementation's 1.1 identity URL. Specifically, they want something easier to remember than https://login.launchpad.net/+id/xxxxxxx for 1.1 RPs. We used this format originally because it helps to maintain anonymity. However many 1.1 RPs do not seem to respect this and publish the URL to the public. Additionally, users want to have an OpenID that they can remember. So, we're working on a proposal for a different method. Currently we're thinking about this format: https://id.launchpad.net/NNN/somename where NNN is a random number. So my URL might be https://id.launchpad.net/911/rinchen and Francis' might be https://id.launchpad.net/201/flacoste.

Because users of Launchpad can change their usernames, using only a username in an identity URL (e.g. https://launchpad.net/~rinchen) is not sustainable. Identity URLs should remain constant to preserve the identity. If we didn't, it's possible for me to change my username from "rinchen" to "joey40" and someone else can then register (or rename) as "rinchen". Thus when they would go to OpenID sites, they could enter their identity URL, which was my old one (e.g. https://launchpad.net/~rinchen) and gain access to my accounts. This is why our current discussions are around having a random number in the 1.1 identity URL. For 2.0 sites, login.launchpad.net would remain the universal URL for everyone.

Joey

On Thursday 15 May 2008 00:11:58 Joey Stanford wrote:
> We used this format originally because it helps to maintain anonymity. However many 1.1 RPs do not seem to respect this and publish the URL to the public.

I read the bug report here it stated the use of anonymous OpenID urls, but I still don't get it...
I have no prob stating that my OpenID is http://id.BUGabundo.net, so why should I keep this a secret?

--
BUGabundo :o)
(``-_-´´) http://Ubuntu.BUGabundo.net
Linux user #443786 GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net

BUGabundo: the original reasoning was that by default, the only information disclosed would be that you own the ID: any further information disclosure would be under the user's control. So the idea was to have identity URLs that did not disclose information about the user.

The anonymity angle has turned out to be less useful that we originally thought it might, and has the downside that users have trouble recognising their own ID. Even for sites that don't show your identity URL to other people, they often display it on the profile page, and it is useful if that is recognisable.

That said, we still feel it is important that a user's identity URL be immutable (since changing the URL cuts you off from accounts on RPs you've previously logged in to) and never recycled (since that would let someone else assume your identity). The proposed scheme attempts to address these concerns.

On Thursday 15 May 2008 14:06:16 James Henstridge wrote:
> That said, we still feel it is important that a user's identity URL be
> immutable (since changing the URL cuts you off from accounts on RPs
> you've previously logged in to) and never recycled (since that would let
> someone else assume your identity). The proposed scheme attempts to address these concerns.

With the immutable urls I agree, of course, but i dont see an easy way....
Its not appiling for an user to change an username, for what ever reason, and then still see it on his/her OpenID account at LP.
Can the old username and new username url/id be linked or redirected in some way?
I'm not sure if OpenID supports the likes of 301 http redirects.

--
BUGabundo :o)
(``-_-´´) http://Ubuntu.BUGabundo.net
Linux user #443786 GPG key 1024D/A1784EBB
My new micro-blog @ http://BUGabundo.net
ps. My emails tend to sound authority and aggressive. I'm sorry in advance. I'll try to be more assertive as time goes by...

OpenID relying parties do follow redirects, but not in a way that helps here.

Say you used http://example.com/bob/ as your OpenID. Each site you logged in to would record this URL as your user identifier.

Now lets say you decided to use http://example.com/robert/ instead so set up a redirect from the first to the second. Now when you log in this new URL will be recorded. Furthermore, the redirect means that if you enter the old URL the new one would be recorded. This effectively cuts you off from accounts on sites you used before setting up the redirect.

Things will work if you redirect from the new URL to the old URL, but that is probably not what you want: if sites display your OpenID, it will show the old URL.

Re concern about security implications of acting as a consumer:

OpenID providers are available offering multi-factor authentication and effective measures (Verisign's SeatBelt browser plugin, Vidoop's completely non-password-based approach) to prevent other attacks; a security-conscious user can have better security *with* OpenID (and a provider offering such features) than accessing launchpad *without* it.

Maybe we should split off a separate bug for being a consumer?

I would like that Martin

Martin, BUGabundo: Bug #210943 "be an openid consumer" is already existing.

Nice idea

Fixed in RF 7303.