CA Client Automation - 14.0

PDF
English

Overview of Permissions

Contents
cla140
Contents
Authorization covers the following types of permissions:
  • Class permissions
  • Object permissions
  • Area permissions
The security subsystem manages all types of permissions and uses a cumulative approach to get the effective permissions.
If you have enabled area permissions, both types of permissions (object and area permission) are checked to get access to objects. That means a user needs objects permissions
and
 area permissions to get an object managed. Object permissions are checked only if area support is disabled .
Class Permissions
Class permissions are the access rights you specify on class level. This means that the class-level permissions are the default rights for each object that is an instance of this class.
You must specify the class permissions for each security profile when you create a security profile. For all security classes, No Access is set by default. Security profiles with appropriate class permissions give you access rights to the system. You can specify this in the Class Permissions dialog.
Class permissions are globally applicable to all objects in an object class. If you want to restrict users on a specific object or folder in the Explorer, or grant extended access rights, use the Object Permissions dialog or the Security Group Permissions dialog, respectively.
Security classes are used for grouping objects of the same type. The security subsystem in
CA Client Automation
 supports the following security classes:
  • Discovered hardware (Computer)
  • Users
  • Computer Users
  • Manager
  • Servers
  • Asset Groups
  • Server Groups
  • Domain Groups
  • Queries
  • Security Classes
  • Security profiles
  • Software packages
  • Software procedures
  • Procedures groups
  • Job Containers
  • Software Jobs
  • Asset Jobs
  • Modules
  • Query Based Polices
  • Event Based Policies
  • OSIM Boot images
  • OSIM OS images
  • Engine
  • Configuration Policies Computer
  • Configuration Policies User
  • External Directory Access
  • Report Templates
  • Inventory modules
The following security classes are used for class level only.
  • MDB Access
  • Enable Control Panel
  • Enable Remote Control
Class level security means that every object or instance of a class will get the permission as defined for the class by default.
Combined Class Permissions Required for Specific Actions
A couple of Object Class rights are depending on each other; this means if you want to perform the following actions, you have to grant rights to more than one object class.
  • Report Templates
    If you want to schedule a Report template, you need to grant Change right for object class "Report Scheduling"
    and
     Change right for object class "Engine".
  • Security Profiles
    The security class "Security Profiles" controls the handling with just security profiles (delete, and so on). If you want to modify object class permissions in a security profile, you must have Special Access (VRP, with the 'P' permission) for the object class "Class Permissions".
  • Engine
    If you want to link an engine task to an engine, you must grant Change right for the "Engine" object class
    and
     Manage right for the "Engine Task" object class.
    Regarding engine security, if you want to start, stop, or modify engine objects, you must grant Full Control right for the "Engine" class in the security profile
    and
     beyond NT Administrator or root rights to the computer where the engine is running.
  • Software Job security
    If you want to modify or remove a software job under the /computer folder, the software is delivered to /Jobs/Software Jobs; the object classes "Computer" and "Software Job" must have Change rights.
  • Procedure Security
    If you want to start, stop, or modify Procedure objects, you must grant Change (VRWXD) for the "Procedure" class
    and
     beyond the file permissions administrator or root.
  • Security Area Support
    If you want to enable or disable the Security Area support and define Default Security Areas, the class permissions for the object class "Security Area" must be set at least to Special Access (VP).
    If you want to link security profiles to a security area, View (V) permissions are sufficient for the object class "Security Area". The class permissions for the object classes "Security Profiles" must be set at least to Special Access (VW).
Object Permissions
Setting object permissions is helpful when you want to restrict the access rights on a particular object. By default, all objects inherit the permissions set for the object class.
Object permissions take precedence over the class and group permissions.
The object permissions are always present and managed by the security subsystem and cannot be disabled. If you do not want to take care of object permissions you may set the class-level permissions for all security classes to Full Control.
Authorization is based on the concept of an Access Control Entry (ACE). An ACE is any combination of the code letters shown in the following table, for example, VR. This ACE allows you to show and read objects; any other access is denied.
If the ACE is empty (contains no code letter), no access right is granted at all.
The following table defines object permissions:
Code letterin ACE
Meaning
Rights Granted
V
View
Allows you to show objects
C
Create
Allows you to create objects
R
Read
Allows you to read sub-objects of an object
W
Write
Allows you to change an object
X
Execute
Allows execution, depends on object type
D
Delete
Allows you to delete objects
P
Permission
Allows you to change the ACE itself
O
Ownership
Allows you to take ownership of an object
 
A user may belong to one or more security profiles. A user can also be the owner of an object. A set of security classes is assigned to each security profile. The security class permission defines the default permission that is assigned to an object when an instance of the class is created.
The following illustration shows how security profiles, security classes and object permissions are related to each other and that an object inherits the rights from the security class where the object is an instance of:
Object permissions profiles classes relation
Object permissions profiles classes relation
In the illustration, user 1 belongs to security profile A, user 2 belongs to security profile A and is also owner of objects, represented by an ACE. User 1 and user 2 have specific ACEs, for example, VR, through security profile A. User 2 has an additional ACE, for example, VCRWD, as owner of an object.
To check the access rights of user 1 and user 2 to an object, the security system makes a (logical) union of the user-specific ACE and the ACE associated to the specific secured object. In the example, both user 1 and user 2 have "view" and "read" rights to the object, but only user 2 has write or delete access.
Security Levels
Depending on how the object permissions are derived, there are different types of security levels for the object:
  • Class-level security
    When the object permission derives from the class-level permission (from the class where the object belongs), the security level is set to class-level. This is the default if a secured object is created.
  • Group-level security
    When a secured object is member of a security group where inheritance is enabled, the security level is set to group-level. Permissions derive from the group that the object is a member of (group-level permission).
  • Object-level security
    When the user sets the object permission manually for a certain secured object, the security level is set to object-level because the permissions are set individually for the object.
Permission Inheritance from a Group
If an object is member of a group, the security subsystem in
CA Client Automation
 supports dynamic inheritance of permissions from a group to a member, as follows:
  • A flag marks a group for dynamic inheritance.
  • The specified member permissions are inherited to all members of this group.
  • If a member is added to a group, it automatically inherits the permissions of the group.
The design of group security is based on following decisions:
  • Security inheritance can be turned on or off on a group. When turned on, the group becomes a security group (the application may use a different icon for visualization).
  • The group will have two permission masks, one for the group itself (just like any other secured object) and an inheritance mask.
  • When a group inherits from a parent group, both masks will be changed to the inherit mask of the parent group.
  • The permission mask of a member of a group or many groups is evaluated to the "union" of all the permissions from the member’s parents, and so on. (the permissions are ORed together).
  • The inheritance is done from parent to child which can result in a recursive update of objects.
  • There are no restrictions of inheritance depth.
  • In the order of precedence, object permissions preside over group permissions, which preside over class permissions.
  • If an object is a member of at least one security group, the only change allowed on that object is to apply object security, because applying class security would break the model. For class security to become active, the object needs to be removed from the group or security inheritance turned off on the group.
Inheritance from a group is switched off, if the security level of an object is set to object-level.
The following illustration shows the inheritance when an object is a member of a group and the group enables the inheritance of the object permissions:
Object permissions inheritance
Object permissions inheritance
Group g1.1 is a sub-group of group g1. The computers "john" and "smith" are members of the group g1.1.
For the group g1 inheritance of permissions is disabled, for g1.1 it is enabled. Therefore, the computers "john" and "smith" inherit their permissions from the permissions of group g1.1.
Area Permissions
The security area concept extends the security model. A security area is an optional feature that is suitable for large implementations with thousands of objects managed by different users.
A security area is a geographical, organizational, or topological division. Defining security areas is helpful if you want to restrict the access of users to only the objects linked to their security area. In the security area concept, users, represented by security profiles, and objects are linked to security areas. A security area can be linked to one or more profiles and one or more objects. A user can access an object, if at least one security area linked to the object is also linked to at least one security profile of the user. If object access is denied, the object is not visible for the user.
Example: Two security areas and three users
Three users, HRManager, SeniorManager, and DevManager have the user profiles HRMgrProfile, SrMgrProfile, and DevMgrProfile (with all access rights) assigned. Two security areas have been defined, HumanResources and Development. The profiles HRMgrProfile and SrMgrProfile are linked to the security area HumanResources. The profiles SrMgrProfile and DevMgrProfile are linked to the security area development. Then SeniorManager, represented by SrMgrProfile, has access to both security areas, Human Resources and Development. HRManager has only access rights to security area Human Resources and the user DevManager has only access rights to security area Development. If HR Manager, for example, creates a query on his console in the Human Resources area, this is not visible for the user DevManager. Only objects created by the system are visible for all user profiles.
Area permissions example
Area permissions example
Setting area permissions lets you restrict the access rights on a particular object of one or more profiles. That means that even the class-level permissions defined for a profile are the same. You may assign or link an object to different areas or restrict the access for profiles to see only objects that are linked to a certain area.
In addition to the object permissions, which are basically managed by the security classes, the security subsystem allows to create up to 32 areas.
The following illustration gives you an overview of the area support of the security subsystem.
Area permissions overview
Area permissions overview
User 1 and user 2 belong to security profile A. In the area definition, which is linked to profile A, it is defined which areas are visible to the users belonging to security profile A.
User 2 created an object, which is visible to all users who are linked to the appropriate area.
For important use cases and the descriptions of what area support is doing in the context of these use cases refer to the section "Security Area Support Use Cases".
Preconditions for Object Access in Areas
The following conditions must be fulfilled before the area permission of the user is evaluated:
  • The user must have object access (View or Read) to the object.
  • The security area support on the domain manager must be enabled.
  • All security profiles that the user is member of must be enabled for security area support.
If the first condition is not fulfilled, the object access for the user is denied regardless of the second and third condition. If the second or third condition is not fulfilled, the user will not be restricted based on the area permissions and be allowed to access all the objects.
Notes:
  • All objects are accessible to the users who are members of security area disabled security profiles. We recommend that the administrator ensures that all security profiles are enabled for security area support.
  • Security area support is not available on the DSM enterprise managers.
  • The “Distributions” profile is the only built-in profile that can be enabled for security area support. All other built-in profiles are disabled for security area support.
  • Objects belonging to the "Procedure" or "Software Job" security classes cannot be linked to any security area within the DSM Explorer. They are automatically linked to the areas their parent containers, "Software Package" and "Software Job Container", are linked to.
Area Permissions Derived
Area permissions can be set or are derived in the following ways:
  • Area permission from security profile
    If the creation user is valid when a secured object is created, then the area permissions are derived from the user who created the object.
    (Security level: Creation User)
  • Area permission from a group
    This case only applies when the secured object is member of a group and inheritance is enabled.
    (Security level: Group)
  • Area permission set manually
    A user may set the area permission for a certain object manually.
    (Security level: Object)
  • Area permission by default
    If a secured object is created and the creation user is not set or could not be found in the user list, then the area permissions are derived from the global configuration settings (global default permissions).
    (Security level: Global Settings)