You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This discussion is to discuss about permissions and policies.
I'm trying to write how all this is gonna work in LocoKit.
Mainly inspired by the v0.7.x work, but also constrained by the new engine, with adapters able to proxy data from real databases (or API), without being altered.
This text should go in the docs folder to be available to developers and end users.
Here it is :
Policy
This section explains how LocoKit
manage roles, permissions and policies.
Permissions exist at several levels:
at the core level,
at the workspace level,
at the group level
Public policy
There is a public policy
at the core and workspace level.
Users unauthenticated are linked to this policy.
Unauthenticated users can:
signup if the use case is enabled at the platform level
read public workspaces and public resources of these workspaces (datasources, metamodel, records, ...)
create records in public datasource if the public policy of the workspace allows it
Core level
A user has a profile at the platform level.
The profile can be :
MEMBER
CREATOR
ADMIN
MEMBER
A MEMBER has access to the platform.
He can't create any workspace.
He has access to all resources he's able too.
It can be workspace's resources on which he's a group member.
CREATOR
A CREATOR has access to the platform.
He can create a workspace.
As the workspace's creator,
he becomes automatically the owner and the manager
of this workspace.
He can create groups inside this workspace,
add users to them, create datasources, workflows,
all actions needed to manage the workspace.
He can remove the workspace.
He can invite other members to its workspace,
through groups.
ADMIN
ADMINs are the platform managers.
They can do everything on the platform to manage it.
They can manage users (add them, configure them),
manage every workspaces
(removing them included),
access to all workspace's metadata and data.
They can block users,
by forbiding a user to log in the platform.
Workspace level
Only the owner of the workspace
can remove it (or the ADMIN users).
Only users members of a manager group can
manage (CRUD) groups, datasources, etc.
Record
A record is, eg, a row in a table for a database,
or a record in an API like BaseRow / AirTable.
At this level, a user can access records
through Access Control List rules.
Actions on tables
We distinguish 4 actions on a record : create, read, update, delete.
Each user can be member of one or several workspace's group.
Each group has a policy in the workspace.
Each policy define rules at the table level, composed by :
an action (the four previously defined),
a set of filters applied to records, allowing hiding records unavailable for the user
Table name
Create
Read
Update
Delete
Read filters
Update filters
Delete filters
Table 1
x
{ id: {userId} }
Table 2
x
{ id: {groupId} }
Table 3
x
x
x
x
Some tables can be available for creation,
and other ones only for reading, depending on
the policy defined by the workspace's managers.
Rules at table level
Rules are filters on table.
Let's take an example.
We have a database containing birdhouses,
that are installed on parcels,
and each parcel is related to a farm.
Farm < Parcel < Birdhouse
Each farm is owned by a farmer.
Each farmer has a user account on the platform.
A workspace contains a datasource for this database.
Each farmer is member of a group that is equivalent
of a farm.
We have in the workspace a mapping table
matching the group id and the farm id
in the database.
The use case is to display all birdhouses
for a farmer.
We would like to show the farmer
only the birdhouses that are on its parcels.
For this, we need to filter birdhouses
by parcel > farm id.
This should give us the following rules table:
Table name
Create
Read
Update
Delete
Read filters
Update filters
Delete filters
Farm
x
x
-
{ id: {mappingFarmId} }
-
Parcel
x
x
{ farm_id: {mappingFarmId} }
{ farm_id: {mappingFarmId} }
-
Birdhouse
x
x
{ lck_acl_parcel:farm_id : {mappingFarmId} }
{ lck_acl_parcel:farm_id : {mappingFarmId} }
-
At the engine level (under the hood),
the lck_acl_parcel is a dedicated alias
to join the parcel table.
::: warning
The lck_acl_ prefix is a reserved prefix.
You should not name your table like this.
:::
Access on table fields
A read/write permission can be defined
the same way at the field level.
Table field
Read
Write
Read filter
Write filter
Farm name
x
x
-
{ id: {mappingFarmId} }
Parcel geometry
x
{ farm_id: {mappingFarmId} }
{ farm_id: {mappingFarmId} }
Birdhouse position
x
x
{ lck_acl_parcel:farm_id : {mappingFarmId} }
{ lck_acl_parcel:farm_id : {mappingFarmId} }
These rule should work both sides,
server and client side, to be isomorphic.
This implies the data lck_acl_parcel:farm_id
to be available on the client side.
::: info
Policy rules are available on the client side.
This allows isomorphic security checks.
:::
Group level
A group is a user set,
allowing to have a logical unit.
Manager group
A group can be a manager one.
In this case, all users of this group
can manage the workspace.
Group mapping
To allow matching between a group
and a datasource entity (= table in a database),
LocoKit provide a mapping table for a group.
Table / Field
Slug
Datasource value
Workspace value
farm.id
mappingFarmId
1
uuid-group-farm-1
farm.id
mappingFarmId
2
uuid-group-farm-2
(not sure it will be sufficient, maybe there is sthg to do at the group or workspace level to specify the group has variables availalble in these rules ?)
User mapping
We need to do the same at the user level ?
TODO:
how do we manage the rule integrity in time, when, eg. the table name disappear ?
how do we allow user to define these rules, on a UI perspective ?
Feature ✨New feature or requestnextnext iteration of LocoKit
1 participant
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
This discussion is to discuss about permissions and policies.
I'm trying to write how all this is gonna work in LocoKit.
Mainly inspired by the v0.7.x work, but also constrained by the new engine, with adapters able to proxy data from real databases (or API), without being altered.
This text should go in the
docsfolder to be available to developers and end users.Here it is :
Policy
This section explains how LocoKit
manage roles, permissions and policies.
Permissions exist at several levels:
Public policy
There is a public policy
at the core and workspace level.
Users unauthenticated are linked to this policy.
Unauthenticated users can:
Core level
A user has a profile at the platform level.
The profile can be :
MEMBERCREATORADMINMEMBERA
MEMBERhas access to the platform.He can't create any workspace.
He has access to all resources he's able too.
It can be workspace's resources on which he's a group member.
CREATORA
CREATORhas access to the platform.He can create a workspace.
As the workspace's creator,
he becomes automatically the owner and the manager
of this workspace.
He can create groups inside this workspace,
add users to them, create datasources, workflows,
all actions needed to manage the workspace.
He can remove the workspace.
He can invite other members to its workspace,
through groups.
ADMINADMINs are the platform managers.They can do everything on the platform to manage it.
They can manage users (add them, configure them),
manage every workspaces
(removing them included),
access to all workspace's metadata and data.
They can block users,
by forbiding a user to log in the platform.
Workspace level
Only the owner of the workspace
can remove it (or the
ADMINusers).Group, Datasource, table, field, relation, dataset, workspace
Only users members of a manager group can
manage (CRUD) groups, datasources, etc.
Record
A record is, eg, a row in a table for a database,
or a record in an API like BaseRow / AirTable.
At this level, a user can access records
through Access Control List rules.
Actions on tables
We distinguish 4 actions on a record : create, read, update, delete.
Each user can be member of one or several workspace's group.
Each group has a policy in the workspace.
Each policy define rules at the table level, composed by :
{ id: {userId} }{ id: {groupId} }Some tables can be available for creation,
and other ones only for reading, depending on
the policy defined by the workspace's managers.
Rules at table level
Rules are filters on table.
Let's take an example.
We have a database containing birdhouses,
that are installed on parcels,
and each parcel is related to a farm.
Farm < Parcel < BirdhouseEach farm is owned by a farmer.
Each farmer has a user account on the platform.
A workspace contains a datasource for this database.
Each farmer is member of a group that is equivalent
of a farm.
We have in the workspace a mapping table
matching the group id and the farm id
in the database.
The use case is to display all birdhouses
for a farmer.
We would like to show the farmer
only the birdhouses that are on its parcels.
For this, we need to filter birdhouses
by
parcel > farm id.This should give us the following rules table:
{ id: {mappingFarmId} }{ farm_id: {mappingFarmId} }{ farm_id: {mappingFarmId} }{ lck_acl_parcel:farm_id : {mappingFarmId} }{ lck_acl_parcel:farm_id : {mappingFarmId} }At the engine level (under the hood),
the
lck_acl_parcelis a dedicated aliasto join the
parceltable.::: warning
The
lck_acl_prefix is a reserved prefix.You should not name your table like this.
:::
Access on table fields
A read/write permission can be defined
the same way at the field level.
{ id: {mappingFarmId} }{ farm_id: {mappingFarmId} }{ farm_id: {mappingFarmId} }{ lck_acl_parcel:farm_id : {mappingFarmId} }{ lck_acl_parcel:farm_id : {mappingFarmId} }These rule should work both sides,
server and client side, to be isomorphic.
This implies the data
lck_acl_parcel:farm_idto be available on the client side.
::: info
Policy rules are available on the client side.
This allows isomorphic security checks.
:::
Group level
A group is a user set,
allowing to have a logical unit.
Manager group
A group can be a manager one.
In this case, all users of this group
can manage the workspace.
Group mapping
To allow matching between a group
and a datasource entity (= table in a database),
LocoKit provide a mapping table for a group.
mappingFarmIdmappingFarmId(not sure it will be sufficient, maybe there is sthg to do at the group or workspace level to specify the group has variables availalble in these rules ?)
User mapping
We need to do the same at the user level ?
TODO:
Beta Was this translation helpful? Give feedback.
All reactions