Disc: Auth & Logging in

Overview

Person objects are Person Sharables which contain metadata about a person. These already exist in Clotho. Each individual using Clotho may have multiple persona, captured by multiple Person objects.

Users are security personas which are used for login. They can have multiple Persons associated with them.

Users need:

• username (user provided)
• password (user provided)
• ID (unique across all Clothos - exposed to user on login)
• associated Person IDs

Information tied to an individual (e.g. settings), and authoring information should be tied to the ID of the user, rather than IDs of Person objects.

Currently, users cannot be created until an associated person exists. This needs to be changed.

createUser() (implemented, needs refactor) takes username, password, and optional array of person IDs, and will create a UUID, and whatever else the server needs

Login() (implemented) takes a username and password

updatePassword() (implemented, needs refactor) takes a username and password. It should also take old password, or allow reset via server-authenticated method.

associateUser() (forthcoming) should associate a person with a user

grant() handles permissions

Comments on the above

I disagree with this statement: "authoring information should be tied to the ID of the user, rather than IDs of Person objects." Authorship should point to the Person not the User. Within one domain of Clotho, one Person uniquely maps to one User. However, the User may point to multiple Person, and thus there is information loss when pointers are made to the User. Additionally, a User is not a Sharable and thus is not publicly exposed by clotho. Thus, the ID for a User is meaningless beyond a single Clotho domain. Also as a result of this, there is a different User on any given Clotho domain associated with one Person. I've sent out a powerpoint describing this visually, narration in notes section as: 2014_09_14-Users and Persons.pptx. When thinking about Person and User, it is helpful to consider that Person is publicly exposed, and User is not. This places many functional constraints on the decision. The use case to think about is a human has constructed two Persons to handle two different jobs that legally, ethically, or strategically need to be firewalled. For example, it is important to distinguish Sharables authored by ddensmore at BU over those that were authored during the course of work for Nona. In this example, Douglas has two Persons associated with his User, and he changes which one he is logged in as to indicate the which 'hat' he is currently wearing.

I'm also unsure about this statement: "Information tied to an individual (e.g. settings),...should be tied to the ID of the user". This needs to be exploded out...which settings are we talking about? I would expect security settings (the User object is not exposed, so how can I grant permissions to a User? all I know is their Person); population of a phagebook page (again, the User is not exposed, and DD wants to present his Nona work as distinct from his BU work), and most other things to operate on a Person.

Someone with administrative access to an instance of Clotho presumably needs to authorize the creation of a User. The pointers to a Person, or the creation of new Persons is something the individual human can do. It is never going to be safe to allow a general-public person to create their own User. Once you have a User, you have create access, and from this you have the ability to cause a lot of damage. It is implicit that there is trust for an individual before providing them access as a User. So, I agree with this statement: "Currently, users cannot be created until an associated person exists. This needs to be changed.". An administrator needs to either initiate the creation, or click an "ok" if the User initiates the creation. The administrator creates a User that points to no Person, and then the human attaches their new User account to a Person(s).

Prashant's Comments

From a Server side perspective, I think we should implement Login + User as follows:

Every time, a user is created, we would need the following details:

• User Name
• Password
• (Basic Details, such as first name, Last name, Email Id)

In the Server Side, once we try to create a new user, Clotho Account will store the User Name and Password. At the same time, a Person object should be created, which stores every detail other than password. While creating Person, the username should also be the ObjectId of the instance of Person created.

Since our main problem stems from what should User ID be, we have two options:

• Use an Alphanumeric sequence
• Use an existing email id - either tied in to or independent from an existing Social Networking

There are multiple existing models that we can use for our current conundrum. I've listed out the options we could explore, along with the pros and cons I could think of:

1) Twitter:

Twitter lets users choose their own "User Name" which is usually an alphanumeric sequence. Now this sequence is unique across all users of Twitter. Which means, if you create a new user, and enter a user name, it will check if the entered user name is "available". Twitter also lets you link your Facebook account with the created Username and password. But this is only to be able to post updates to Facebook via Twitter. In this case, you do not use Facebook authorization to log into Twitter.

Implementation:

• Ask for User Name, Password and First Name, Last Name.
• User Name would be alphanumeric (Not an email id)
• Check if User already exists. If a matching user name is found, say, User exists
• If user name does not exist, create a ClothoAccount with user name and password, create a Person storing username as ObjectId, email Id, First name and last Name as provided by the User.
• Proceed to asking if they would like to link a Facebook account to Clotho.
• If yes, proceed to Facebook login, and pull FB information, and show an updated User Profile Page, asking user to confirm if he/she would like to keep this updated information.

Pros:

• This is fairly easy to implement. (especially checking availability of a username). This is also something very close to what we have right now.
• Having unique user names will be a good idea for the future if we one would ever require usernames to be associated with clothocad domain name. I mean, if in any near or distant releases, we decide to have 'xyz'@clothocad.org, this would be easy to link.
• The user can then have the option of adding multiple "Email Ids" to the Person object (this would have to be verified)

Cons:

• Users would only be able to choose their User Id on a first come first serve basis.
• We would have to figure out a way to ensure that updated FB information is reflected in Clotho.

Chess.com : (Link : http://www.chess.com/ )

Follows the same model as Twitter, except, users can now chose to log in via Facebook. Everytime you log in, you have 2 options: (a) Use a user name and password (again unique) or (b) Use Facebook credentials. If one uses the user name password, authorization is done by Chess.com. But if one uses Facebook credentials, authorization is performed by Facebook.

Implementation:

• New User/Login Page, would have two options: (a) User name password for Clotho, (b) Facebook Login
• If the user chooses (a), see Twitter implementation (except for the Facebook part)
• If user chooses (b), redirect to FB login.
• Pull Facebook information, and populate it in User profile page. (create Person, do not specify ObjectId, let MongoDB create one)
• In ClothoAccount, username will be the ObjectId created by MongoDB, and password field will be null.
• The user can then have the option of adding multiple "Email Ids" to the Person object (this would have to be verified)

Pros:

• We do not store FB credentials.
• The user experience when it comes to creating Log in and creating a new user maybe easier, since Users who choose FB do not have to create yet another account for another service.

Cons:

• User Clotho Account is tied to FB. So if one stops using FB, hence, their Clotho account will only be as safe as their FB account.

Windows Phones:

So far, the two ideas mentioned above, are specific to creating just One User Windows Phones are all tied to a "live.com" account. Every user, can then add other profiles, such as Facebook, Twitter, Instagram, gmail, LinkedIn etc to these as multiple "Persons" for the same user. Authentication however, is always via the windows live account. Users however, have the option to set their primary information based on each Account. For instance, I can edit my Profile picture, such that it always shows my Google picture as my most current picture. At the same time, my personal information can be set with FB information while my employment details can be set with the LinkedIn information

Implementation:

• First step, ask user to choose User Name, Password (again unique and alphanumeric, or an email id. If it is an email id, the id has to be verified using some email verification system).
• Create a schema "PrimaryPerson" (or something like that) with this username, and ClothoAccount with this username and Password
• Show a list of Available networking Services such as FB, LinkedIn, Gmail. Ask user to authenticate the ones the user wishes to link to Clotho. Create a Person object for each service/email id entered. Pull relevant information and populate it in a page which has User information. All the information chosen, can be saved in PrimaryPerson. Hence PrimaryPerson would be a Node, with each Person (FB, Gmail, live.com, yahoo.com, bu.edu, berkeley.edu) as a child. The field linking each Person to PrimaryPerson would be User Name specified in Step 1.
• Login will always involve the credentials set in Step 1.

Pros:

• Very detailed. Lets user chose their level of privacy for each linked account.
• Has a primary Clotho Account linked to just 1 user name (which will be unique)

Cons:

• Might be difficult to implement.

Tokens + Security

We could use OAuth via 3rd party service to handle authentication.

However, we currently allow users to pull in their information from a 3rd party, but they must create an account with Clotho directly. The User they create will be associated with the Person, created based on the information obtained from their social media profile.

Clotho will create a session per-session token, rather than using a third party service, for handling REST requests. WebSockets are already secure.

Brian's comments (teague@mit.edu)

I don't understand the need for a one-to-many mapping between users and Persons. If a user wants to separate his or her work for various organizations, I don't see the problem with tying that to different email addresses. For example, this is Dropbox's model.

If we associate authorizations on objects with Persons, the other thing this makes easy is switching out the authentication mechanism. Wiring up OAuth or OIDC or Kerberos is easy; we just need the service to say "yes this person (email address) is allowed in" and then map their identity to a Person. Then Clotho's only role is to maintain that mapping ... which is super-easy if that Person's id field is the email!

Presumably the task of establishing a new Person and creating that mapping is taken care of by an administrator. Which begs the question - there doesn't seem to be any way to control object authorship, correct? A Person is an arbitrary schema just like a Part or a Polynucleotide. We need more administrative control here - either the creation of Persons should be privileged, or the id field should be.

Maybe Person gets moved from model to datums, like Badge is -- instances in the container, created and managed directly by the server without a Schema.

Thoughts?