-
Notifications
You must be signed in to change notification settings - Fork 2
How to use Rights API and setup permissions
The Rights API (see also its Swagger online doc UI in the Playground) allows to set ACLs (Access Control List) on each Resource.
Those ACLs may contain u_[username] or groups defined in Kernel using User Directory or Social API or (DEV MODE ONLY) mock auth conf.
Said groups are provided in "sub_groups" in the Introspection endpoint's reponse that validates the token. In Spring / Java, they are the OAuth token's GrantedAuthorities.
To create such groups, you must use the User Directory API (or Social API, but it's not ready yet) provided by the OASIS Kernel.
There also are Model-wide configurable "shortcuts" for handling default cases in an efficient way by skipping Resource-level permissions checking.
Here are unit tests that can be useful for understanding the rights API (the testAddRightAndVerify method might be of some help) :
Here is an explanation with an example :
A user Bob has a right list set on him in the Kernel. At our level, this list simply consists in a list of strings. Let's say Bob has the following list of rights : [ "group_a", "group_b" ]
Now let's look at the Datacore side. There are two types of rights : rights on Models (high-level) and rights on resources (low-level). For now, the rights API can only deal with rights on resources.
The rights on a resource are made of three lists : readers, writers, owners.
These three lists are lists of strings that can be set as wanted with the rights API of the Datacore (it is not yet possible to do it at resource creation though).
These lists of rights are the same type as those that can be found on users in the Kernel. Meaning that when a user wants to access a resource, the Datacore will determine whether each right of the user (e.g. "group_a", "group_b", etc.) is contained by the rights on the resource (readers, writers, owners).
For instance if a resource has the string "group_a" in its writers list, and Bob has "group_a" in his list of rights in the Kernel, then Bob will have the writing permissions on this resource.
There are also "user" groups prefixed with "u_" which are special rights set up by default by the datacore when a resource is created. When Bob (whose ID is 3454-4343-590954) creates a resource in the datacore, the list of owners of that resource will automatically be set to [ "u_3454-4343-590954" ]. At kernel level, there will be no need to define "u_3454-4343-590954" in Bob's rights list as the Datacore will do it automatically when user infos are filled in.
In the Datacore, users are identified by their field "sub" read from the Kernel.
Finally, concerning rights on Models, in the same way there are several lists that contain rights (those are on DCSecurity of DCModel). See the comments in the code below that explain precisely what each permission does :