Introduction to Permissions and Roles

CentraSite 10.7 | CentraSite User’s Guide | Role Management | Introduction to Permissions and Roles

Permissions determine the operations users can perform and the set of objects users can access.

Instance-Level Permissions

This following table lists instance-level permissions and the actions they enable a user or group to perform:

Permission	Enables specified user or group to...
View	View an object View a folder and its properties View a file and its properties
Modify	Edit an object Create files and subfolders in a folder Edit a file and its properties View instance-level permissions
Full	Edit an object Create files and subfolders in a folder Edit a file and its properties View instance-level permissions

By default, a user has implicit and irrevocable Full permission on all the objects the user owns.

The object types that support access control at the instance level are assets, repository folders and files, report templates, design/change-time policies, run-time policies, and taxonomies. All CentraSite users, including guests, have implicit and irrevocable permission to view all instances of report templates, policies, and taxonomies. However, you can use instance-level permissions to restrict the ability to edit and delete them.

Access to other types of objects is controlled using the broader role-based permissions or is enabled contextually. 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.

You can set instance-level permissions through CentraSite Control and CentraSite Business UI, and 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 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 is 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, CentraSite Business UI, and the CentraSite plug-in for Eclipse to present the details for an asset in an organized manner. In CentraSite Control, for example, all attributes associated with a particular profile are grouped on a separate tab.

Profile permissions determine the profiles a user sees when he or she views an asset with CentraSite Control, CentraSite Business UI, 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. Profile permissions restrict access at the UI level but not the API level. At the API level, profile permissions are irrelevant. A user with view permission on an asset can access all the asset's metadata through the API, regardless of whether profile permissions exist for the asset.

Roles and Role-Based Permissions

A role is a set of role-based permissions. Role-based permissions enable users to access areas of the CentraSite Control and CentraSite Business UI and to create and manage (view, edit, and delete) certain types of registry and repository objects. You can assign roles to a user or a group; the user or users in the group receive the permissions specified in the role.

By default, all CentraSite users, including guests, have permission to use the asset details of the CentraSite Control and CentraSite Business UI, and all users except guests have permission to provide and consume assets within their own organization. To use the other parts of the user interface or have access to other objects, a user must belong to a role that includes the appropriate permission.

Role-based permissions are at two levels:

System-wide permissions grant 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 or repository. System-wide permissions are generally given only to a small group of high-level administrators.

Organization-specific permissions grant access to all objects of a certain type within one organization. Permissions that enable access to assets, policies, and lifecycle models are organization-specific.

CentraSite comes with predefined roles for each level of permissions. If necessary, you can create custom roles.

System-level 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 or repository.

Organization-wide roles contain permissions for working with organization-specific objects. CentraSite maintains a set of organization-level roles for each organization in the registry or repository.

System-Level Role-Based Permissions and Predefined Roles

This following table lists system-level permissions:

Permission	Grant the right to...
Use the {Home\|Policy\| Administration\|Reports\|Operations} UI	Use the indicated area in CentraSite Control.
View {Policy Log\|Approval History}	View the indicated item. Administration UI permission is implied.
Register as Consumer	Register as a consumer of assets.
Manage Organizations	Manage all organizations in the CentraSite instance. Manage Organizations (org-level permission for every organization), Manage System-wide Design/Change-Time Policies, Manage System-wide Run-Time Policies, Manage Lifecycle Models (org-level permission for every organization), and Manage Report Templates permissions are implied. Note: All organizations are visible to everyone.
Manage System-wide Lifecycle Models	Manage lifecycle models. Administration UI, Manage System-wide Design/Change-Time Policies, Manage System-wide Runtime Policies, and Manage Lifecycle Models (org-level permission for every organization) permissions are implied.
Manage System-wide {Design/Change-Time\|Runtime} Policies	Manage the indicated policies as well as Action Categories, Action Templates, and Action Parameters. Policy UI permission is implied.
Manage Report Templates	Manage system-wide report templates. Reports UI permission is implied.
Manage System-wide Roles	Manage system-level roles. Administration UI permission is implied.
Manage {Taxonomies\|Asset Types}	Manage the indicated items. Administration UI permission is implied.
Manage Supporting Documents	Manage the content of all folders in the Supporting Documents Library (SDL). View Supporting Documents permission is implied.
View Supporting Documents	View the content of all folders in the SDL.

This following table lists predefined system-level roles provided with CentraSite.

System-Level Role	Permissions
CentraSite Administrator (CSA)	All system-wide permissions. Can create, delete, or change the permission set for a system-level role. This role cannot be modified or deleted. At least one user must be assigned to this role at all times.
Asset Type Administrator	Use Home and Administration UIs; view policy log and approval history; manage system-wide lifecycle models, design/change-time policies, taxonomies, and asset types.
Operations Administrator	Use Home, Policy, Reports, and Operations UIs; view policy log and approval history, manage system-wide lifecycle models, design/change-time policies, runtime policies, report templates, runtime gateways, and event types.
Guest	Browse and use the asset catalog.

Organization-Specific Role-Based Permissions and Predefined Roles

This following table lists organization-specific permissions.

Permission	Grants the right to...
Manage Assets	Manage assets and supporting documents within an organization. View, Create, and Modify Assets permissions are implied.
Create Assets	Create assets within an organization.
Modify Assets	Modify all assets and supporting documents within an organization. Also important for performing consumer registrations. View Assets permission is implied.
View Assets	View all assets and supporting documents within an organization.
Manage Design/Change-Time Policies	Manage design/change-time policies within an organization. Implies the right to manage all policy-related objects such as policy conditions and policy parameters. Policy UI permission is implied.
Manage Run-Time Policies	Manage run-time policies within an organization. Implies the right to manage all policy-related objects such as policy conditions and policy parameters. Policy UI permission is implied.
Manage Lifecycle Models	Manage lifecycle models (LCMs) within an organization. Administration UI, Modify Assets, Manage Design/Change-Time Policies, and Manage Runtime Policies permissions are implied.
Manage Users	Manage users, groups, and roles within an organization. Administration UI permissions is implied.
Manage Organizations	Manage an organization, all its child organizations, and the organization folder in the SDL. Manage Users, Manage Design/Change-Time Policies, Manage Runtime Policies, Manage Lifecycle Models, and Manage Assets permissions are implied. Note: By default, the content of an organization folder is visible to every user of that organization. All organizations are visible for everyone.

This following table lists predefined organization-level roles provided with CentraSite.

Organization-level Role	Permissions
API Gateway Administrator	Manage API Gateway instances in an organization. Note: If you are upgrading to CentraSite 10.1 from an earlier version, the users who had been assigned the Mediator Administrator role in the previous versions of CentraSite are automatically assigned the API Gateway Administrator role.
API Gateway Publisher	Publish and unpublish APIs to and from API Gateway instances in an organization. Note: If you are upgrading to CentraSite 10.1 from an earlier version, the users who had been assigned the Mediator Publisher role in the previous versions of CentraSite are automatically assigned the API Gateway Publisher role.
Asset Administrator	Use Home and Reports UIs; view policy log and approval history; register as consumer; manage assets and lifecycle models.
Asset Consumer	Use Home and Reports UIs; register as consumer, view assets. By default, all users in an organization receive this role.
Asset Provider	Use Home and Reports UI; register as consumer; create assets. By default, all users in an organization receive this role.
Mediator Administrator	Manage Mediator gateway instances in an organization.
Mediator Publisher	Publish and unpublish run-time policies and APIs to and from Mediator gateway instances in an organization.
Organization Administrator	All organization-specific permissions for an organization. Can use the Home, Policy, Administration, and Reports UIs, and view, edit or delete any object within an organization or the organization's descendants. This role cannot be modified or deleted. At least one user in an organization must be assigned to this role at all times.
Policy Administrator	Use Home and Policy UIs; view policy log and approval history; view assets, manage design/change-time and runtime policies.
API Portal Administrator	Manage API Portal gateway instances in an organization.
API Portal Publisher	Publish and unpublish APIs to and from API Portal gateway instances in an organization.
API Runtime Provider	Manage run-time policies and configure run-time actions for virtual APIs in an organization.

Considerations when Working with Instance-Level and Role-Based Permissions

A user always receives the union of all permissions that are granted.

If you grant access to an object type using a role-based permission, the users of that role can access all objects of that type within the organization. You cannot selectively hide objects from certain users.

If you grant access to an asset using a role-based permission, the users of that role can view all profiles for the asset. You cannot selectively hide profiles from certain users. 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.

Users that have been granted a role-based permission receive the specified level of access (View, Modify, or Manage). You can selectively increase this level of access for individual users, but you cannot selectively reduce it.

Grant instance-level permissions to groups rather than individual users unless you have a specific reason to do so. Doing so gives you greater flexibility and makes permission changes easier to manage.

If you grant access using instance-level permissions, you configure permissions on each asset individually. If you routinely use instance-level permissions, consider creating a policy to do this for you automatically.

If you grant instance-level permissions to an external group (that is, a group that is defined and managed in your external authentication system), it might take CentraSite longer than usual to remove those permission assignments from a registry object.

Configuring the Default Roles that CentraSite Assigns to Users in an Organization

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 is assigned with these roles.

If you do not want users in your organization to have these roles assigned automatically, or if you want to customize the set of permissions that users are assigned by default, you can do any of the following:

Remove the Asset Provider and Asset Consumer roles from the organization's Users group.

Modify the set of permissions associated with the Asset Provider and 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 Asset Consumer roles).

For example, if you want to create an organization whose users can only consume assets, you have to 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.)

Important Things to Know When Upgrading to API Gateway 10.1

After upgrading to CentraSite 10.1 from an earlier version, the users who were created with Mediator Administrator and Mediator Publisher roles in previous versions of CentraSite and transferred to CentraSite 10.1 will automatically have the API Gateway Administrator and API Gateway Publisher roles.