-
Notifications
You must be signed in to change notification settings - Fork 1
User Sessions
Preliminary design of a very simple user authentication system
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.
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
- 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.
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 byGroupKeys.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