Administrative user roles settings and CORBA naming service user settings
Use the Administrative User Roles page to give users specific authority to administer application servers through tools such as the console or wsadmin scripting. The authority requirements are only effective when global security is enabled. Use the Common Object Request Broker (CORBA) naming service users settings page to manage CORBA naming service users settings.
To view the Console Users console page, complete either of the following steps:
- Click Security > Global security > Administrative User Roles.
- Click Users and Groups > Administrative User Roles.
If we are using local OS, the SIB administrative security panel's searches can use both the "?" and "*" search characters. However. if you switch to federated repositories, the searches will not work with the "?" character but will with the "*" character.
To view the CORBA naming service groups console page, click Environment > Naming > CORBA Naming Service Groups.
(zos) Note: When a third-party authorization such as Tivoli Access Manager or System Authorization Facility (SAF) for z/OS is used, the information in this panel might not represent the data in the provider. Also, any changes to this panel might not be reflected in the provider automatically. Follow the provider's instructions to propagate any changes made here to the provider.
Click Refresh All to automatically update the node agent and all of the nodes when a new user is created with the Administrator or Admin Security Manager role. When you click Refresh All, we do not need to manually restart the node agent under an existing Administrator before the new user is recognized with one of these roles. This button automatically invokes the AuthorizationManager refreshAll MBean method. To invoke this method manually, read about Fine-grained administrative security in heterogeneous and single-server environments.
User (Administrative user roles)
Specifies users.
The users that are entered must exist in the configured active user registry.
Information Value Data type: String
User (CORBA naming service users)
Specifies CORBA naming service users.
The users that are entered must exist in the configured active user registry.
Information Value Data type: String
Role (Administrative user roles)
Specifies user roles.
The following administrative roles provide different degrees of authority that are needed to perform certain application server administrative functions:
- Administrator
- The administrator role has operator permissions, configurator permissions, and the permission required to access sensitive data including server password, LTPA> (LTPA) password and keys, and so on.
- Operator
- The operator role has monitor permissions and can change the run-time state. For example, the operator can start or stop services.
- Configurator
- The configurator role has monitor permissions and can change the WAS configuration.
- Deployer
- The deployer role can complete both configuration actions and run-time operations on applications.
- Monitor
- The monitor role has the least permissions. This role primarily confines the user to viewing the application server configuration and current state.
- adminsecuritymanager
- The adminsecuritymanager role has privileges for managing users and groups from within the console and determines who has access to modify users and groups using administrative role mapping. Only the adminsecuritymanager role can map users and groups to administrative roles, and by default, AdminId is granted to the adminsecuritymanager.
- iscadmins
- The iscadmins role has administrator privileges for managing users and groups from within the console only.
To manage users and groups, click Users and Groups in the console navigation tree. Click either Manage Users or Manage Groups.
Information Value Data type: String Range: Administrator, Operator, Configurator, Deployer, Monitor, and iscadmins Other arbitrary administrative roles might also be visible in the console collection table. Other contributors to the console might create these additional roles, which can be used for applications that are deployed to the console.
Role (CORBA naming service users)
Specifies naming service user roles.
A number of naming roles are defined to provide degrees of authority that are needed to perform certain application server naming service functions. The authorization policy is only enforced when global security is enabled. The following roles are valid: CosNamingRead, CosNamingWrite, CosNamingCreate, and CosNamingDelete.
The roles now have authority levels from low to high:
- CosNamingRead
- We can query the application server name space by using, for example, the JNDI lookup method. The EVERYONE special-subject is the default policy for this role.
- CosNamingWrite
- We can perform write operations such as JNDI bind, rebind, or unbind, plus CosNamingRead operations.
- CosNamingCreate
- We can create new objects in the name space through operations such as JNDI createSubcontext and CosNamingWrite operations.
- CosNamingDelete
- We can destroy objects in the name space, for example using the JNDI destroySubcontext method and CosNamingCreate operations.
Information Value Data type: String Range: CosNamingRead, CosNamingWrite, CosNamingCreate and CosNamingDelete
Login status (Administrative user roles)
Whether the user is active or inactive.
Related concepts
(zos) System Authorization Facility considerations for the operating system and application levels
Fine-grained administrative security in heterogeneous and single-server environments
Administrative console buttons Administrative console page features Administrative console scope settings Administrative console preference settings migrateEAR utility for Tivoli Access Manager