Authentication integration: Difference between revisions

no edit summary
imported>Paulproteus
imported>Paulproteus
No edit summary
Line 3:
The OpenHatch website is comprised of a few pieces. There's the OpenHatch codebase in Django, but there's also this wiki and we are [[choosing a forum]]. I'd like logins to be integrated.
 
== StrategyOverview ==
 
Django code creates domain cookies within openhatch.org that contain the user's username and email address. The application (like the wiki) can read that information and verify it using HMAC-SHA1.
Only applications in *.openhatch.org can receive user data. HMAC-SHA1 is used to verify the authenticity of the data that is passed through. Th
 
== Details ==
When (e.g.) the wiki wants to get the OpenHatch username and email address corresponding to the current session, it
 
=== Application: redirect ===
Line 34:
The application should make its own "logged in" status expire at the end of the session.
 
== Known issues ==
 
There are some problems with this setup. Some security issues:
 
* Email addresses and usernames travel along the network unencrypted. (In practice, this is no worse than the status quo, since session IDs already do that.)
* Not all applications treat usernames as case-sensitive. This might allow an attacker to create a new username that is treated as equivalent to a different user, effectively stealing an account.
** We can fix this by constraining usernames on the Django side to be case-insensitively unique.
*** Right now, Django usernames [http://code.djangoproject.com/ticket/2273 seem to be case sensitive].
 
Some usability issues:
 
* The first time the user goes to the forum, the browser will redirect a few times. That'll be weird.
 
Missing features:
 
* If an account gets deleted within the OpenHatch Django app, we don't have a way to ask downstream applications to delete their account of the same name.
 
[[Category:Hacking_OpenHatch]]
Anonymous user