Revamp the Admin Security Model
Summary: The current approach for Admin is better than nothing, but largely sucks. It should be almost entirely rebuilt.
The current approach is that access rights are inherent in the User. Users can be Admins, which let them do some things, or Superadmin, which allows more. This means that I wind up having to log in with a secondary account in order to do Admin stuff. Also, there is a lot that only Superadmin can do. And none of this is currently being logged.
This should be rewritten, as follows:
- Superadmin should remain a separate, highly-locked-down account. It should only be used for rare activities such as approving new Admins. In particular, the current approach, where only Superadmin can look into Spaces, should be migrated to Admin. Basically, let's get more serious that Superadmin is essentially root, and should only ever be used for exceptional activities.
- While Admin will remain a special setting on the User, it should not, in and of itself, permit anything special. Instead, there should be an additional Option field in the User data structure, which is a time-limited security token.
- When an Admin wants to go into Admin Mode, he invokes that through the UI. This creates a security token, which is good for, say, 30 minutes. This token is uploaded to the Client, and stored as a time-limited cookie. The token is also timestamped with its expiration time, and signed. Whenever it is used for approval, this signature and timestamp is checked.
- (Alternatively, the security token could be stored in the UserSession, server-side. But that means that all logged-in windows for that User will now be in Admin Mode; I'd prefer to restrict it to this browser session.)
- (Other alternative: once we rewrite the Client so that you don't reload it when you change Spaces, we could simply store the token in-memory in the Client, rather than as a cookie. This would be even more secure, but won't really work in the current architecture.)
- If set, the token is sent as part of the metadata with all Client requests. If a token is received with a request, it will be attached to the User structure and passed around while processing this request.
- While in Admin Mode, this is shown in bright red in the Client, with a countdown timer of how long before Admin Mode expires, and buttons to exit or renew Admin Mode. When you exit Admin mode, the cookie is erased.
- We add a new Admin Audit Log to the system, possibly as a simple Persistent Actor that mainly exists for its History.
- Whenever an Admin escalates to Admin Mode, that is logged.
- Whenever an Admin loads a Space that is only accessible to them as an Admin, that it logged.
- Whenever an Admin changes a Space that is only accessible to them as an Admin, that is logged.
- As a matter of policy, Admins are only allowed to enter User Spaces as an Admin after receiving explicit permission from that Space's Owner. The dialog to enter Admin Mode should say this explicitly.
- There must be an Admin-only UI that allows review of the Admin Audit Log, optionally filtered by Space or Admin, so that we can review what has happened with confidence.
