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, 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, 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.

Creating domains
Permissions
Best practices

Creating domains

For a stub to have restricted access, it must have its own domain. An 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.

Permissions

When domain-level security is off but standard user security is on, a user can have one of two roles:

Server Administrator
User

When domain-level security is on, those two roles still apply server-wide. Additionally, users can have roles within individual domains:

Domain Administrator
Domain User (or simply "User" in a domain context)
API User

A user who has any of those roles in a domain is said to be a member of that domain.

A Server Administrator can create and delete domains, rename domains, and assign roles within domains, but cannot perform actions in a particular domain, such as starting stubs.

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 Domain User.

A Domain User can perform actions in that domain such as starting and stopping stubs, or locking environments.

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. These users are typically those for whom tokens are generated for agents, proxies, or automated scripts that call the ant or command-line APIs.

To add a user to a domain, 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 Rational Integration Tester agents and proxies to use security tokens.

Best practices

Create agent and proxy tokens for accounts that have only the API User role. By this precaution, you 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.
Never 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. Use separate accounts for administration and for running stubs.
The visibility of the stubs that are running in an environment can be controlled separately from the ability to start and stop stubs in that environment. 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 run stubs on a limited basis through Integration Tester. Other users must not use the Request unlock environment option. Doing so automatically unlocks the environment after a specified time, allowing anyone to start or stop stubs in the environment. The audit log on the Administration page contains an entry when an environment unlock request is automatically approved.

Feedback