CentraSite Documentation : Getting Started with CentraSite : Implementation Concepts : Using Permissions and Roles to Manage Access to the Registry : Issues to Consider when Working with Permissions
Issues to Consider when Working with Permissions
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 (that is, 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 (that is, 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 (that is, 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.
Copyright © Software AG, Darmstadt, Germany.

Product LogoContact Support   |   Community   |   Feedback