Domain-level security

Domain-level security designates the users who can access a particular domain. Domain-level security is turned off by default.

For example, you can use domain-level security so that stubs that are running in one team's domain can be viewed or changed by members of that team only but not by other teams that have their own domains on the same server. In addition, you can use domain-level security to control access to the recorded messages on the Library page and to control the visibility of any registered agents or proxies.

Note:

If a user does not have the User or Domain Administrator role for a given domain they will not be able to access the following screens:

Results
Library
Scheduling

The following sections provide you with information about how you can create domains, understand the user roles supported in an domain-level security enabled or disabled scenario:

Creating domains
User roles
Supported roles with DLS disabled
Supported roles with DLS enabled
Roles and permissions
Best practices

Creating domains

For a stub to have restricted access, it must have its own domain. A Rational® Integration Tester project can be associated with only one domain at a time. Therefore, all stubs within a project are published to the same domain. Typically, a domain equates to a team or a project. Multiple projects can be published to a team's domain. For more information about creating domains, see Creating domains with Rational Test Control Panel method.

User roles

Rational® Test Control Panel supports the following user roles:

Role	Description
Server Administrator	A Server Administrator can create, delete, and rename domains, and assign roles within domains, but cannot perform actions in a particular domain, such as starting stubs. You can assign a user as the Server Administrator at the time of installing Rational® Test Control Panel. The role of a Server Administrator once assigned cannot be changed after installing Rational® Test Control Panel.
Domain Administrator	A Domain Administrator can assign roles within that domain, perform other administrative tasks such as deleting published projects, unlocking environments locked by other users, deleting others' artifacts on the Library page, and can perform actions like a user in a domain.
User	The Domain Administrator assigns the User role for a domain. A user in a domain can perform actions from the Rational® Test Control Panel user interface in that domain such as starting and stopping stubs or locking environments. A user who has any of those roles in a domain is said to be a member of that domain.
API User	The Domain Administrator assigns the API User role for a domain. An API user can access the domain only by means of APIs such as the REST API, and not from the Rational® Test Control Panel user interface. The API users are typically those for whom tokens are generated for agents, proxies, or automated scripts that call the ant or command-line APIs.

Supported roles with DLS disabled

In Rational® Test Control Panel, when the domain-level security is disabled, which is the default option, a user has no role assigned nor has any restrictions on the operations that the user can perform in any domain on the server. A user can perform any function in any domain in the server.

Supported roles with DLS enabled

When domain-level security is enabled in Rational® Test Control Panel, a user must be assigned to any of the following roles by the Server Administrator:

Domain Administrator
User
API User

A user without a specific role assigned cannot perform any operation in any of the domains in the server. The same user can be assigned multiple roles if required in the same domain or in different domains. See User roles in a domain-level security enabled scenario that shows the scope of the assigned roles as a Venn diagram, for a domain-level security enabled scenario in Rational® Test Control Panel server.

figure showing user roles as a venn diagram — Figure 1. User roles in a domain-level security enabled scenario

Roles and permissions

The following table shows the permissions to perform functions in Rational® Test Control Panel for the different roles assigned:

Role	Create, delete, and rename domains	Assign roles in a domain	Perform Admin functions in a domain	Perform domain-specific functions using UI	Access domains using APIs
Server Administrator
Domain Administrator
User (domain-specific)
API User

To add a user to a domain, you must assign that user a role in the domain. For information about assigning roles, see Adding and removing domain privileges.

For information about making agents and proxies work with domain-level security, see Creating and assigning security tokens and Configuring agents and proxies to use security tokens.

Best practices

You must create agent and proxy tokens for users with only the API User role assigned. By this precaution, you can limit what those tokens are allowed to do. For example, calls that use those tokens cannot delete resources such as Library artifacts or stub scenarios.
Do not give agents or proxies user-generated tokens for a Server Administrator or Domain Administrator.
When a Server Administrator starts a stub, that stub gets all the permissions of that user. You must assign separate roles for users for administration tasks and for running stubs in a domain.
The user who is designated to start and stop stubs can lock the environment. When an environment is locked, other users will be unable to make changes to that environment in Rational® Test Control Panel although they can view stubs. Other users can use the Unlock Environment option to request to unlock the locked environment. Requesting an unlock sends a message to the user who locked the environment. That user can reject the request, leaving the environment locked. Otherwise, the environment automatically unlocks after a specified time. An unlocked environment allows any user to start or stop stubs in that environment. The audit log on the Administration page contains an entry when an environment unlock request is automatically approved.