Authentication integration: Difference between revisions
imported>Paulproteus (Created page with '== Purpose == The OpenHatch website is comprised of a few pieces. There's the OpenHatch codebase in Django, but there's also this wiki. I'd like logins to be integrated. == Str…') |
imported>Paulproteus No edit summary |
||
| Line 1: | Line 1: | ||
== Purpose == |
== Purpose == |
||
The OpenHatch website is comprised of a few pieces. There's the OpenHatch codebase in Django, but there's also this wiki. I'd like logins to be integrated. |
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. |
||
== Strategy == |
== Strategy == |
||
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 |
|||
When (e.g.) the wiki wants to get the OpenHatch username and email address corresponding to the current session, it |
|||
=== 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 |
|||
=== Django code: create_user_data_cookie === |
|||
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_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__username''': This contains the user's username. |
|||
* '''user_data__username__hmac''': This contains a HMAC-SHA1 of the username. |
|||
=== Application: Read cookie data, then delete cookies === |
|||
Now it's time for the application (e.g., the wiki) to read the user data and log the user in. |
|||
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. |
|||
Revision as of 21:36, 4 September 2010
Purpose
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.
Strategy
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
When (e.g.) the wiki wants to get the OpenHatch username and email address corresponding to the current session, it
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
Django code: create_user_data_cookie
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_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__username: This contains the user's username.
- user_data__username__hmac: This contains a HMAC-SHA1 of the username.
Application: Read cookie data, then delete cookies
Now it's time for the application (e.g., the wiki) to read the user data and log the user in.
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.