Initial role setup occurs during installation. Please refer to the Installation guide for the TopBraid Suite product you are using (EDG, EVN, TBI, TopBraid Live, etc.). For a Role to be used in a TopBraid server, the role must: To define roles in the permitted security roles, enter a comma-delimited list of roles in the TopBraid Deployment Descriptor Configuration Page during installation. The following figures show the most common setups for LDAP and in-memory database (conf/tomcat-users.xml), where the role names in either case are Role1, Role2 and Role3. Note that these roles are defined in LDAP/Tomcat and are not editable from within TopBraid. Once installation is completed, the Server Administration page can be accessed by users associated with a role having access to the resource ANY_ROLE. The Permission Group Management page is found at Server Administration > Permission Group Management. This setup replaces the Superuser setting in versions of TopBraid Suite prior to version 4.4. TopBraid includes a default administrator group, named AdministratorGroup, which allows access to all resources. The group must be defined for at least one Role to prevent being locked out of the system. To remove AdministratorGroup for a specific role the user must define another role for the group. If AdministratorGroup is defined for at least one other role it can be removed from ANY_ROLE. The Permission Group Management UI page: To navigate between them, click on the column name as shown in the following figure. Definitions for concepts appearing in this user interface are as follows: To define a new permission group based on an existing role, first select a role, then click on the Add Group button and choose option New Group. Provide a name as shown in the figure and click 'Create Group' in the dialog. Groups can be associated with one or more resource with access permissions Resource permissions are defined with the Add Resources button in the figure below. Resource types are defined in Section 3. You can choose a listed wildcard resource or choose from a list of specific resources. In this example, we add a readAnyGraph group to a role (UpdateDenyRole). Then follow the menu from left to right to add Resources, Wildcards, or Projects as desired. Upon choosing the resource type the Permission Group Management view will display a set of permissions corresponding to the aforementioned CRUD+E resource permissions. IMPORTANT: When you want to 'remove' a group from a particular role – use the X icon next to the group name. When you want to 'delete' a group completely – use the trashcan icon. (note that this will remove the group from all roles that were associated with it. Project names should not contain a space - if they do you will get an error trying to expand them. Please correct Project name and reupload with no spaces. Generally, roles are defined in a User Directory such as those defined in LDAP or Tomcat's in-memory user database. Each user should belong to a role in the system. Choose Permission Group Management from the Administrative Functions Menu. Choose a role from the "Roles" column: AdministratorGroup is a system group that allows for administration access. Users belonging to role(s) that is assigned to this group will have administrative access. By Default, ANY_ROLE belongs to the AdministratorGroup. It's best to assign another role (e.g. 'administrator') to belong to 'AdministratorGroup' as shown above, so that you can remove the association of AdministratorGroup from ANY_ROLE when you install the system. This will prevent every user to have administrative functions. Select AdministratorGroup, it shows that it has all the CRUD-E permission for any resource. Use the 'GlobalUserRole' and add a group, resource, and project from the menu. Then adjust the permissions as needed. Select 'GlobalUserRole' role on the left, Click on 'Add Group' button, then select the newly added group "readAnyGraphGrp", it shows the default set of resource permissions for this group, this only gives Read permission to all graph resources. If you would like to have a specific set of resources permission, you can create a new group and start adding resources to the group. Click 'Add Group' and select 'New Group' to create a new group called it 'ReadonlyGroup'. Then click 'Add resources' for that group, select the resources from the tree. Click next to choose graph imports or 'Add resources' to the group without dealing with permission of the import. Add wildcard if needed: Configure the CRUD-E permissions as needed: One or more resource definition is associated with each Group. The resource definition consists of a resource, either PROJECT (via the 'Add Resource' button) or ANY (via the 'Add Wildcard' button) and the CRUD+E access type definition. The choices are described in the following sections. The two resource types are PROJECT and ANY. Clicking the 'Add Resources' button will bring up a window that shows a list of projects in the workspace, you can choose the individual projects (multi-select) or drill down the tree to select a specific file within a project. Instead of selecting project resource, you can choose 'ANY' by clicking the 'Add Wildcard', select the radio button for a type of 'ANY' resource of your choice. Only one can be selected among this list The defined ANY resource types are as follows. These are used to allow administrators to define the different kinds of resources available in TopBraid Suite. The access types are as follows: TopBraid TBL provides features that let users easily manage access to TBL asset collections (taxonomies, ontologies, tag sets, etc.) on a per collection basis. This is accomplished by assigning, in a context of a specific asset, the TBL asset-collection permissions manager, editor, and viewer to user id’s or Tomcat Realms roles . These assignments can be set by the manager of each TBL asset collection. Given the use of TBL User Roles, the best practice is to define a small set of groups with access for the Eclipse/Equinox project that contains connectors to TBL data. One approach is to provide all TBL users (via their roles) with full CRUD+E access. This is depicted as follows, where the Eclipse/Equinox project is the default "Repositories". Anyone is of the role 'ExpertRole' belongs to 'SME Group' (subject matter expert), which has full permission in the Repositories project. Another approach is to define access groups for Admin, general user (read/update/execute), and read-only user. Start by creating three groups, named "SME Group", "Editor Group", and "ReadOnly Group" in this example. Note the access types for each. In this setup only users in 'ExpertRole' can create and delete in the 'Repositories' Projects with Read, Update and Execute rights as shown above. Users in the 'TeamLeadRole' will be able manage, edit, and view things in the 'Repositories' Projects, but not create or delete TBL vocabulary/asset . Depending on the User Roles assigned in the vocabulary/asset, any user in 'ExpertRole' and 'teamLeadRole' can be assigned 'manager', 'editor' or 'viewer' privileges in TBL User Roles. Users in the 'GlobalUserRole' can only read anything in the 'Repositories' projects. If a 'GlobalUserRole' user is assigned 'manager' or 'editor' EVN User Roles for a given vocabulary/asset, they are allowed to manage or edit such particular vocabulary. In other words, the vocabulary/asset manager assignment for a role in a given vocabulary/asset overrides the specification of such role set up by the system administrator in this permission group management page. Users in multiple roles will be given the union of the assigned Group access rights. TopBraid supports the SPARQL Endpoint update with two levels of security. First, the Server Configuration Parameter "Enable SPARQL updates" must be set to "true" from its default value (see Server Configuration Parameters ). Secondly. the user must belong to a role that allows SPARQL Endpoint updates. In addition, roles can be defined that explicitly deny access to SPARQL Endpoint update: To block a roles from using a SPARQL endpoint to update graphs - assign those set of users a role and assign the SPARQLUpdateDenyGrp permission group to that role. To allow roles to use a SPARQL endpoint to update graphs - assign those set of users a role and assign the SPARQLUpdateAllowGrp permission group to that role. Page Contents
TopBraid Permission Group Management
Installation and Admin Setup
Access to the Server Administration page
AdministratorGroup
Defining new groups
Defining resource permissions
Configure Permissions
Example of adding groups to a role
Resource Permissions
Resource Types
Definition of ANY Resource Types
Definition of Access Types (CRUD+E)
Suggested setup for TopBraid TBL
SPARQL Endpoint Update