580284 - Assign UUID to users and use that when communicating with client app

Status: RESOLVED FIXED

(Webtools Graveyard :: SSO (Legacy), defect, P1)

Description

[Fred Wenzel [:wenzel]]

If we use the SSO nickname when talking to a client app, people can never change it without fear of username hijacking.

So we should assing a UUID to users that is only used in communication with the client apps, and never changes. No-one will see this except SSO <-> client app.

Comment 1

[Austin King [:ozten]]

I've played with

1) Sub-classing django.contrib.auth.models.User with SSOUser and putting a new property sso_uuid on this model.

2) Using the Django User.get_profile support to create a UserProfile model which has a property sso_uuid.

#1 is a slightly better choice from a performance perspective, as the UUID would be handy in the auth_users table. The downside is that all the code that access the User would need to access the SSOUser instead. I messed with implementing an Auth Backend and ran into some issues. It also introduces some magic, which is bad. All of this is probably premature optimization and so I'm writing then with solution #2 instead. We'll be caching these objects, so a second query is not a big deal. If we add more "profile" information, we'll already be setup with the get_profile pattern.

Comment 2

[Austin King [:ozten]]

Attachment: First stab, patch for bug583797 second attempt tree

Note: This patch will only apply on top of the 583797_2 branch of Bug#583797.

Patch can also be revied at http://github.com/mozilla/secret-squirrel/commit/583fe4bf1003fe0dd2d232c7b946d3e9b952748f

Comment 3

[Fred Wenzel [:wenzel]]

Comment on attachment 464651 [details] [diff] [review]
First stab, patch for bug583797 second attempt tree

I like that, good job! Now we only need to use it in the cas_provider app as opposed to the username (when sending "yes\nusername").