Version 9.6	SEARCH   CONTENTS   |   PDF BOOKS   |   HOME   UP   PREV   NEXT

In CentraSite, access control is enabled through a system of roles and permissions. A permission enables a user to perform a specified operation on a specified object. Permissions also enable users to work with specified parts of the CentraSite Control user interface. A role is a collection of permissions that can be assigned to an individual user or a group. The roles to which you belong and the permissions they includes dictate what portions of the CentraSite Control user interface you see, what objects you can work with, and what operations you can perform.

This section describes how you use permissions and roles to apply access control to the objects in your registry.

• About Permissions

• About Roles

About Permissions

A permission enables a user to perform a specified operation on a specified object. Permissions also enable users to work with specified parts of the CentraSite Control user interface. It is largely CentraSite's system of permissions and roles that enables it to manage and maintain the separation of organizations in the registry.

Within CentraSite, there are two basic types of permissions: instance-level permissions and role-based permissions.

• Instance-level permissions enable access to one specific instance of an object. They provide very fine-grain control over objects in the registry. You can use an instance-level permission, for example, to give one specific user the ability to modify one particular asset in the catalog. Instance-level permissions are granted directly to individual users or to groups.

• Role-based permissions enable access to an entire class of objects or give users the ability to perform certain general operations in CentraSite. Role-based permissions provide coarse-grain control over the objects in the registry. You might use role-based permissions, for example, to allow a group of users to edit all of an organization's assets. Role-based permissions are not granted directly to individual users or groups. Role based permissions are assigned to roles, and the roles are assigned to individual users or groups.

• Instance-Level Permissions

• Role-Based Permissions

• Combining Role-Based and Instance-Level Permissions

Instance-Level Permissions

An instance-level permission enables access to:

• A specific instance of an object in the registry

• A specific folder in the repository

• A specific file in the repository

Instance-level permissions are granted at the following levels: View, Modify and Full.

The following table describes the capabilities that each level gives to a user. Note that each level of access inherits the capabilities of the preceding level. That is, each level implicitly includes the lower levels of access. In CentraSite's permission model, it is not possible to give a user delete permission without also giving that user modify permission. The Full permission, which enables a user to delete an object, implicitly gives the user Modify and View permissions as well.

Permission Levels on Registry Objects

Permission Levels on Repository Folders

Permission Levels on Repository Files

On Which Objects Can You Assign Instance-Level Permissions?

You can assign instance-level permissions to the following types of registry and repository objects:

• Assets (of any type)

• Design/change-time policies

• Run-time policies

• Report templates

• Taxonomies

• Repository folders

• Repository files

Implicit View Permissions on Registry Objects

CentraSite grants implicit View permission to all users on the following types of registry objects:

• Organizations

• Users

• Groups

• Roles

• Design/change-time policies

• Taxonomies

The View permission that CentraSite grants to users on these objects is permanent and irrevocable. It cannot be taken away from users through any instance-level or role-based permission.

Who Can Assign Instance-Level Permissions?

To assign instance level permissions to registry or repository objects, you must have Full permission on the object itself or belong to a role that includes a permissions that effectively grants you Full access to the object.

By default, a user has implicit (and irrevocable) Full permission on all of the objects that he or she owns. Consequently, the object owner is one user that is always permitted to set the instance-level permissions on an object.

How to Assign Instance-Level Permissions

For information about how to set instance-level permissions on registry and repository objects, see the following procedures in the CentraSite user documentation.

Role-Based Permissions

Role-based permissions enable access to an entire set of objects or give users the ability to perform certain operations in CentraSite. Unlike instance-level permissions, which are assigned directly to individual users or groups, role-based permissions are assigned to roles, and roles are assigned to users and groups. You cannot assign a role-based permission to a user or group directly.

There are two basic types of role-based permissions:

• Permissions that enable access to areas of the CentraSite Control user interface.

• Permissions that enable users to create and/or work with certain types of registry and repository objects.

Some permissions are granted implicitly when you assign other permissions.

These topics are described in the following sections:

• Permissions that Enable Access to Areas of the User Interface
• Permissions that Enable Access to Objects
• Implication of Additional Permissions
• The Role-Based Permissions in CentraSite

Permissions that Enable Access to Areas of the User Interface

Role-based permissions include a set of permissions that enable access to certain features and screen sets in the CentraSite Control user interface. These permissions determine which tabs a user sees in the navigation bar in CentraSite Control. For example, CentraSite will not display the navigation bar's Policies profile to a user unless the user has the "Use the Policy UI" permission. The UI-related permissions also include permissions that enable users to view certain logs and use certain controls in CentraSite Control.

Note:
The user interface permissions apply only to the CentraSite Control user interface. They do not affect access to features or screen sets in the CentraSite plug-in for Eclipse.

By default, all CentraSite users have implicit (and irrevocable) permission to use the Asset Catalog area of the CentraSite Control user interface. To use the other parts of the user interface, a user must belong to a role that includes the appropriate user interface permission either explicitly (i.e., the role includes the permission itself) or implicitly (i.e., the role includes a permission that implicitly grants the UI permission). For more information about implicitly granted permissions, see Implication of Additional Permissions.

The following table describes the user interface permissions that are available in each CentraSite edition:

For a complete description of the user interface permissions, see The Role-Based Permissions in CentraSite.

For more information about CentraSite editions, see the section CentraSite Editions in the document Introducing CentraSite.

Permissions that Enable Access to Objects

Role-based permissions include a second type of permissions that enable users to create and/or work with an entire class of objects.

Generally speaking, these types of role-based permissions grant a specified level of access on objects of a specific type. For example, the "Modify Assets" permission grants Modify-level access on all objects of the type Asset. Role-based permissions enable you to apply access controls over an entire class of objects instead of assigning permissions on each object individually.

Levels of Access Granted by the Role-Based Permissions

If a role-based permission grants access to an object, the name of the permission includes one of the following terms to indicate which level of access the permission provides.

Be aware that CentraSite does not provide role-based permissions at all levels for all object types. Access to certain objects types can only be granted at the Manage level, for example. For a complete list of the role-based permissions, see Predefined Roles in CentraSite.

System-Level vs. Organization-Level Permissions

Role-based permissions that enable access to objects are either organization-specific or system-wide.

System-Level Permissions

A system-wide permission grants access to objects that are available to all organizations, such as taxonomies and asset types. Additionally, some system-wide permissions grant access to all objects of given type in any organization in the registry/repository.

The following table describes the system-level permissions that are available in each CentraSite edition:

Organization-Level Permissions

An organization-specific permission grants a specific level of access to all objects of a given type within a specified organization. Permissions that enable access to assets, policies and lifecycle models are organization-specific.

The following table describes the user interface permissions that are available in each CentraSite edition:

For a complete description of the system-level and organization-level permissions, see The Role-Based Permissions in CentraSite.

For more information about CentraSite editions, see the section CentraSite Editions in the document Introducing CentraSite.

Implication of Additional Permissions

Most role-based permissions grant additional permissions by implication. That is, the permission grants not only the permission that its name indicates, it grants additional implied permissions.

For example, any permission that grant access to a particular type of object automatically includes (by implication) the UI permissions required to work with that object. Users that belong to roles that include the "Manage Taxonomy" permission, for instance, automatically receive the "Use the Administration UI" permission by implication.

The "Manage Organizations" permission is an example of another permission that grants additional permissions by implication. This permission, when given at the system-level, essentially implies all other role-based permissions. Consequently, a user with "Manage Organizations" permission at the system-level can manage virtually any object in any organization.

For a description of the individual permissions, and the permissions they each imply, see The Role-Based Permissions in CentraSite.

The Role-Based Permissions in CentraSite

The following table describes the individual permissions and their implied permissions in CentraSite, if any.

Combining Role-Based and Instance-Level Permissions

When a user receives multiple permissions for the same object, the permissions are combined and the user receives the union of all the permissions.

For example, if you give a user instance-level View permission on an asset and that user belongs to a role that gives him or her Modify permission on the asset, that user will get View permission plus Modify permission on the asset (or, in effect, Modify permission since it implies View permission).

You will need to keep this concept in mind when granting role-based access to a large group of users (particularly to an entire organization). Anytime you use a role-based permission to give a group of users access to the entire set of assets in an organization, you can no longer use instance-level permissions to reduce the level of access for those users. For example, when everyone in your organization is given "View Assets" permission, you no longer have a way to use instance-level permission to selectively hide assets from certain users in the organization. In effect, the View permission becomes irrevocable for the users in the organization.

About Roles

A role is a collection of role-based permissions. Assigning a role to a user gives the user the permissions specified in the role. Roles can be assigned to individual users or to groups.

CentraSite provides many predefined roles for you to use. You can also create custom roles as needed.

• Predefined Roles in CentraSite

• Creating and Managing Roles

Predefined Roles in CentraSite

CentraSite provides many predefined roles. These roles fall into two categories:

• System-level roles, which contain permissions for working with system-wide objects (i.e., objects that affect or are available to all organizations). Asset types and taxonomies are examples of system-wide objects.

  The following table identifies the predefined system-level roles that are available in each CentraSite edition:

  Available Roles in CentraSite full-feature edition	Available Roles in Community Edition
  CentraSite Administrator (CSA)
  Asset Type Administrator (ATA)
  Operations Administrator (OPA)
  Guest (G)

  For detailed information about these roles, see System-Level Roles.

• Organization-level roles, which contain permissions for working with organization-specific objects (i.e., objects that belong to and are used by one particular organization). Assets, policies and lifecycle models are examples of organization-specific objects. CentraSite maintains a set of organization-level roles for each organization in the registry/repository.

  The following table identifies the predefined organization-level roles that are available in each CentraSite edition:

  Available Roles in CentraSite full-feature edition	Available Roles in Community Edition
  Organization Administrator (OA)
  Asset Administrator (AA)
  Policy Administrator (PA)
  Asset Provider (AP)
  Asset Consumer (AC)

For detailed information about these roles, see Organization-Level Roles.

The following table summarizes the permissions that CentraSite assigns to each of the predefined roles by default. Be aware that the permission assignments for most of these roles can be customized by an administrator. If an administrator has customized a predefined role at your site, it might have different permissions than what is shown here.

System-Level Roles

The following predefined roles in CentraSite are system-level roles. Generally speaking, these roles contain permissions that enable users to work with system-wide objects. Some of these roles also enable users to manage (view, edit or delete) all instances of a given object type in any organization in the CentraSite registry/repository. For example, a user in the Centrasite Administrator role has, in effect, Full permission on every asset in every organization.

The main characteristic that distinguishes a system-level role from an organization-level role is that a system-level role is not generated for each new organization.

As noted in the following descriptions, some system-level roles can be edited and/or deleted and others cannot.

• CentraSite Administrator

  The CentraSite Administrator role includes all available permissions. Users in this role have all the permissions to manage the complete system (that is, users with "superuser" permissions). The CentraSite Administrator only can change the permission set for a system role. Additionally, the CSA has permission to create and delete a system role. This role cannot be modified or deleted.

• Asset Type Administrator

  Users in the Asset Type Administrator role can manage the type definitions and taxonomies in CentraSite.

• Operations Administrator

  Users in the Operations Administrator role can manage the operational aspects of CentraSite. For example, the Runtime Event Types and Runtime Targets.

• Guest

  Users in the Guest role can browse and use the asset catalog.

For a summary of the permissions that CentraSite assigns to these predefined roles by default, see Predefined Roles in CentraSite.

Organization-Level Roles

CentraSite automatically populates any new organization that is created with the following organization-level roles and permissions.

• Organization Administrator

  Users in the Organization Administrator role can manage objects within a particular organization. This includes all child organizations of that organization. This role cannot be modified or deleted.

• Asset Provider

  Users in the Asset Provider role can create new assets and view assets. This role also has the ability to register users to consume assets.

• Asset Consumer

  Users in the Asset Consumer role can view all assets. This role also has the ability to register users to consume assets.

• Asset Administrator

  Users in the Asset Administrator role can manage all assets within the organization.

• Policy Administrator

  Users in the Policy Administrator role can manage design/change-time and run-time policies within an organization.

Note:
By default, the Asset Provider and Asset Consumer roles are automatically assigned to the Users group that CentraSite creates for an organization. Consequently, every user in an organization is assigned these roles. If you do not want every user in your organization to have these roles (for example, if you do not want every user to have the Asset Provider role), edit the role assignments for your organization's Users group. For procedures, see Assigning Roles to a Group.

For a summary of the permissions that CentraSite assigns to these predefined roles by default, see Predefined Roles in CentraSite.

Creating and Managing Roles

You can create custom roles in CentraSite as needed. Custom roles can contain system-level permissions and/or organization-level permissions. A custom role can contain organization-level permissions for multiple organizations (i.e., you can create a role that allows a user to manage the policies in two different organizations). You can also modify many of the predefined organizations that CentraSite installs. For information about which predefined roles can be modified, see the topics System-Level Roles and Organization-Level Roles in the section About Roles and Permissions in the document Users, Groups, Roles and Permissions.

• Who Can Create and Manage Roles?
• Creating Custom Roles
• Viewing and Editing Roles
• Deleting Roles

Who Can Create and Manage Roles?

To create and manage (i.e., view, edit and delete) roles for an organization, you must belong to a role that has the "Manage Users" permission for the organization. Users in the Organization Administrator role have this permission, although an administrator can assign this permission to other roles.

Note:
Users that belong to a role that includes the "Manage Organizations" permission have the "Manage User" permission by implication. Such users can create and mange groups in any organization to which their "Manage Organizations" permission applies.

Be aware that you when you define a role, you cannot assign permissions to the role that you do not have yourself. Therefore, if you belong to the Organization Administrator role (and you have no additional role assignments), you cannot create roles that have any additional permissions than the ones provided by the Organization Administrator role. For example, you could not create a role that included system-level permission or permissions for other organizations. A user with the "Manage Organizations" permission at the system-level (such as someone in the CentraSite Administrator role) would need to do that.

Creating Custom Roles

To create a custom role

1. In CentraSite Control, go to Administration > Users > Roles.

2. On the Roles page, click Add Role.

3. In the Role Information panel, specify the following fields:

   In this field...	Do the following...
   Name	Enter a name for the new role. A role name can contain any character (including spaces). Note: The role name must be unique within an organization.
   Description	Optional. Enter a short description for the new role. This description appears when the user displays the list of roles in CentraSite Control.
   Organization	Specify the organization to which this role belongs. (The drop-down list only displays organizations for which you have "Manage Users" permission.)

4. In the Permissions panel, click Assign permissions.

5. In the Assign Permissions dialog box, do the following

   1. Select the permission(s) that you want to assign to this role. (The list will only contain permissions that you are authorized to assign.)

   2. Click OK.

6. Click Save to create the new custom role in the CentraSite registry/repository.

Viewing and Editing Roles

You use the Edit Role page to examine and/or edit the properties of a role. When viewing or editing a role, keep the following points in mind:

• You cannot modify the CentraSite Administrator role.

• You cannot modify the Organization Administrator.

To view or edit the properties of a role

1. In CentraSite Control, go to Administration > Users > Roles.

2. By default, all of the available roles are displayed.

   If you want to filter the list to see just a subset of the available roles, type a partial string in the Search field. CentraSite applies the filter to the Name column. The Search field is a type-ahead field, so as soon as you enter any characters, the display will be updated to show only those roles whose name contains the specified characters. The wildcard character "%" is supported.

3. Locate the role that you want to view or edit.

4. From the role's context menu, select the Details command.

5. Examine or modify the attributes on the Edit Role page as necessary.

   Field	Description
   Name	The name of the role. A role name can contain any character (including spaces). Note: The role name must be unique within an organization.
   Description	Additional comments or descriptive information about the role.
   Organization	Read-only. The organization to which the role belongs.
   Permissions	The settings on this profile identify the permissions that are assigned to this role.

6. If you want to add or remove permissions to/from the role, select the Permissions profile and do the following:

   1. To add permissions to the role, click Assign Permissions and select the permission that you want to add.

   2. To remove permissions from the role, select the permissions that you want to remove and click Remove.

7. If you have edited the settings on the Edit Role page, click Save to save the updated role.

Deleting Roles

You use the Roles page to delete the custom roles. When deleting a role, keep in mind that you cannot delete the CentraSite Administrator role or the Organization Administrator role (not even if you belong to the CentraSite Administrator role).

To delete a role

1. In the CentraSite Control, go to Administration > Users > Roles to display the roles list.

2. Enable the checkbox next to the name of the role that you want to delete.

3. Click Delete.

   When you are prompted to confirm the delete operation, click OK.

You can delete multiple roles in a single step. The rules described above for deleting a single role apply also when deleting multiple roles.

Important:
If you have selected several roles where one or more of them are predefined roles, you can use the Delete button to delete the roles. However, as you are not allowed to delete predefined roles, only roles you have permission for will be deleted. The same applies to any other roles for which you do not have the required permission.

To delete multiple roles in a single operation

1. In CentraSite Control, go to Administration > Users > Roles to display the roles list.

2. Mark the checkboxes of the roles that you want to delete.

3. From the Actions menu, choose Delete.

   When you are prompted to confirm the delete operation, click OK.

www.softwareag.com

Copyright © 2005-2014 Software AG, Darmstadt, Germany.

SEARCH   CONTENTS   |   PDF BOOKS   |   HOME   UP   PREV   NEXT