Introduction and OpenID

[Patrick Uiterwijk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello ReviewBoard developers,

I am planning to contribute to reviewboard soon, and would like to introduce myself and what I am intending to contribute.

I am Patrick Uiterwijk, currently a full time student in Computer Sciences, and a Fedora contributor.
Recently, Stephen Gallagher hired me as an intern for Red Hat Inc. to work on ReviewBoard.

The first idea we were thinking of having me implement, is an OpenID relying party implemention for ReviewBoard, so that users can login to a reviewboard instance with OpenID, and thus reducing the number of passwords users have to remember.

One of the reasons I was assigned to this is that from my role of Fedora Infrastructure member, I have recently built the new Fedora OpenID provider (FAS-OpenID), so I have quite some experience with OpenID.

We had two ideas on how to implement OpenID in ReviewBoard, each with their own pros ans cons:
1. A hybrid system, where users can login with the traditional username/password, and have the OpenID implementation as an addition. You could also hide the username/password fields, and have OpenID be the only (visible) authentication system. This would probably be easiest to implement, as it would only impact the web-based authentication and
registration procedures.
2. Implement a new seperate authentication provider for OpenID. This would probably make a better user experience, but this would make authentication to the API harder, as users will no longer have a password at all. We will have have to implement some mechanism to retrieve an authentication token asynchronously (the user will have to get a token or something from the website, after which they can use that in the Web API). Do you have any idea or preference on how to accomplish this?

I would like to hear your opinion on these ideas, and look forward to contributing.

With kind regards,
Patrick Uiterwijk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBCgAGBQJRh8CXAAoJEIZXmA2atR5QkbkP/ialzLo9rvB17fg7K95gj+iv
D3mG4JSpIMOrv55ov66wk1GA/ky2Zdw0DXbrIN6dBdRCqsxPId+b90HpK1GLMlsD
kAE9NG2gHdkyLg0b6f3h+SOg+9jvv04oIlIi+OGvmlA7lV52Uh1rH5R00n9YaRU7
3nKmgUNYgVOzBV/Djf2WvZM37jN+hX9Lcxv+WCVAz4Tox8Ip2RYvy3qlFQ7gJZOs
ILvwxZNAZ0o5bCZoAZoRyJC7KVr5kKhGxSZOtbmQVM/53DLJxMJ1OBEhiWh77vfb
vhjiUeM5a1gVYSlPhdxy5PZFk/efr3wF6lgdJRG7cfh7DQf3WYCJ3kpcj50GQUKy
eY8FJD9/CiMmNa+NikCcV9sxcYjTx6XHToE8mCazClhiHupupeOiI+nyXhBfVlh9
+WbVx5J9OOHru4PVjucPceV3P4+UCinWYsJ63becpG61DIlfwq1bzO53aCm3KblL
klzF6x+J9yJLDiU2RKFL88wNrFVKNC3MjdjmT0KtW50fzMvbpFmyTmkTcg+Syvb6
BRgCCPPVpLV8Dcs7nWtaEpKHCvqcWvkPW5WcMlfwjZX2nH1lwZry9YPowtz8MK7m
MXLIYw/uBtIbOvV4wonf4XBXiUPl0WVkSx0DcAiisZzNyozB/Aqc9sMXQFHh/1fg
N3k+YEh2ckbVvjZ3aC72
=SGWj
-----END PGP SIGNATURE-----

[Stephen Gallagher]

As Patrick says, we're looking at enhancing the way that Fedora-based
open-source projects interact with Review Board. One of the major
issues we've had in the past was with how to maintain integrated
identities with the Fedora Account System. Previously, we had
developed a Django identity plugin, but that was very fragile and
overly unsuccessful (also causing many other issues in the deployment).

Recently, Patrick implemented a powerful new OpenID provider for the
Fedora Infrastructure, which is now being treated as the default
interface for integrating new services into our environment. Over
time, we're going to be migrating most build and development services
over to OpenID.

With this in mind, we'd like to work closely with the Review Board
team to get this added.

As Patrick notes, we have two questions we need discussion on before
we dive deeply into implementation as noted by Patrick above.
Personally, I'm inclined to say that we want to build this as a
complete authentication provider, and as such we need to identify how
we will handle the creation of and maintenance for API access tokens.
This is necessary (for the benefit of anyone finding this thread later
who isn't an expert on Review Board) in order to allow external
applications owned by a user to interact with Review Board on that
user's behalf. The most obvious example of this case would be the
RBTools package, which uses the web API to submit reviews. Since
OpenID accounts would not have a password (and because OpenID requires
a fully featured browser to establish identity), we will need to have
another mechanism to authenticate the clients.

Suggestions are most welcome.

[Christian Hammond]

Hi Partrick, Stephen,

I'm really happy to hear this! That's fantastic.

OpenID would be a great addition. I've been starting to think about this more and more lately. Let me give you my initial thoughts on this, and we can discuss them further. I have a lot of thoughts, so this may appear as a jumble.

So first off, let's briefly discuss the web API issue. Regardless of the method we choose, something I want to see added to Review Board is the ability to have revocable, per-user API auth tokens that they can see in their account settings and use for scripts without providing a password. I'm thinking more for automation scripts than RBTools, though, but I think it's valuable. So let's say that that's a goal (whether for your work or for ours) regardless of the method we choose for OpenID.

Okay, so today for our auth system, we have auth backends that know how to speak to some system to verify user credentials. They are standard Django auth backends (with some additional metadata). When we verify a user's credentials, we first try the configured auth backend, and then fall back to the standard (database-backed) auth. This all works well when you're just dealing with a username/password, but not for anything more complex.

I kind of see providers like OpenID sitting on top of all that. On a login page, you can either log in with existing stored credentials, *or* your OpenID account. So that's #1 in your list above, I think.

The reason I like a hybrid/layered approach is that it gives us more room for expansion.

Today, we're talking OpenID, but there's other systems to consider. There's SAML systems, like VMware's Horizon. There's Mozilla's Persona. Ideally, we'd be able to start supporting login with these systems as well. Ideally, the admin wouldn't have to choose which are supported. For example, on RBCommons.com, we could support all the above, and still let people log in with their existing accounts.

That also solves the problems of existing installations, and authenticating to the web API, I believe.

So, OpenID (et al) would be a convenience/alternative, but not a replacement, and could co-exist with other similar auth implementations.

Does that make sense? (I'll admit, I'm a complete newbie when it comes to OpenID and typical implementations, so set me straight.)

Christian

-- 
Christian Hammond - chi...@chipx86.com
Review Board - http://www.reviewboard.org

Beanbag, Inc. - http://www.beanbaginc.com

[Patrick Uiterwijk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Christian,

It's great to hear you are so enthusiastic about this!

Your ideas make sense, and that was indeed what my first idea meant.
So the way we could show this to the user to configure, is by adding a new section to the "User Preferences" page with authentication options, where we could put "Change password" and also any way to change the connected OpenID account etc?

Also, me and Stephen also got the idea of something like a revocable "API Token" that every user has.
This could also be listed under "authentication options", possibly with a "regenerate" button?

Also, I was planning on integrating OpenID with the registration process, as OpenID can provide several details on the user like username, full name and email address, thus providing details the user does not anymore have to enter.
This would bring up one more choice for debate though: if we accept OpenID login for registration information, would the user still be required to enter a new password for themselves?

In the mean time, I will try to start with programming such a hybrid system.

Patrick

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBCgAGBQJRiPZyAAoJEIZXmA2atR5Qb84QAKiQMnUnNbGWdOJ/NTIJf9o+
BEBw0g5ROH5ZijXGxzG4B8wLxOi0Z/dS6htYCmdwwX3iSQDDunG0zpZbXkrEYZuS
fqKMJq7Hn5dVp6cQ72pIFW3PrkrxAAJgySearrtoZAeM9pbYLS7qe0NX9XjvEzz8
GYx4vM/V6c+Rbjf0AP9isTZmvoLpV3NByxBIXui7wqbZaitaHfCL9padaAwxbHOG
OXCvgQUeThXDliYYjt46kherzGD/f+RksSQl333BxuCgqKnSpOJiksesNIFVwPAm
TCOOtiBOJrl48IzuJUI3ggW5QlUEao0qLXgADKVfeVB1vQCPpzX1WyKz9EZ4DS2L
WilDyqiVM4frrdEMcHn2NZ4n1PmWh5I/GTp9CZsSKjMU2qFJM7Wtjb1orlF5jSOW
+J1OvdAyhAcGL/A45E5KjM9+GHNy3zhkW/T3PsCkj9/G1lT18vpexiavGMe3ml3m
VPfIrqcReFl6Jp2zE/C4seHaQAB2FcmTCCsnHdcsQFGC8S1997DMko4H2KRoAeMi
ACX8ze3/SCs2mDzd6F+smS7ztSJ/ktijUXpyBKXmfFpf6k/oPBxBS/3S05gvda10
SEdxc/udEW1AmHGhK42uuzXUIamG20uFBD09I448fMRMhElZdyN7MugzLfzV4/Ip
VGg9GB9SeoDojbu9WhJO
=h8sK
-----END PGP SIGNATURE-----

[Christian Hammond]

Yep, both make sense.

 

Also, I was planning on integrating OpenID with the registration process, as OpenID can provide several details on the user like username, full name and email address, thus providing details the user does not anymore have to enter.
This would bring up one more choice for debate though: if we accept OpenID login for registration information, would the user still be required to enter a new password for themselves?

I'm not sure what the right answer is here... I've used systems that have asked for a password after, and others that haven't. Our other auth backends (LDAP, NIS, Active Directory) don't ask for one, since we retrieve it remotely, and I think that's a good precedent. The problem then becomes the API.

If we have API tokens, I'm fine with not requiring the storage of a password. We do need to figure out the workflow with RBTools then. Today, it asks for a login/password. Perhaps the password just takes the API token in this case?

Christian

[Stephen Gallagher]

If the password takes the API token, what do we do for identity?

Do we want to be able to just pass --token and have the API on the
Review Board side translate that into the user account? This would
require uniqueness guarantees for the API, but that's pretty simply solved.

The other option is to require the use of the OpenID URI as the username
and the token value as its password. This is probably the simplest
method to implement, since it won't require any changes to the client at
all. At this point, though, I'm not sure whether we're any better off
than just instructing the user to set a ReviewBoard password after the
first registration. So maybe that's the best choice (and give them the
option to have the password generated for them, since they wouldn't need
to use it for logging in, just for the post-review tool.

So here's my thought on this procedure:

User logs in the very first time using OpenID (I'll use the Fedora
Account System aka FAS as the example).

The redirect to FAS occurs, the user logs in there in an appropriate
manner, and then elects to grant permission for their user information
to go to ReviewBoard.

FAS OpenID then redirects back to ReviewBoard's registration page, with
any eligible fields populated by the OpenID data. The user is prompted
to enter a password or (the new part) click an Ajax button that unmasks
the password field and creates a new random password (and adds a note
that the user should record this password for later use with RBtools or
other Web API client tools).

User logs in and can use ReviewBoard.

User logs out, then logs in with OpenID again. This time, the redirect
back from FAS should go directly to the dashboard. (The user should not
need to enter the password for access to the Web UI at this point).

Ok, those are my thoughts: commencing poking holes in it in 5... 4...

[Christian Hammond]

So no matter what, we need a User entry server-side, and while this can be set to not have a stored password, we do need a valid username. So that's a requirement. A URI wouldn't be valid, and I don't think we can adapt things to make that valid. Wouldn't make sense. So, let's assume a standard username must be chosen at some point by the user.

Given that that's a requirement, the above case I mentioned with RBTools means that identity is solved with the username. The password field could then be matched against either their password (if any standard auth backend can auth against it), or their configured API token.

The API token would be a UUID, and we can ensure uniqueness on the database level. So I'm not worried about that. Still, since a username is required, the uniqueness of the API token doesn't really matter.

I'd like the API token ton exist regardless of OpenID usage, since it's a useful thing. So, the part above about unmasking the password and telling them to record it probably isn't necessary. They can look up the API token in their account settings later, and regenerate it whenever they need to.

Otherwise, I think the method you outline above sounds sane to me. I'd love to hear other people's opinions on this as well.

[Stephen Gallagher]

On 05/09/2013 03:59 PM, Christian Hammond wrote:
>
> So no matter what, we need a User entry server-side, and while this
> can be set to not have a stored password, we do need a valid
> username. So that's a requirement. A URI wouldn't be valid, and I
> don't think we can adapt things to make that valid. Wouldn't make
> sense. So, let's assume a standard username must be chosen at some
> point by the user.
>

What about a URI would be invalid? Let's assume (for the moment) that
we're able to drop the HTTP:// portion. Is the remainder acceptable? I
don't know how I feel about making them choose a username after they've
logged in via OpenID. I've seen other services where they just
internally keep the OpenID URI (minus the locator portion) as the
username. It's one fewer thing for users to remember, as well.

> Given that that's a requirement, the above case I mentioned with
> RBTools means that identity is solved with the username. The password
> field could then be matched against either their password (if any
> standard auth backend can auth against it), or their configured API
> token.
>
> The API token would be a UUID, and we can ensure uniqueness on the
> database level. So I'm not worried about that. Still, since a
> username is required, the uniqueness of the API token doesn't really
> matter.
>
> I'd like the API token ton exist regardless of OpenID usage, since
> it's a useful thing. So, the part above about unmasking the password
> and telling them to record it probably isn't necessary. They can look
> up the API token in their account settings later, and regenerate it
> whenever they need to.
>

Well, my main concern there is that if the token is going to function
effectively as a password, we probably don't want that to be stored
unencrypted in the database. So if a user doesn't remember the token, we
probably will want the approach to be that they have to regenerate it
(thereby invalidating their current clients' usage of the old token).

Thus, I suggested the unmasking approach as the way to deal with it at
creation time, while keeping it secure in the DB.

[Christian Hammond]

On May 9, 2013, at 1:14 PM, Stephen Gallagher <ste...@gallagherhome.com> wrote:

> On 05/09/2013 03:59 PM, Christian Hammond wrote:
>>
>> So no matter what, we need a User entry server-side, and while this
>> can be set to not have a stored password, we do need a valid
>> username. So that's a requirement. A URI wouldn't be valid, and I
>> don't think we can adapt things to make that valid. Wouldn't make
>> sense. So, let's assume a standard username must be chosen at some
>> point by the user.
>>
>
> What about a URI would be invalid? Let's assume (for the moment) that
> we're able to drop the HTTP:// portion. Is the remainder acceptable? I
> don't know how I feel about making them choose a username after they've
> logged in via OpenID. I've seen other services where they just
> internally keep the OpenID URI (minus the locator portion) as the
> username. It's one fewer thing for users to remember, as well.

Usernames are typed a lot on Review Board, and often map to some existing identity of theirs. A company-standard username format. Some known identity on GitHub or another project.

I'd personally like to use OpenID to log into a server, but I still want "chipx86" as my username. I also don't want to see somedomain.com/somepath/user all throughout the dashboard and review request and autocompletes. Takes too much space, and is too annoying to read. It's a detail that I, as a user of the system, shouldn't have to see.

Even if other services make use of the OpenID URI, I don't feel it's a good match for Review Board.

>
>
>> Given that that's a requirement, the above case I mentioned with
>> RBTools means that identity is solved with the username. The password
>> field could then be matched against either their password (if any
>> standard auth backend can auth against it), or their configured API
>> token.
>>
>> The API token would be a UUID, and we can ensure uniqueness on the
>> database level. So I'm not worried about that. Still, since a
>> username is required, the uniqueness of the API token doesn't really
>> matter.
>>
>> I'd like the API token ton exist regardless of OpenID usage, since
>> it's a useful thing. So, the part above about unmasking the password
>> and telling them to record it probably isn't necessary. They can look
>> up the API token in their account settings later, and regenerate it
>> whenever they need to.
>>
>
> Well, my main concern there is that if the token is going to function
> effectively as a password, we probably don't want that to be stored
> unencrypted in the database. So if a user doesn't remember the token, we
> probably will want the approach to be that they have to regenerate it
> (thereby invalidating their current clients' usage of the old token).
>
> Thus, I suggested the unmasking approach as the way to deal with it at
> creation time, while keeping it secure in the DB.

We just spoke about this a little in IRC, but the API token would be limited to the API. You wouldn't be able to log into the site with it.

Any user session that uses an API token for auth would be strictly limited to the API. You couldn't use that cookie to, say, log into your dashboard, or reset your password.

There are many services out there that expose an API token in the account settings, and allow users to just reset it if need be. We should scrutinize the security of this, but I don't think we're doing something wildly new. It's worth researching what others are doing and what are considered best practices here.

[Christian Hammond]

On Thu, May 9, 2013 at 2:14 PM, Christian Hammond <chi...@chipx86.com> wrote:

On May 9, 2013, at 1:14 PM, Stephen Gallagher <ste...@gallagherhome.com> wrote:

> On 05/09/2013 03:59 PM, Christian Hammond wrote:
>>
>> So no matter what, we need a User entry server-side, and while this
>> can be set to not have a stored password, we do need a valid
>> username. So that's a requirement. A URI wouldn't be valid, and I
>> don't think we can adapt things to make that valid. Wouldn't make
>> sense. So, let's assume a standard username must be chosen at some
>> point by the user.
>>
>
> What about a URI would be invalid? Let's assume (for the moment) that
> we're able to drop the HTTP:// portion. Is the remainder acceptable? I
> don't know how I feel about making them choose a username after they've
> logged in via OpenID. I've seen other services where they just
> internally keep the OpenID URI (minus the locator portion) as the
> username. It's one fewer thing for users to remember, as well.

Usernames are typed a lot on Review Board, and often map to some existing identity of theirs. A company-standard username format. Some known identity on GitHub or another project.

I'd personally like to use OpenID to log into a server, but I still want "chipx86" as my username. I also don't want to see somedomain.com/somepath/user all throughout the dashboard and review request and autocompletes. Takes too much space, and is too annoying to read. It's a detail that I, as a user of the system, shouldn't have to see.

Even if other services make use of the OpenID URI, I don't feel it's a good match for Review Board.

So I know it's fun to implement code from scratch, but I'm reading a lot of good things about django-allauth, which is a new but growing Django app for doing integration with OpenID (and presumably able to do other) services. Provides a lot of the base infrastructure we can build upon.

Would you mind looking into this and seeing if it would be a sufficient base? I'd rather use something that's going to have a community backing it than to maintain all the services ourselves if we can avoid it.

[Patrick Uiterwijk]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Christian,

I was already planning to look at current implementations for OpenID for django, as there are quite a lot already so far.
A quick search returned with at least these results:
- - django-socialauth
- - django-social-auth
- - django-socialregistration
- - django-openid
- - django-authopenid

And quite some more.

So I will first look into some of those (including django-allauth) to find which of those is easiest to implement and has the required features.

Thanks for refering me to the -allauth version.

Patrick
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)

iQIcBAEBCgAGBQJRkfpVAAoJEIZXmA2atR5QoNwQAJASxP0WacjBCaFCfHEgJV+S
Vt71E8RM2ioZMRGX5bUJgiBW35rS/w1yMmVuk63waG8rLpqmKH6xi+EZhdi7C1UM
Loh2C0t3b5V5CSDv8D8/nEwXinr9BtE52cCL3Bsai4gPE4N87oE1AnxDEzJR1e+f
/B15jPKOmor1oSuQIQEiIaRuXtix+CJESSl5/jdX8qB+TLw+6aLDDkjh7YC0oewA
Fcaa4bsj/rMLkWXE4oOXmdeMH7jsZ9/r/LLqJK9/ZnNBz3YeKAzRXgjcU1zRKiVg
8OSVxAWkpTiuGmp5xEk+y26JMq2Up76itF2b4+kGXPZ8Ozagizy+atASiNA0atDT
C/Lunm/fYp4jpbL/c2TPdFQ7YGpqy4Lj0z/UdbqJWGTLn2VKIXw2npuEoS/TG5bB
6Ch2tTmN8FRkwv8wqEr4mIDU2TBCdyma4pWO7fNAbWFtQhHg4iVJ3WXQtCBHF/FA
dRpwm1CHBLNRf1VxM0fiOiHMq4fRdOvbMrT+ixWd+OnqDSxYoqllmIwLrouM+mMg
+jnz2BwEbLRh7JcTExhPHk3YXBoctCfle8LrRRjo3a6IzrssYecXU6MOocu/L5yH
8Y1MYpHpn4OfkvBH2HdJzk3LHvoaEm1NgTYwHKzoko6TEbKZG2+t487x+PoIXjud
NS25eyv+4+3HKsQZsrTj
=ZQTF
-----END PGP SIGNATURE-----