Editing Authentication integration

Jump to navigation Jump to search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.

Latest revision Your text
Line 1: Line 1:
{{Hacking OpenHatch}}
 
 
== Purpose ==
 
== Purpose ==
  
Line 9: Line 8:
  
 
* Users only have to authenticate once to all (web) services within openhatch.org.
 
* Users only have to authenticate once to all (web) services within openhatch.org.
* Simple implementation.
 
 
* Users can't impersonate other users.
 
* Users can't impersonate other users.
* Even if the forum is compromised, it's not totally trivial for the forum admin to impersonate OpenHatch users to other openhatch.org applications (especially openhatch.org itself).
 
 
* Applications outside openhatch.org should not be able to use this system to gain information about users. (They might be able to use ''other'' mechanisms, but not this one.)
 
* Applications outside openhatch.org should not be able to use this system to gain information about users. (They might be able to use ''other'' mechanisms, but not this one.)
 
* These applications don't have to be particularly securely maintained. (Specifics...?)
 
* These applications don't have to be particularly securely maintained. (Specifics...?)
Line 17: Line 14:
 
m_stone's notes:
 
m_stone's notes:
  
 +
* You should plan to rotate authenticators.
 +
* Maybe use separate HMAC keys for separate "apps"?
 
* I'm a bit nervous about having splittable cookies. Maybe add an index cookie? (fun link: [http://wiki.laptop.org/go/Canonical_JSON canonical json])
 
* I'm a bit nervous about having splittable cookies. Maybe add an index cookie? (fun link: [http://wiki.laptop.org/go/Canonical_JSON canonical json])
 
* I'm a bit nervous about the inter-app dataflow that these cookies represent. How are you going to avoid exposing XSS opportunities in the apps receiving data through these cookies?
 
* I'm a bit nervous about the inter-app dataflow that these cookies represent. How are you going to avoid exposing XSS opportunities in the apps receiving data through these cookies?
* Other minor nits: unicode canonicalization, redirect_to abuse & replay
 
  
 
== Overview ==
 
== Overview ==
  
 
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.
 
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.
 
== Before using ==
 
 
Every new application that gets added to the authentication integration system needs a key to use with HMAC.
 
 
To generate such a key, run this on '''linode.openhatch.org''' as the '''deploy''' user:
 
 
$ dd if=/dev/urandom bs=1M count=1 | sha1sum
 
 
That will output a hex string on its last name. We need to store that in the Django configuration, so we add that to '''deployment_settings_settings_secret_keys.py''' by adding a line like this:
 
 
AUTHENTICATION_INTEGRATION_KEYS['forum'] = '51996f577251de19efbd623a9c5045a9d4144415'
 
 
We need to then make sure the forum uses that key, too.
 
  
 
== Details ==
 
== Details ==
Line 43: Line 27:
 
=== Application: redirect ===
 
=== Application: redirect ===
  
If the wiki detects an OpenHatch session cookie, it:
+
If the wiki detects an OpenHatch session cookie, it redirects the user to http://openhatch.org/+create_user_data_cookie?redirect_to=http://openhatch.org/wiki/handle_login.php
 
 
* Creates a cookie called '''user_data__application__come_back_to''' and stores a URL in there
 
* Creates a cookie called '''user_data__application__come_back_to__hmac''' containing the HMAC-SHA1 of the come_back_to cookie
 
* Creates a cookie called '''user_data__application''' and sets it to a string that identifies HMAC key
 
* Redirects the user to https://openhatch.org/+create_user_data_cookie
 
  
 
=== Django code: create_user_data cookies ===
 
=== Django code: create_user_data cookies ===
 
The Django code creates a JSON object with the following keys:
 
* username: The username of the currently logged-in user.
 
* email: The ...
 
  
 
The OpenHatch site creates some cookies. All cookies contain text. We encode it as UTF-8 and then wrap that in base64.
 
The OpenHatch site creates some cookies. All cookies contain text. We encode it as UTF-8 and then wrap that in base64.
 
 
  
 
The "message" that we HMAC is the final, base64-encoded data.
 
The "message" that we HMAC is the final, base64-encoded data.
  
* '''user_data__json''': This contains the user's email address.
+
* '''user_data__email_address''': This contains the user's email address.
 
* '''user_data__email_address__hmac''': This contains a HMAC-SHA1 to verify the authenticity of the email address.
 
* '''user_data__email_address__hmac''': This contains a HMAC-SHA1 to verify the authenticity of the email address.
 
* '''user_data__username''': This contains the user's username.
 
* '''user_data__username''': This contains the user's username.
 
* '''user_data__username__hmac''': This contains a HMAC-SHA1 of the username.
 
* '''user_data__username__hmac''': This contains a HMAC-SHA1 of the username.
 
Finally, it checks for a '''user_data__application__come_back_to''' cookie. If passes the HMAC-SHA1 check, it redirects the user to that URL. Otherwise, it redirects the user to https://openhatch.org/.
 
  
 
=== Application: Read cookie data, then delete cookies ===
 
=== Application: Read cookie data, then delete cookies ===
Line 75: Line 46:
 
It should delete the user_data__* cookies that it read, to avoid keeping clutter in the user's browser.
 
It should delete the user_data__* cookies that it read, to avoid keeping clutter in the user's browser.
  
It '''MUST''' verify the user_data__* using HMAC-SHA1 before trusting it, as users can tamper with this data.
+
That's up to the application. It '''MUST''' verify the user_data__* using HMAC-SHA1 before trusting it, as users can tamper with this data.
  
 
The application should make its own "logged in" status expire at the end of the session.  
 
The application should make its own "logged in" status expire at the end of the session.  
Line 87: Line 58:
 
** We can fix this by constraining usernames on the Django side to be case-insensitively unique.
 
** 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].
 
*** Right now, Django usernames [http://code.djangoproject.com/ticket/2273 seem to be case sensitive].
 
* me_stone says, "You should plan to rotate authenticators [keys for the hash]."
 
** Asheesh says, "Okay, fine. We should revisit this in September, 2011, and probably rotate them. (That's one year from now.)"
 
  
 
Some usability issues:
 
Some usability issues:
Line 98: Line 66:
  
 
* 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.
 
* 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]]

Please note that all contributions to OpenHatch wiki are considered to be released under the Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) (see OpenHatch wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

Cancel Editing help (opens in new window)

Templates used on this page: