Improve the auth capability for Tensorbase

[hsluoyz]

We can provide more help for: https://github.com/tensorbase/tensorbase/issues/126

[hsluoyz]

@hackerchai @smrpn @PsiACE

[hackerchai]

@hackerchai @smrpn @PsiACE

Will look into it

[frank-king]

Hi all, I'm the contributor of TensorBase, thank you for your interests of supporting TensorBase!

As the description in tensorbase/tensorbase#126,

Basically, we need two kinds of policies, which:

1. describes which users have access to which databases/tables, in particular access patterns (e.g. read/write/update/...),
2. describes which users have access to which computing resources, how many quotas, and the priorities.

we need two kinds of policies in our project. However, the problem is that casbin seems not to support multiple policies according to the descriptions on the doc.

In addition, the might be more problems where the actions might be composite. For example. If the user Bob submits a SQL to access the table school and teacher read only, running with 8 CPUs and 32 GiB memory, in a low priority. We will first check whether he has read access to the two tables, and how many quota of CPU and memory remained (owned by Bob).

Based on the current implementation of casbin, the above rules are possible to implement as:

1. split up the two policies to two model files and policy files, and query the action separately;
2. split up the access checks according to different tables (but it might become complicated if many tables are accessed in the same time, e.g. insert into A select ... from A join B join C will generate 4 actions: user read A, user write A, user write B, and user write C);
3. maintain the usage of resources for users in runtime, and always query casbin with the total amount instead of the increment of currently-used resources (i.e., if Bob requested 4 CPUs and then 6 CPUs, Bob CPU 4, Bob CPU 10 will be generated)
4. split up the access of different types of resources (similar to 2).

Do you have any better suggestions?

---

BTW, we prefer more meaningful field names such as

[policy_definition]
data = user, table, action
resource = user, type, quota, priority

instead of

[policy_definition]
p = sub, obj, act
p2 = sub. obj. act

Currently, those names seems to be hard-coded and not modifiable.

[hsluoyz]

@smrpn

/cc @hackerchai