Domains

A domain consists of all the resources that require protection and the associated security policy used to protect those resources.

The resources we can protect depend on the resource managers installed. These resources depend on which resource managers are installed. The resources can be any physical or logical entity, including objects such as files, directories, web pages, printer and network services, and message queues. Any security policy implemented in a domain affects only the objects in that domain. Users with authority to do tasks in one domain do not necessarily have the authority to do those tasks in other domains.

Security Verify Access creates a domain, called the management domain, as part of its initial configuration. The default name of this management domain is Default. It is in a stand-alone naming context, with a suffix called secAuthority=Default. This domain is used by ISAM to manage the security policy of all domains and is available for managing other protected resources as well. The administrator can rename the management domain and change its location when the policy server is configured.

For small and moderately sized enterprises, one domain is typically sufficient. If only one domain is needed, no explicit action needs to be taken.

In large enterprises, however, we might want to define two or more domains. Each domain is given a name and is established with a unique set of physical and logical resources. The security administrator can define the resources in a domain based on geographical area, business unit, or major organizational division within the enterprise. The security policy defined in the domain affects only the resources in that domain, which allows data to be partitioned and managed independently.

A multiple domain environment can be invaluable when there is a business need to keep a physical separation between different sets of data. The following other benefits are associated with using multiple domains:

Increased security

Security policy data for each domain is mutually exclusive. We cannot associate users, groups, and resources defined in a domain with another domain. For example, suppose that a user named John Doe is identified as JohnDoe in the Sales domain and as JDoe in the Advertising domain. Although the same person, each user ID is unique for each domain. As a result, resources available to user JohnDoe can be granted access by the unique ID by which the user is defined in that domain (Sales). In addition, user JohnDoe can be granted access in the Sales domain by the unique ID in the groups of which JohnDoe is a member. Likewise, user JDoe can be granted access only by the unique ID by which the user is defined in the Advertising domain.

Simplified administration

We can assign independent administrators to handle policy management tasks for each domain. For example, assume that we are an IT specialist for a large corporation. You are assigned to deploy ISAM from a single data center. We can create a separate domain with a unique policy database and an administrator for each organization, division, or geographic area in the company. As users, groups, or resources change, the assigned administrator is responsible for updating the security policy for that particular domain. This domain administrator can also delegate administration tasks to others in that domain.

An administrator assigned to a specific domain has authority only in that domain. By default, an administrator can view users and groups defined in the user registry that are not necessarily Security Verify Access users or groups. This feature is beneficial if, for example, an administrator wants to import a user or group from a different domain. The administrator of the management domain can limit the registry data that a domain administrator can access. To do so, add the allowed-registry-substrings stanza entry to the [domains] stanza in the ivmgrd.conf configuration file for the policy server.

See Domain management.

Parent topic: Security Verify Access administration