...
Our LTI users will either have some empty attributes or some automatically generated. In either case, we will have to figure out where the existing edX code assumes that a user has a particular attribute and make sure that it will continue to work properly without one. An example would be the discussion forums - if our user has no public user name, we must either ensure that we have a generated user name (which wouldn't be particularly useful to forum viewers), or make sure that the code can handle an empty user name.
Topic: Defining a unique login ID (e-mail) for an LTI user
LTI provides us with a user identifier that is determined by the tool consumer. Per the LTI spec:
user_id=0ae836b9-7fc9-4060-006f-27b2066ac545 (Recommended)
Uniquely identifies the user. This should not contain any identifying information for the user. Best practice is that this field should be a TC-generated long-term “primary key” to the user record – not the “logical key". At a minimum, this value needs to be unique within a TC.
Since we will eventually have multiple campus systems, we can't rely on the user_id field being globally unique. LTI also includes a recommended tool_consumer_instance_guid that can be combined to create a (hopefully) globally-unique identifier.
tool_consumer_instance_guid=lmsng.school.edu
This is a unique identifier for the TC. A common practice is to use the DNS of the organization or the DNS of the TC instance. If the organization has multiple TC instances, then the best practice is to prefix the domain name with a locally unique identifier for the TC instance. In the single-tenancy case, the tool consumer data can be often be derived from theoauth_consumer_key. In a multi-tenancy case this can be used to differentiate between the multiple tenants within a single installation of a Tool Consumer. This parameter is strongly recommended in systems capable of multi-tenancy.
Requirement: Identity linking between edX account and campus LMS account
...