By default, everyone in your organization is permitted to view the assets that you publish. However, only you (as the owner of the asset) and users who belong to a role with the "Manage Assets" permission for your organization are allowed to view, edit and delete these assets. To enable other users to view, edit and/or delete an asset that you have published, you must modify the asset's permission settings.
The following sections describe how to set permissions on an asset.
When setting permissions on assets, keep the following points in mind:
To set permissions on an asset, you must belong to a role that has the "Manage Assets" permission or have the Full instance-level permission on the asset itself.
You can assign permissions to any individual user or group defined in CentraSite.
The groups to which you can assign permissions include the following system-defined groups:
| Group Name | Description |
|---|---|
| Users | All users within a specified organization. |
| Members | All users within a specified organization and its child organizations. |
| Everyone | All users of CentraSite including guest users (if your CentraSite permits access by guests). |
If a user is affected by multiple permission assignments, the user receives the union of all the assignments. For example, if group ABC has Modify permission on an asset and group XYZ has Full permission on the same asset, users that belong to both groups will, in effect, receive Full permission on the asset.
The same principle applies to users who have both role-based permissions and instance-level permissions on the same asset. In this case, users receive the union of the role-based permission and the instance-level permission on the asset.
If you intend to give users in other organizations access to the asset, and the asset includes supporting documents that you want those users to be able to view, make sure you give those users permission to view the supporting documents as well as the asset itself.
CentraSite allows you to set permissions on individual profiles within an asset. This feature enables you to specify which of the available profiles can be viewed or edited by users when they display the asset in CentraSite Control. For any given asset, you can define different profile permissions for different users. For example, if an asset includes a profile called Source Control that displays links to your source control systems, you might want to restrict the visibility of that profile to authorized developers.
You define the user-specific or group-specific profile permissions of an asset via the asset's the Permissions profile. See the instructions in the section Assigning Permissions Using the CentraSite Control User Interface for details.
The profile permissions that can be set on a given asset for any user or group are:
| Permission | Description |
|---|---|
| View | Enables the specified user or group to see the profile when they view the asset. |
| Modify | Enables the specified user or group to modify the attribute settings in the profile when they view the asset. |
Note that the individual profiles do not include the Full permission because users cannot delete a profile from an individual asset.
Important:
Be aware that profile permissions can be used to prevent users
from viewing and/or accessing a particular set of attributes through
CentraSite's graphical user interfaces. However, they do not restrict access
to the attributes themselves at the API level.
By default, if a user with the Guest role has permission to view the details of an asset, CentraSite Control includes the asset's Summary profile in the set of profiles displayed to this user. If you wish to suppress the display of this profile for users with the Guest role, you can do this as follows:
To suppress the display of the Summary tab for users with the Guest
role
On the file system, locate the configuration file plugin.xml in the folder <RuntimeDir>\workspace\webapps\PluggableUI\CentraSiteControl .
In this file, locate the following
<extension> element:
<extension point="com.softwareag.cis.plugin.parameter" id="guestAllowSummaryProfileVisible" value="true" />
Change the value "true" to "false".
Save the file and restart Software AG Runtime.
If you wish to reactivate the Summary profile for
users with the Guest role, replace "false" by
"true" in the
<extension> element and restart Software AG Runtime.
You can set the permissions on an asset in two ways:
Using the Permissions profile in the user
interface
You can use the Permissions profile in the user
interface as described in Assigning
Permissions Using the CentraSite Control User
Interface.
Using the "Set Instance and Profile
Permissions" policy action
You can use the "Set Instance and Profile
Permissions" policy action in a design/change-time policy to
automatically assign permissions to an asset during any of the following
events:
PostCreate
PreStateChange
PostStateChange
OnTrigger
For more information about creating policies, see the document Working with Design/Change Time Policies. For more information about using the "Set Instance and Profile Permissions" action, see the section Set Instance and Profile Permissions in the document Built-In Design/Change-Time Actions Reference.
Use the following procedure to set instance-level permissions on an asset using CentraSite Control.
To assign permissions to an asset
Display the details page for the asset whose permissions you want to edit. If you need procedures for this step, see Viewing Details for an Asset.
Open the Permissions profile.
To add users or groups to the Users and Groups list, do the following:
Click .
Note:
This button is only
selectable if you have the Modify permission on the asset and also the Modify
permission on the asset's Permission profile. See the
sections Who Can Set Permissions on an
Asset? and Restricting Access to
Specific Profiles above for details.
Select the users and groups to which you want to assign permissions.
If you want to filter the list, type a partial string in the Search field. CentraSite applies the filter to the Users/Groups column.
Examples| String | Description |
|---|---|
b |
Displays names that contain "b" |
bar |
Displays names that contain "bar" |
% |
Displays all users and groups |
Click .
Use the View, Modify and Full check boxes to assign specific permissions to each user and/or group in the Users and Groups list as follows:
| Permission | Allows the selected user or group to... |
|---|---|
| View |
View the asset. |
| Modify |
View and edit the asset. |
| Full |
View, edit and delete the asset. This permission also allows the selected user or group to assign instance-level permissions to the asset. |
When you assign instance-level permissions on an asset, the related objects (for example, bindings, operations, interfaces etc.) receive the same permissions that are assigned on the asset.
If you want to ensure that the asset's dependent objects (for example, a WSDL or schema) receive the same permissions, mark the checkbox Propagate permissions to dependent objects. If you do not mark this checkbox, the permissions of the dependent objects will not be modified.
In addition, you can ensure that the dependent objects of the same object type receive the same profile permissions. To do this, mark the checkbox Propagate profile permissions.
See the section Propagation of Permissions below for more information concerning propagation of permissions and propagation of profile permissions.
Click to save the new permission settings.
Use the following procedure to set instance-level permissions on an asset's profiles.
To assign instance-level permissions on an asset's profiles
Open the asset's Permissions profile.
Locate the user or group for which you wish to set profile permissions. Then click the arrow icon beside the user or group name to open the profile permission list.
Use the checkboxes to indicate which profiles the user or group is permitted to view or modify.
Click to save the new permission settings.
An asset can have one or more dependent objects. For example, a Service asset can refer to a WSDL which in turn can refer to one or more XML Schema assets. You can optionally choose whether the permissions assigned to an asset instance should be automatically propagated to the asset instance's dependent objects.
In the context of CentraSite Control, propagation of permissions means that the new permissions completely replace the old permissions; the new permissions are not merged with the old permissions. As an alternative, you can use a change-time policy containing the action "Set Instance and Profile Permissions". With this action, you can choose whether the new permissions will be merged with the old permissions or will replace the old permissions. See the section Built-In Actions for Design/Change-Time Policies in the document Built-In Design/Change-Time Actions Reference for details.
By default, the access level permissions that are assigned on an asset are implicitly propagated to these dependent objects. This behavior is activated when you mark the checkbox Propagate permissions to dependent objects in the asset's Permissions tab. For example, assigning Modify permission on a Service asset propagates the Modify permission to the asset's WSDL, schemas, etc.
If you do not have permission to assign instance-level permissions to a dependent object, the dependent object will not be modified and a warning message will be issued.
You can propagate permissions only for the following asset types:
Service
XML Schema
BPEL
In addition to propagating permissions that control the access to an asset instance (as described above), it is also possible to propagate permissions that control the access to the asset instance's profiles. This means that the profile permissions that you define for an asset instance can be propagated to the asset's dependent objects. However, this is only possible if the dependent object is of the same asset type as the first object; this restriction arises because different asset types can have different sets of profiles.
This behavior is activated when you mark the checkbox Propagate profile permissions in the asset's Permissions tab. This checkbox is only available for the following asset types:
Service
XML Schema
