Resource permissions

To perform an action on a resource, the user must belong to a group that has the necessary permissions for both the action and the resource (server). For example, suppose that a server is associated with these resources: the Widget, Inc. customer and the Fresno facility and the Red Hat AS 4 device group. To install a patch on this server, the user could belong to a group with the permissions listed the following table.

Table 3. Example of Resource permissions and Action permissions

Resource and Action	Permission
Customer: Widget, Inc.	Read & Write
Facility: Fresno	Read & Write
Device Group: Red Hat AS 4	Read & Write
Action: Install Patch	Yes

A resource is one or more managed servers. Server resources are organized into the following categories:

• Facilities: The servers associated with an SA Facility. Every managed server belongs to one and only one of your facilities.
• Customers: The servers associated with a customer. You create customers and assign each server to one customer. Every server belongs to one and only one customer, which may be the “Not Assigned” customer group.
• Device Groups: The servers belonging to a device group. You create device groups and assign servers to them. Every server can belong to one or more device groups.

Resource permissions for a user group determine if the users in the user group can view or modify the servers. A user group only has access to the servers in the facilities, customers, and device groups for which it has been granted resource permissions. Because every server belongs to one facility, one customer, and at least one device group, to have access to servers, a user group must have permissions to at least one facility, at least one customer, and at least one device group.

You can combine customer, facility, and device group permissions to implement security policies. For example, you can restrict access to servers that are associated with the Acme Corp. customer, reside in the Fresno facility, and belong to a device group that contains only Windows servers (see Examples of Resource permissions).

Any one server is in a facility, is associated with a customer and is in one or more device groups. A user needs access to that facility, as well as to that customer and to at least one device group containing that server to get access to that server. See Setting Resource permissions - facilities, customers, and device groups.

Examples of Resource permissions

Suppose that a server resides in the Fresno facility, is associated with the Widget, Inc. customer, and belongs to the Accounting device group. To modify the server, the user group could have the permissions listed in the following table. These permissions are also shown in the following figure for the user group named Win-patchers.

Example of Resource permissions

Resource	Access Permission
Facility: Fresno	Read & Write
Customer: Widget, Inc.	Read & Write
Device Group: Accounting	Read & Write

Resource permissions view in the User Group screen

If the access permissions for the facility, customer, or device group do not match, then the most restrictive permissions are enforced.

For example, asthe following table shows, if the permission for the customer and the device group is Read & Write but the permission for the facility is Read, then the Read permission is enforced and the user will not be able to modify the servers.

If the permission for the customer is None, then the server cannot be viewed, even if the other permissions for the user group specify Read, or Read & Write.

Example of mismatched Resource permissions

Resource	Permission
Facility: Fresno	Read
Customer: Widget, Inc.	Read & Write
Device Group: Accounting	Read & Write

Resource and Action permissions combined - Example

To perform an action on a resource, the user must belong to a group that has the necessary permissions for both the action and the resource (server). For example, suppose that a server is associated with these resources: the Widget, Inc. customer and the Fresno facility and the Red Hat AS 4 device group. To install a patch on this server, the user could belong to a group with the permissions listed the following table.

Example of Resources permissions and Action permissions

Resource and Action	Permission
Customer: Widget, Inc.	Read & Write
Facility: Fresno	Read & Write
Device Group: Red Hat AS 4	Read & Write
Action: Install Patch	Yes

Types of access to resources

Resource permissions must specify one of the following types of access:

• Read: Users can view the resource only.
• Read & Write: Users can view, create, modify or delete the resource.
• None: The resource does not appear in the SA Client. Users cannot view or modify the resource.

About Facility permissions

Every server is in one and only one facility. To modify a server in a particular facility, a user must belong to a user group that has Read & Write permission for the facility. For example, if you want the users of a group to be able to view (but not modify) the servers in the London facility, set the permission to Read.

The facility permissions also control access to the facility object itself. For example, to modify a property of a facility, a user must belong to a group that has Read & Write permission to the facility and the action permission to modify facilities.

About Customer permissions

Every server is associated with one and only one SA Customer, even if it is the “Not Assigned” Customer group. An SA Customer is a logical group into which you can place servers. You can then perform IT management tasks on all servers belonging to an SA Customer as long as you have Read and/or Write privileges to that Customer, thus providing security and authorization boundaries. For example, if you want the users of a group to be able to view (but not modify) the servers associated with the Widget Inc. customer, set the permission to Read.

The customer permissions also control access to the customer object itself. For example, to add a custom attribute to a customer, a user must belong to a group that has Read & Write permission to the specific customer and the action permission to modify customers.

About Device Group permissions

Every server can belong to one or more device groups. By setting the device group permissions, you control the access that the users in the user group have to the servers in the device group. For example, if you want the users of a group to be able to view (but not modify) the servers in the Windows Server 2008 device group, set the permission to Read.

By default, each server belongs to a public device group based on its operating system. You can view these device groups in the SA Client by selecting the Devices tab and selecting Device Groups > Public > Opsware > Operating Systems.

If a server belongs to more than one device group, the user group needs permission to only one of the device groups to get access to that server.

While a device group can contain other device groups, permissions are not inherited by the contained device groups.

You cannot control access to a private device group. Private device groups are visible only to the user who created them.

The device group permissions control access to servers that belong to device groups. However, these permissions do not control the management of the device groups. To create, modify, or delete device groups, a user must belong to a user group that has the Manage Public Device Groups and the Model Public Device Groups action permissions and the Managed Servers and Groups action permission. To add devices to a device group being used as an Access Control Group, the user must be a Super Administrator.

Other types of resources

Managed servers are the most common resources. Other types of resources are:

• Hardware definitions
• Realms
• OS installation profiles

Each of these resources can be associated with customers.

Folders can also be associated with customers, but access to folders is controlled in a different way (see Folder Permissions).