Permissions determine which operations users can perform and which set of objects they can access. There are two types of permissions in CentraSite: instance-level permissions and role-based permissions.
Instance-level permissions enable access to one specific instance of an object in the registry. They provide fine-grain access control over registry objects. You grant instance-level permissions 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 operations in CentraSite. Role-based permissions provide coarse-grain control over objects in the registry. You assign role-based permissions to roles, and you assign the roles to individual users or groups.
The following diagram illustrates the relationships between instance-level permissions, role-based permissions, users, groups and roles.
An instance-level permission gives a specified user or group access to one particular object in the registry. Instance-level permissions, which are granted at the View, Modify or Full level, determine how a specified user or group is allowed to interact with a registry object.
| This Permission Level... | Enables the specified user or group to... |
|---|---|
| View |
|
| Modify |
|
| Full |
|
Note that each permission level inherits the capabilities of the preceding level.
Access control at the instance-level is not supported by all object types in the registry. The following list identifies the types of objects on which you can control access at the instance level.
Assets (of any type)
Supporting documents
Design/Change-time policies **
Run-time policies **
Taxonomies **
Report Templates **
** All CentraSite users have implicit and irrevocable permission to view all instances of these object types. However, you can use instance-level permissions to restrict who can edit and delete them.
Access to other types of objects is controlled using the broader role-based permissions (described below) or is enabled contextually. (Enabled contextually means that an object is a constituent of some other "access-controlled" object. For example, the individual operations and bindings associated with a Web service are objects that can only be accessed within the context of the Service object itself. Therefore, the permissions that control access to the Service object also control access to the service's constituent objects.)
To set permissions on an object, you must have Full permission on the object. You can use the CentraSite Control user interface to assign instance-level permissions to any of the types of objects listed above. Additionally, you can set permissions on the following types of objects using the CentraSite plug-in for Eclipse: assets, taxonomies, report templates and supporting documents.
Besides setting instance-level permissions through the user interface, you can create design/change-time policies to automate the assignment of instance-level permissions on certain types of objects (specifically, assets and policies). For example, you might use a design/change-time policy to automatically extend access to specified groups of consumers when an asset switches to the "Deployed" state.
Assets (of any type) include an additional level of access control called a profile permission. Profile permissions enable you to control access to individual profiles within an instance of an asset.
A profile represents a collection of attributes. It is used to group the metadata for an asset when the asset is displayed in the user interface. Profiles enable CentraSite Control and the CentraSite plug-in for Eclipse to present the details for an asset in an organized manner. In CentraSite Control, for example, all of the attributes associated with a particular profile are grouped together on a separate tab.
The attributes associated with a profile are displayed on individual tabs in CentraSite Control
Profile permissions determine which profiles a user sees when he or she views an asset with CentraSite Control or the CentraSite plug-in for Eclipse. You might use profile permissions, for example, to limit the amount of information that consumers see for an asset.
Important:
Profile permissions restrict access at the UI level but not the
API level. At the API level, profile permissions are irrelevant. If a user has
view permission on an asset, he or she can access all of the asset's metadata
through the API, regardless of whether profile permissions exist for the asset.
A role-based permission is a permission that CentraSite confers to users through a role. A role is a set of role-based permissions that you assign to users or groups.
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 granted 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 (UI permissions)
Permissions that enable users to create and/or access certain types of registry and repository objects (object-access permissions)
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 are displayed to a user in CentraSite Control's navigation bar.
For example, CentraSite will not display the Policies tab 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.
By default, all CentraSite users (including guests) have 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 explicitly includes the appropriate user interface permission (meaning that the role includes the actual permission itself) or implicitly includes the permission (meaning that the role includes a permission that implicitly grants the UI permission). For example, when you give a user permission to "Manage Design/Change-Time Policies", that permission implicitly grants that user permission to the "Use the Policy UI".
Role-based permissions also include 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 to all objects of a specific type. For example, the Modify Assets permission grants Modify level access on all objects of type Asset. The role-based permissions enable you to apply access controls over an entire class of objects instead of assigning permissions on each instance of an object individually.
These role-based permissions are granted at varying levels. The name of the permission itself indicates the level of access that it grants.
| If the name includes the following term... | The permission enables users to... |
|---|---|
| View | Read objects of a specified type. This level is equivalent to giving a user View instance-level permission on all objects of a given type. |
| Modify | Read and edit objects of a specified type. This level is equivalent to giving a user Modify instance-level permission on all objects of a given type. |
| Create | Create and read objects of a specified type. This level is equivalent to giving a user View instance-level permission of all objects of a given type and giving them the ability to create new instances of that type. |
| Manage | Create, read, edit, delete and modify the instance-level permission of objects of a specified type and modify the object's instance-level permissions. This level is equivalent to giving a user Full instance-level permission of all objects of a given type. |
Note:
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. Refer to the CentraSite user
documentation for the role-based permissions available for each object
type.
The permissions that enable access to registry/repository objects are either organization-specific or system-wide. 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. A system-wide permission grants access to objects that are available to all organizations, such as taxonomies and asset types.
System-wide permissions are generally given only to a small group of high-level administrators.
Permissions are system-wide or organization-specific
CentraSite provides you with coarse-grain and fine-grain permission controls. You will use both types, depending on your needs. When working with permissions in CentraSite, keep the following points in mind:
All users, including guests, have implicit and irrevocable View permission on the following types of objects. You can control who can manage these types of objects (i.e., create, modify and delete them), but you cannot revoke view-level access to these objects.
Organizations
Users
Groups
Roles
Taxonomies
Asset Types
Policies
Run-Time Targets
Report Templates
When a user has multiple instance-level permissions for the same object, the user receives the union of the combined permissions. For example, if a user has View permission on object ABC and belongs to a group that has Full permission on object ABC, the user will get Full permission on the object.
When a user has both role-based permission and instance-level permission on the same object, the user also receives the union of the combined permissions. For example, if a user has the View instance-level permission on asset and also has the role-based "Manage Assets" permission, the user receives Full permission on the object (as conferred by the "Manage Assets" permission).
There will be times when you need to decide whether to use instance-based or role-based permissions to grant a group of users access to a set of assets. When deciding which type of permission to use, keep the following points in mind:
When you grant role-based permissions to a group of users, those users are given permission to access all assets within the organization. You will not be able to selectively hide assets from certain members of the group. Additionally, all users in the group receive a specified level of access (i.e., View, Modify or Manage). You cannot selectively reduce this level of access for individual users. (Although you can selectively increase an individual user's level of access.)
If you grant access to an asset using a role-based permission, you will not be able to selectively hide profiles from the users with the role-based permission. The role-based permissions automatically confer permission to view all profiles for an asset.
Any approach that involves instance-level permissions, by definition, requires you to configure permissions on each asset individually. If you use instance-level permissions to routinely grant permissions to specified groups of users, consider creating a policy to do this for you automatically.
If you need to hide or reveal certain profiles as an asset progresses through its lifecycle states, consider creating policies to automatically set the appropriate profile permissions when the asset switches state.
Avoid granting instance-level permissions to individual users unless you have a specific reason to do so. Granting these permissions to groups instead of individuals, gives you greater flexibility and makes permission changes easier to manage.
Be aware that if you grant instance-level permissions to an external group (i.e., a group that is defined and managed in your external authentication system), it might take CentraSite longer than normal to remove those permission assignments from a registry object.
A role is a set 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 is installed with several predefined roles, including the following:
CentraSite Administrator. This role includes every role-based permission available in CentraSite. As such, it confers "super admin" capabilities to the users to which it is assigned. Users in this role can view, edit and delete virtually any object in the registry. This role cannot be deleted or edited. At least one user must be assigned to this role at all times.
Organization Administrator. This role includes the set of role-based permissions that enable a user to administer an organization. Users in this role can view, edit or delete any object within an organization or the organization's descendants. This role cannot be deleted or edited. Each organization must have at least one user assigned to the organization's Organization Administrator role.
Asset Provider. This role includes the "Create Assets" permission, which enables a user to create assets within his or her organization. By default, all users in an organization receive this role (however, you can configure this behavior as described later). You can modify the permissions associated with this role.
Asset Consumer. This role includes the "View Assets" permission, which enables a user to view all of the assets that belong to his or her organization. By default, all users in an organization receive this role (however, you can configure this behavior as described later). You can modify the permissions associated with this role.
The predefined roles are usually adequate for most CentraSite implementations. However, you can create custom roles if the ones that CentraSite provides do not suit your needs. You can also modify many of the predefined roles that CentraSite supplies.
Note:
Avoid creating a role that is equivalent to the CentraSite
Administrator role. The CentraSite Administrator role is specifically optimized
to maximize performance. An equivalent role will not perform as efficiently as
the predefined CentraSite Administrator role that is installed with
CentraSite.
To create or modify a role, you must have the "Manage Users" permission for the organization to which the role belongs. Be aware, however, that you cannot create a role that has more permissions than what your own user account has. For example, if you do not have the "Manage Taxonomies" permission, you cannot create a role that includes the "Manage Taxonomies" permission.
You assign roles to users or groups using the CentraSite Control user interface. A user or group can be assigned multiple roles. When a user is given multiple roles, he or she receives the union of all permissions in those roles.
By default, CentraSite assigns the Asset Provider and Asset Consumer roles to an organization's Users group. Consequently, every user that you add to an organization receives these roles.
If you do not want users in your organization to receive these roles automatically, or if you want to customize the set of permissions that users receive by default, you can do any of the following:
Remove the Asset Provider and/or Asset Consumer roles from the organization's Users group.
Modify the set of permissions associated with the Asset Provider and/or Asset Consumer roles that are assigned to the Users group.
Create custom roles and assign them to the organization's Users group (instead of, or in addition to, the Asset Provider and/or Asset Consumer roles).
For example, if you want to create an organization whose users can only consume assets, you would remove the Asset Provider role from that organization's Users group. Doing this ensures that users added to the organization only receive permission to view assets. (An administrator could, of course, selectively give specific users in the organization permission to publish assets as necessary.)
