Skip to content

User Sessions

Flynn Duniho edited this page May 29, 2024 · 1 revision

Preliminary design of a very simple user authentication system

User Session Requirements

We have a server running at a local IP address on the LAN. Running the server will display the IP address.

  • We want GROUPS that access a particular shared DATASET
  • We want ANONYMOUS user stats while still seeing WHAT USER DID WHAT
  • We want easy distribution and assignment of group, user, and access credentials

I'm dispensing with passwords because they are a tedious detail, and people are going to be insecure anyway. Instead, will make some reasonable defaults and keep things very short. Instead, will rely on algorithmically-generated users and group keys. These keys will be very short but encrypted with data inside, so they can not be easily forged.

User Session Credentials and Unit Access

I'm thinking that we can provide a unique authentication key (kind of like a software product code). It should be 6-8 letters at max, is hard to decrypt. The activity can be part of the code, and it will be case-insensitive.

    UNIT_KEY:   CodeWord (PascalCase but is case-insensitive)
    -
    GROUP_KEY:  GroupWord (PascalCase but is case-insensitive)
    USER_KEY:   AC1-FLA (linked to GROUP at generation)
  • Access to the unit is in the form of http://appserver.local/unit/UNIT_KEY/USER_KEY
  • There is NO PASSWORD. The USER_KEY is associated with a GROUP_KEY. Just visiting the URL will log you in.
  • The USER_KEY is pregenerated and assigned to a student by teacher, but the student identity is not stored in the database.
  • You can not easily make up your own USER_KEY because it's a self-encrypted key (much like a product key)
  • All user actions are logged under that key.
  • If another user key is logged in to the system, you aren't allowed to login until the other user disconnects
  • Participation is logged when this KEY is used to gain access to the UNIT
  • While USER_KEYs are associated with a GROUP_KEY, a user can access another group data by accessing UNIT_KEY/GROUP_KEY/USER_KEY
  • UNIT can be set-up to disallow cross-group access
  • For READ ONLY access to the data for a particular group, use UNIT_KEY/GROUP_KEY instead

Generating USERKEY lists

  • Access an ADMIN URL that algorithmically generates a list of USER_KEYs from a seed, so they never have to be stored.
  • The USER_KEYs are created per GROUP
  • A USER_KEY can be used to access any UNIT
  • The keylist is generated for printing from http://appserver.local/admin/unit/UNIT_KEY. It is up to the teacher to note which key is assigned to what student, and the student must remember it.

Defining Units and Membership

An editable JSON document contains the following:

Options {},
ClassKeys [
    { ClassID, ClassName, ClassSize }, ...
],
UnitKeys [
    { UnitID, UnitName, DataSet }, ...
],
GroupKeys [
    { GroupID, GroupName }, ...
]
  • To generate USER_KEYs, the algorithm loops over GroupKeys and ClassKeys and generates a number of associated USER_KEYs that implicitly encode the GroupID.
  • The list of USER_KEYs is generated algorithmically from the GroupID and ClassID, so they are never stored.
  • Authenticating to the application is handled implicitly via the URL.
  • The number of USER_KEYs generated per class is specified in ClassKeys Class.ClassSize multiplied by GroupKeys.length. This number can be increased without destroying old keys, because the keys are algorithmically generated from a seed.
  • We generate more keys that necessary so groups do not have to contain the exact same number of students, and the teacher can pick a new one without regnerating the list and printing out a new one. For large classes, we may tune the algorithm to auto-create lists that are ClassSize / GroupKeys.length
Clone this wiki locally