Jump to content

Authentication integration: Difference between revisions

no edit summary
No edit summary
No edit summary
Line 16:
m_stone's notes:
 
* 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 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?
Line 24 ⟶ 23:
 
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 ==
Line 29 ⟶ 42:
=== Application: redirect ===
 
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 ===
 
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 "message" that we HMAC is the final, base64-encoded data.
 
* '''user_data__email_addressuser_data__json''': 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__username''': This contains the user's 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 ===
Line 48 ⟶ 74:
It should delete the user_data__* cookies that it read, to avoid keeping clutter in the user's browser.
 
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.
Anonymous user
Cookies help us deliver our services. By using our services, you agree to our use of cookies.