Feature Request: Authorize users from RATT

[tangentaudio]

It has been requested that Resource Managers be able to directly authorize users from the RATT interface.

This has many implications and is likely to be a significant project. As implemented currently, users interact directly with the auth backend web interface to make access control changes, RATTs are notified of changes, and RATTs then pull updated ACLs from the backend. This feature would alter that model and allow ACL change requests to flow from RATT to the backend, which (if accepted by the backend) would trigger an update. Security implications should be considered.

Also required for this is for each user record to contain an access level for the given resource, so that RATT may know if a user is the admin user and thus allowed to manage users. An 'admin mode' menu would need to be created for this as well.

[bkgoodman]

Most if the logic already exists in the new backend. I would recommend a model by which once a user is logged in, a "secret menu" or like option would allow the user to scan another RFID tag [or timeout after a short interval] with the intent of authorizing them. When done, it could EITHER:

1. Broadcast a "User X is requesting access to resource Y" message. Fire and forget. Backend could verify if this operation is allowed, and take action accordingly.

2. [Prefered] Send an API request to back-end - to which back-end could give user a "done", "no access", or "could not connect" status, etc.

Optional feature: The new backend has a concept of not only if users have access to a resource, but what special permissions they might have on it. If we sent that field for each user entry in the Access Control list:

1. Would it's presence break any logic?
2. We could use that to "unlock" the aforementioned "special menu".

This could also be sued to:

1. Allow "special menu" to do things like lock/unlock resource, etc.
2. Allow RMs to log-into resource even when it is in "locked' mode.

(Some detail)

4 levels of resoruce specific privileges exist in [current] new backend:
User (0) - A user who has permission to access access backend
Trainer (1) - Trainers can authorize new users on this resource
Asst' RM (2) - Can authorize and revoke user privileges, lock/unlock machine, use machine during lockouts

(Other privs exist - but don't have direct back-end) implications.