Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add endpoints for effective permissions #88

Closed
gorbunkov opened this issue Jan 20, 2020 · 2 comments
Closed

Add endpoints for effective permissions #88

gorbunkov opened this issue Jan 20, 2020 · 2 comments
Assignees
Labels
state: fixed Fixed by the developer type: enhancement New feature or request ver: 7.2.0 Fixed in version ver: 7.3.0 Fixed in version
Milestone

Comments

@gorbunkov
Copy link
Contributor

The /rest/v2/permissions/entities endpoint should return effective permissions for all entities operations:

[
   {
       "t": "some_Entity:create",
       "v: 0
   },
   {
       "t": "some_Entity:read",
       "v: 1
   },
   ...
]

The /rest/v2/permissions/entityAttributes endpoint should return effective permissions for all entity attributes:

[
    {
        "t": "sample_Author:createTs",
        "v": 2
    },
    {
        "t": "sample_Author:createdBy",
        "v": 2
    },
   ...
]
@gorbunkov
Copy link
Contributor Author

gorbunkov commented Jan 24, 2020

An alternative solution. There will be a single endpoint: /rest/v2/permissions/effective. The endpoint will return a data structure that represents an "effective" user role that is built by joining all the roles assigned to the user.

Effective role JSON example:

{
	"explicitPermissions": {
		"entities": [
			{
				"target": "sample_Author:create",
				"value": 1
			},
			{
				"target": "sample_Author:read",
				"value": 1
			},
			{
				"target": "sample_Book:create",
				"value": 0
			}
		],
		"entityAtributes": [
			{
				"target": "sample_Author:name",
				"value": 2
			},
			{
				"target": "sample_Author:email",
				"value": 1
			}
		],
		"specific": [
			{
				"target": "cuba.restApi.enabled",
				"value": 1
			},
			{
				"target": "some.other.permission",
				"value": 0
			}
		]
	},
	"defaultValues": {
		"entityCreate": 0,
		"entityRead": 1,
		"entityUpdate": 1,
		"entityDelete": 1,
		"entityAttribute": 2,
		"specific": 0
	},	
	"undefinedPermissionPolicy": "ALLOW"
}

The explicitPermissions property contains permissions explicitly granted by any user role.
If there is no explicit permission, then in order to get the value, the client must look at the defaultValues property and find the default value for the proper operation there (e.g. entity creation or accessing an entity attribute).

If the default for the operation is not defined, then take the value from the undefinedPermissionPolicy property (ALLOW or DENY). DENY is always 0, ALLOW is 2 for entitiy attribute access and is 1 for all other cases.

The /rest/v2/permissions/effective endpoint has the following boolean parameters that define which permission types should be returned:

  • entities
  • entityAttributes
  • specific

E.g. /rest/v2/permissions/effective?entities=true&entitiyAttributes=true will return explicit permissions and defaults for entities and attributes. Explicit permissions and default value for specific won't be returned.

@gorbunkov gorbunkov assigned gorbunkov and unassigned t2-cuba Jan 27, 2020
@gorbunkov gorbunkov assigned gorbunkov and natfirst and unassigned gorbunkov Jan 31, 2020
@gorbunkov gorbunkov added ver: 7.2.0 Fixed in version ver: 7.3.0 Fixed in version labels Jan 31, 2020
gorbunkov added a commit that referenced this issue Feb 10, 2020
 Defaults for permission type have been removed. Wildcard permissions are returned instead.
@gorbunkov
Copy link
Contributor Author

The JSON result have been modified. The default values section is not returned any more. Wildcard permissions are returned instead.

Example:

{
	"explicitPermissions": {
		"entities": [
			{
				"target": "sample_Author:create",
				"value": 1
			},
			{
				"target": "sample_Author:read",
				"value": 1
			},
			{
				"target": "sample_Book:create",
				"value": 0
			},
			{
				"target": "*:create",
				"value": 1
			},
		],
		"entityAtributes": [
			{
				"target": "sample_Author:name",
				"value": 2
			},
			{
				"target": "sample_Author:email",
				"value": 1
			},
			{
				"target": "sample_Author:*",
				"value": 2
			},
			{
				"target": "*:*",
				"value": 2
			}
		],
		"specific": [
			{
				"target": "cuba.restApi.enabled",
				"value": 1
			},
			{
				"target": "some.other.permission",
				"value": 0
			}
		]
	},
	"undefinedPermissionPolicy": "ALLOW"
}

For entity permissions the following wildcard targets are supported:

  • *:create
  • *:read
  • *:update
  • *:delete

For attribute permissions a wildcard may be defined for a particular entity or for all entities:

  • sample_Book:*
  • *:*

After these changes, an algorithm to evaluate a permission should be the following (example is for attribute permission Author.email:

  1. Find explicit value (sample_Author:email). If not null, return it
  2. Find entity level wildcard (sample_Author:*). If not null, return it
  3. Find global wildcard value (*:*), if not null, return it
  4. Return undefined permission value

For entity operation the algorithm will be (example for Author read operation):

  1. Find explicit value (sample_Author:read). If not null, return it
  2. Find global wildcard (*:read). If not null, return it
  3. Return undefined permission value

For specific permission the only possible wildcard is *

gorbunkov added a commit that referenced this issue Feb 10, 2020
Defaults for permission type have been removed. Wildcard permissions are returned instead.
@natfirst natfirst added the state: fixed Fixed by the developer label Feb 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
state: fixed Fixed by the developer type: enhancement New feature or request ver: 7.2.0 Fixed in version ver: 7.3.0 Fixed in version
Projects
None yet
Development

No branches or pull requests

3 participants