Skip to main content

User Actions, Roles, and Permissions

This section is about granting and revoking permissions for users and roles, and other user / role actions in Timbr.

Granting and revoking user or role permissions​

The pattern for GRANTING PERMISSIONS is as follows:

GRANT [EDIT|QUERY|ACCESS] ON <ALL> {resources} [TO USER|TO ROLE] {username_or_role_name} <WITH GRANT OPTION>

The pattern for REVOKING PERMISSIONS is as follows:

REVOKE [EDIT|QUERY|ACCESS] ON <ALL> {resources} [FROM USER|FROM ROLE] {username_or_role_name} <WITH GRANT OPTION>

Pattern explanation:

  • [EDIT|QUERY|ACCESS] - First level permission. Must choose one of EDIT, QUERY, or ACCESS
    • EDIT - grants access to create, modify or remove a resource
    • QUERY - grants access to view the metadata and query a resource
    • ACCESS - grants access to view the metadata of a resource
  • ALL - Optional flag that indicates the entire scope of a permission
    • In the context of ontology, means [EDIT|QUERY|ACCESS] to all resources for all ontologies, a specific ontologies, or all resources of a specific ontology.
    • In the context of EDIT ON ALL datasources means udpate or remove all datasources
    • In the context of EDIT ON ALL users can update or remove all users
    • In the context of QUERY ON ALL users to view all users
    • In the context of EDIT ON ALL roles can update or remove all roles
    • In the context of QUERY ON ALL roles to view all roles
  • {resources} - A hierarchy of different resources, each with a scope drilldown denoted by a dot .. The list of first level resources are:
    • ontology - Second level permission. If only the first and second levels are specified, and it has the ALL flag set -Then it represents [EDIT|QUERY|ACCESS] permissions for all ontologies. To grant permission to create ontologies, dont specify the ALL flag, and the EDIT permission must be set - Then it means permissions to Create ontologies
      • {ontology name} - Third level permission. If only the first, second, and third levels are specified, and it has the ALL flag then it represents permissions for all resources within a specific ontology. If the next level resource (fourth) is specified then it must be one of the following options:
        • mapping - Fourth level permission. If only the first, second, third, and fourth levels are specified, and it has the ALL flag then it represents permissions for all mappings within a specific ontology. If the next level resource (fifth) is also specified then it Can't contain the ALL flag, and it represents a permission to a specific mapping in the ontology.
        • view - Fourth level permission. If only the first, second, third, and fourth levels are specified, and it has the ALL flag then it represents permissions for all views within a specific ontology. If the next level resource (fifth) is also specified then it Can't contain the ALL flag, and it represents a permission to a specific view in the ontology.
        • schema - Fourth level permission. If only the first, second, third, and fourth levels are specified, and it has the ALL flag then it represents permissions for all schemas within a specific ontology. If the next level resource (fifth) is also specified then it Can't contain the ALL flag, and it represents a permission to a specific schema in the ontology which must be one of timbr, dtimbr, etimbr, vtimbr, or gtimbr
        • query - Fourth level permission. If only the first, second, third, and fourth levels are specified, and it has the ALL flag then it represents permissions to view the query history and the running queries of a specific ontology. The next level resource (fifth) is also specified then it Can't contain the ALL flag and it must be one of query_history or running_queries
    • datasource - Second level permission. If only the first and second levels are specified, and it has the ALL flag set -Then it represents [EDIT|QUERY|ACCESS] permissions for all datasources. To grant permission to create datasource, don't specify the ALL flag, and the EDIT permission must be set
      • Then it means permissions to Create datasources
      • {datasource name} - Third level permission. If only the first, second, and third levels are specified it represents permissions for for a specific datasource
    • user - Second level permission. If only the first and second levels are specified, and it has the All flag set - Then it must have either the EDIT (first level) option set which represents creating / updating / removing all users. Or the VIEW (first level) option set which represents viewing all the users.
      • {user name} - Third level permission. Can be created only when the first level EDIT option is set, and it represents updating / removing a specific user
    • role - Second level permission. If only the first and second levels are specified, and it has the All flag set - Then it must have either the EDIT (first level) option set which represents creating / updating / removing all roles. Or the VIEW (first level) option set which represents viewing all the roles.
      • {role name} - Third level permission. Can be created only when the first level EDIT option is set, and it represents updating / removing a specific role
  • WITH GRANT OPTION - Optional flag which represents whether the permission given can be also granted to other users or roles.

Example #1: Grant the user robert permission to create ontologies:

GRANT EDIT ON `ontology` TO USER `robert`;

Revoke the user robert permission to create ontologies:

REVOKE EDIT ON `ontology` FROM USER `robert`;

Example #2: Grant the user robert permission to modify and query all ontologies, and to grant the permission to other users:

GRANT EDIT ON ALL `ontology` TO USER `robert` WITH GRANT OPTION;

Revoke the user robert permission to modify and query all ontologies, and to grant the permission to other users:

REVOKE EDIT ON ALL `ontology` FROM USER `robert` WITH GRANT OPTION;

Example #3: Grant the user robert permission to query only a specific mapping map_concept1 in the test_ontology ontology:

GRANT QUERY ON `ontology`.`test_ontology`.`mapping`.`map_concept1` TO USER `robert`;

Revoke the user robert permission to query only a specific mapping map_concept1 in the test_ontology ontology:

REVOKE QUERY ON `ontology`.`test_ontology`.`mapping`.`map_concept1` FROM USER `robert`;

Example #4: Grant the role manager to edit all users and roles:

GRANT EDIT ON ALL `role` TO ROLE `manager`;
GRANT EDIT ON ALL `user` TO ROLE `manager`;

Revoke the role manager from editing all users and roles:

REVOKE EDIT ON ALL `role` FROM ROLE `manager`;
REVOKE EDIT ON ALL `user` FROM ROLE `manager`;

Example #5: Grant the role ontology_manager to modify the test_ontology ontology and view all of the ontology resources:

GRANT EDIT ON ALL `ontology`.`test_ontology` TO ROLE `ontology_manager`;
GRANT EDIT ON `ontology`.`test_ontology` TO ROLE `ontology_manager`;

Revoke the role ontology_manager from modifying the test_ontology ontology and view all of the ontology resources:

REVOKE EDIT ON ALL `ontology`.`test_ontology` FROM ROLE `ontology_manager`;
REVOKE EDIT ON `ontology`.`test_ontology` FROM ROLE `ontology_manager`;

Example #6: Grant the role external_viewer to see only the metadata of the test_ontology ontology:

GRANT ACCESS ON ALL `ontology`.`test_ontology` TO ROLE `external_viewer`

Revoke the role external_viewer to see only the metadata of the test_ontology ontology:

REVOKE ACCESS ON ALL `ontology`.`test_ontology` FROM ROLE `external_viewer`

Show the permissions of the current user​

Returns the list of permissions for the current user

SHOW PERMISSIONS

Show the permission history log​

Returns a list of permissions changes in an ontology according to the scope of permissions the user has

SHOW PERMISSION HISTORY

Show the users the current user has access to update​

Shows a list of available users which the user has access to udpate

SHOW USERS

Show the roles the current user has access to update​

Shows a list of available roles which the user has access to udpate

SHOW ROLES

Show which users are assigned which roles​

Returns a list of users and associated roles.

SHOW USERS ROLES

Create a security policy over a property​

Required information when creating a new security policy over a property (the curly brackets {} should not be an input, they are used only as a variable substitution):

  • {policy_name} - The intended name for the new policy
  • {property_name} - The property that's being assigned a new policy
  • {filter clause} - The filtered parameter which defines the new policy
CREATE POLICY `{policy_name}` ON PROPERTY `{property_name}` WHERE {filter clause}

Create a security policy over a concept​

Required information when creating a new security policy over a concept (the curly brackets {} should not be an input, they are used only as a variable substitution):

  • {policy_name} - The intended name for the new policy
  • {concept_name} - The concept that's being assigned a new policy
  • {filter clause} - The filtered parameter which defines the new policy
CREATE POLICY `{policy_name}` ON CONCEPT `{concept_name}` WHERE {filter clause}

Create a security policy over a mapping​

Required information when creating a new security policy over a mapping (the curly brackets {} should not be an input, they are used only as a variable substitution):

  • {policy_name} - The intended name for the new policy
  • {mapping_name} - The mapping that's being assigned a new policy
  • {filter clause} - The filtered parameter which defines the new policy
CREATE POLICY `{policy_name}` ON MAPPING `{mapping_name}` WHERE {filter clause}

Create a security policy over a view​

Required information when creating a new security policy over a view (the curly brackets {} should not be an input, they are used only as a variable substitution):

  • {policy_name} - The intended name for the new policy
  • {view_name} - The view that's being assigned a new policy
  • {filter clause} - The filtered parameter which defines the new policy
CREATE POLICY `{policy_name}` ON VIEW `{view_name}` WHERE {filter clause}

Removing a security policy​

Removes the security policy from the knowledge graph.

Required information for removing a security policy (the curly brackets {} should not be an input, they are used only as a variable substitution):

  • {policy_name} - The name of the policy being removed 
DROP POLICY `{policy_name}`

Granting a security policy to a user​

Required information for granting a security policy to a user (the curly brackets {} should not be an input, they are used only as a variable substitution):

  • {policy_name} - The name of the policy being granted
  • {user_name} - The user name being granted the policy
GRANT POLICY `{policy_name}` TO USER `{user_name}`

Revoking a security policy from a user​

Required information for revoking a security policy from a user (the curly brackets {} should not be an input, they are used only as a variable substitution):

  • {policy_name} - The name of the policy being revoked
  • {user_name} - The user name being revoked from the policy
REVOKE POLICY `{policy_name}` FROM USER `{user_name}`

Granting a security policy to a role​

Required information for granting a security policy to a role (the curly brackets {} should not be an input, they are used only as a variable substitution):

  • {policy_name} - The name of the policy being granted
  • {role_name} - The role name being granted the policy
GRANT POLICY `{policy_name}` TO ROLE `{role_name}`

Revoking a security policy from a role​

Required information for revoking a security policy from a role (the curly brackets {} should not be an input, they are used only as a variable substitution):

  • {policy_name} - The name of the policy being revoked
  • {role_name} - The role name being revoked from the policy
REVOKE POLICY `{policy_name}` FROM ROLE `{role_name}`

Show the policies in the Knowledge Graph​

Returns a list of policies that exist in the knowledge graph.

SHOW POLICIES

Show the policies assigned to users and roles​

Returns a list showing which users and roles have which policies assigned to them.

SHOW ASSIGNED POLICIES

Set active datasource per user​

Set an active datasource per user regardless of the default active datasource set in the Knowledge Graph settings

alter user `<username>` set options (`<ontology_name>.active_datasource` = '<datasource_name>')

Reset datasource to default for user​

Restore the default active datasource of a user and align with the Knowledge Graph settings

alter user `<username>` set options (`<ontology_name>.active_datasource` = '')

Query the system table of assigned policies​

Returns a list from the system table showing which users and roles have which policies assigned to them.

SELECT * FROM timbr.SYS_ASSIGNED_POLICIES

Query the system table of existing policies​

Returns a list from the system table showing the existing policies.

SELECT * FROM timbr.SYS_POLICIES

Get Timbr access token for current user​

Returns the Timbr access token value for the current user.

SHOW TOKEN

Get Timbr access token for another user by username​

Returns the Timbr access token value for a specific user.

Required information for retrieving the Timbr access token value for a user (the curly brackets {} should not be an input, they are used only as a variable substitution):

  • {user_name} - The user name associated with the token value
SHOW TOKEN FOR {user_name}