Managing users
IBM® Rational® Test Control Panel has multiple choices associated with its security model. Depending on the security option selected during installation of the Rational® Test Control Panel, different options are available based on the user accounts.
Security model
The features available within Rational® Test Control Panel depend on the security model option chosen during installation but the applications security settings can be changed at any time after installation.
User types
- System administrators
- Users
- Change the server login passwords of other users and assign administrative privileges to other
users if the built-in security functionality of the server is being used.Note: If the Active Directory or LDAP security models are being used, user administrator tasks are managed by Active Directory or LDAP (whichever is applicable).
- Create, rename, and delete domains.
- Delete published stubs.
- View the activity and audit logs of the server.
- Change their own server login passwords within
Rational® Test Control
Panel if the
built-in security functionality of the server is being used.Note: If the Active Directory or LDAP security models are being used, users can change the server login passwords within Active Directory or LDAP (whichever is applicable).
- View the Environment and start and stop stubs.
- View agents.
- View and modify scheduled tests.
User privileges
The following table outlines how access rights are determined by the security model option used.
If this Rational® Test Control Panel security model option is being used... |
Who can access Rational® Test Control Panel as a user? |
Who can be a Rational® Test Control Panel system administrator? |
---|---|---|
None |
Anyone who knows the server applications URL. |
Anyone who knows the server applications URL. Note: This means that users cannot be created within the server application.
|
Rational® Test Control Panel Built-in |
Anyone who has been assigned a user name and password by a administrator. |
When creating or modifying users, a system administrator can specify that a particular user is a system administrator. |
Active Directory/Lightweight Directory Access Protocol (LDAP) |
Any user with an Active Directory/LDAP user account that is a member of an Active Directory/LDAP user group that is selected during a fresh installation of the server or when you modify an existing installation. |
A system administrator must have an Active Directory/LDAP user account that is a member of an Active Directory/LDAP administrators group that was selected during (or after) installation of the server. |
User roles
- Domain administrator
- (Domain) user
- (Domain) API user
- System administrators can accomplish the following tasks:
- Create new domains.
- Add and remove other users to and from domains.
- Assign and remove domain user, domain API user, or domain administrator roles to those users.
- View the activity and audit logs of the server.
- Domain administrators can accomplish the following domain-level tasks in the domain(s) in which
they have that role:
- Add and remove other users to and from domains.
- Assign and remove domain user, domain API user, or domain administrator roles to those users.
- Delete projects published by other users.
- Delete scenarios created by other users.
- Delete Recording Studio recordings of other users.
Note: To accomplish all of these domain-level tasks, system administrators must assign themselves or be assigned to the domain administrator role. - Domain users can accomplish the following domain-level tasks in the domain(s) in which they have
that role:
- View Recording Studio recordings of other users.
- View the Environments landscape.
- View agents.
- View and modify scheduled tests.
- Publish stubs.
- Start and stop stubs.
- domain API users can access server command-line functions and REST API for the domain(s) in which they have that role, including starting and stopping stubs, but cannot log into and access the user interface. It is recommended that you create one (or more) user accounts with the API user role and have your remote processes (such as the Rational® Integration Tester Agent or automated scripts that call the REST API) operate as these users by providing them security tokens generated for one of these API users. This prevents the tokens that are stored with the unattended processes from being used to access the user interface. For more information about creating security tokens, see Creating and assigning security tokens.