Introduction to Permissions and Roles

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.

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 UDDI Subscriptions

Manage UDDI Subscriptions. View and Create UDDI Subscriptions permissions are implied.

Create UDDI Subscriptions

Create new UDDI Subscriptions and view existing UDDI Subscriptions. View UDDI Subscriptions permission is implied.

View UDDI Subscriptions

View UDDI Subscriptions. 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; manage and create UDDI subscriptions.
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
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.
Asset Provider	Use Home and Reports UI; register as consumer; create assets. By default, all users in an organization receive this role.
Asset Consumer	Use Home and Reports UIs; register as consumer, view assets. By default, all users in an organization receive this role.
Asset Administrator	Use Home and Reports UIs; view policy log and approval history; register as consumer; manage assets and lifecycle models.
Policy Administrator	Use Home and Policy UIs; view policy log and approval history; view assets, manage design/change-time and runtime policies.
API Runtime Provider	Manage run-time policies and configure run-time actions for virtual APIs.
Mediator Administrator	Manage Mediator gateways within an organization.
API Portal Administrator	Manage API Portal gateways within an organization.
Mediator Publisher	Publish and unpublish run-time policies and APIs to and from Mediator gateways.
API Portal Publisher	Publish and unpublish APIs to and from API Portal gateways.

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.)

Contact Support | Community | Feedback