permissions and groups via wasm

[amitu]

In the earlier group design, we had a group definition language, but that was both complex, and also not complex enough (eg it was kind of a lot of code for us to implement at generic level, and yet did not handle all scenarios). What if we can move the complexity of authorisation to wasm, so people can add their own wasm plugins to take care of permissions. We have already done this for auth, so this seems the right logical choice.

Decoupled ACL

We want end users, site admins, to create permissions and groups using acl-wasm files, but all other wasm apps should not be aware of what acl-wasm file is being used, so there should be some sort of interface to define and query acl-wasm.

Acl-wasm answers a few questions:

• Does this user belong to this named group. This user can be currently logged in user or it can be another user, eg if I am adding someone to a chat room, I should only see users in auto complete that belong to my company.
• Does this user has this permission.
• Does this user has this permission on that object.

Efficient Queries

One problem is how do I say find all objects a given user has access to. We have to store some access related information in the object table as well.

We may want to store either the user, or groups with the object table, eg all these repos are accessible to people in so and so team, and we do not want to add access to individual users/repo combination. We may even have groups of repos mapped to group of users, or groups of repos mapped to group of group of users.

Ideally we have users organised in tree, so groups are trees.

But these are the concerns we want to delegate to the wasm.

Generic Share UI

When we share an object, or a permission, ideally the app-wasm should trigger some sort of "acl-wasm", the app wasm does not know if it is being used on a site that has no groups, eg a really tiny site, with only one or two users may never install any group related stuff, and "acl-wasm" should show the share UI with just the user selector. The app-wasm does not really care what UI is used, and what is being returned, what is being returned is some sort of id, which the app-wasm with send back to acl-wasm and ask if the currently logged in user belongs to this id.

When sharing the app may show a bunch of permissions, multi selector maybe, so everyone selected by the share ui is also assigned a permission.

Share / Is Shared With - as the main building blocks

The ACL wasm exposes an api acl-wasm::share(obj) -> share-id.

Shared Table

| id | app | doc-id | definitions | users-we-know-who-belong-to-this |

The last column makes it easy to query all doc-ids that currently logged in user has access. The kind of access may not be known. So you filter for access, and then call kind of access query only on the filtered results.

Sharable As Main Building Block

Imagine a table "sharable", managed by acl-wasm, which is identified by an opaque id, used by all wasm apps. Each app has questions like this action (access to admin site) is allowed globally or on any given object. The app stores the share-id against a configuration table (for global roles eg can access admin), or with the individual document (eg with todo in the table for todo).

Say if the shareable id is stored in config table:

create table todo_config (key, value);

Check if current user has admin access to todo app:

share-id = select value from todo_config where key = 'admin-access';

select count(*) from fastn_sharable where id=share-id and users  ?;  -- what should go in ?

Virtual Table?

We can create virtual table in SQLite, and possibly there are other ways to do this in PostgreSQL.

[amitu]

The minimal version

Share UI

We need UI to trigger share action. Say there is a component, share-ui.fifhtry.site/share-ui, which somehow locates the "acl-app" you have installed and presents its UI. The share-ui component takes a ftd.ui, so it can show what is being shared. We can avoid this by saying this is the responsibility of the component calling the share-ui, the outer chrome is owned by the component calling share-ui and they can use a dialog, or "configuration page", whatever UI, and let share-ui only take care of the sharing related concern.

The share ui should also the list of permissions. For now let's pretend each permission has an id, and a name. So if the user is updating the sharing setting, they can assign the permission-id to anyone. The caller of share-ui passes module with share-updated(integer) method, which will be called when ever the user interacts with share ui and updates who it is shared with. The responsibility for creating close button is with the caller.

The share-ui will be passed the last share-id for this context.

Has Permission

The next bit is has-permission(share-id, permission-id), this can be called to check if the current user has the permission.

Can Share Permission

There is no can-share permission. The job of the application is to not show share dialog if the current user does not have the share permission. What constitutes share permission is decided by the application, it maybe the "admin", or it maybe "can-share", the framework does not care.

[amitu]

Django Models

User has is-staff and is-superuser. Also there is a table called Groups, and many too many between user and group. Also there is a table called Permission, and many too many between User and Permission and Group and Permission.