TFA & RBAC

[MP70]

I'm just looking at my roadmap and I need to write these two features at some point in the future. I may as well contribute them back if you'd like them..

I'm a bit torn about how I'd like to do implementation on the above, interested in your thoughts. If we can come to an agreement that works in my use case and for your boilerplate then I can contrib back.

TFA:

Opt 1 - make this part of the login sequence and add it into the passport login script. TOTP only probably, do the validation on login inside typescript with a node library for TOTP checking (i.e if a tfa is set don't call the Postgres login function until we have validated the TOTP token. Drag session times down. I'm thinking this is probably a bit too simplistic for my use case but could be OK. Super simple to write.

Opt 2 - decouple it and ask for it at login, but also whenever we do something sensitive. Write a handler that will allow us to require them to re-TFA on doing special operations. E.g if you want to delete a record then resupply TFA. This would probably mean we might want to do the TOTP validation in Postgres. Not entirely thought this out, but it could be that we carry in Postgres "last_tfa_timestamp" and check for this being < 5 minutes ago and then throw an error which causes the frontend to run a verifyTFA operation and retry the query or ask for it directly in those functions which are special or write middleware which will do this in express for a statically defined list of queries..

### RBAC:
Opt 1- flexible : So we have a group table, and a permissions table. User or admin can create a group with A,B and C permissions and then add a permissions group UUID to the org_membership table. Select 1 if permission where group = $groupUUID. Keep track of permissions in a JSON file under source control. Default "Owner Group" that replaces is_owner.

Opt 2- flexibleBasic : Directly assign permissions to a org_member maybe in an array e.g permissions varchar[] - {"CRUSER", "DLUSR"}.

Opt 3- staticBasic : Super simple static permissions where we recommend for example the default of a org_member is read only for records in that organisation, then e.g a Tier1 and Tier2 T/F permissions rows in the database similar to the existing is_owner implemenation. The user can decide how to use Tier 2 -- e.g Might be also write/update simple nonconsequential things. Tier 1 could be write/update all things (i.e like old 'is_owner' check). User could always add in more tiers if they need it manually.

Opt 4- Use Postgres rbac and groups to do all the hard work for us and change the context.

For any of the above

-Invite member with permissions XYZ should be implemented

-is_owner and is_billing stay as business logic only fields. For example where to send billing or account emails. All cureent is_owner permsission checks get shifted to the new RBAC method.

[benjie]

Graphile Starter development will recommence a while after PostGraphile V5 is released; in the mean time I won't be merging any significant pull requests into it (or reviewing them), so please do whatever works for you. Sorry I can't dedicate more time to analysing the options right now.