Use the Administrative User
Roles page to give users specific authority to administer application
servers through tools such as the administrative console or wsadmin
scripting. The authority requirements are only effective when global
security is enabled. Use the Common Object Request Broker Architecture
(CORBA) naming service users settings page to manage CORBA naming
service users settings.
To view the Console Users administrative console
page, complete either of the following steps:
- Click Security > Secure administration, applications, and infrastructure
> Administrative User Roles.
- Click Users and Groups > Administrative User Roles.
To view the CORBA naming service groups administrative console
page, click Environment > Naming > CORBA Naming Service Groups.
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, you 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.
Specifies CORBA naming service users.
The users that are entered must exist in the configured active
user registry.
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 that is required to access sensitive
data including server password, Lightweight Third Party Authentication
(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
WebSphere Application Server configuration.
- Deployer
- The deployer role can perform both configuration actions and runtime
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 administrative 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 administrative console only.
Note: To manage
users and groups, click Users and Groups in the console navigation
tree. Click either Manage Users or Manage Groups.
Data type: |
String |
Range: |
Administrator, Operator, Configurator, Monitor, and iscadmins |
Note: Other arbitrary administrative roles might
also be visible in the administrative 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.
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
- You can query the application server name space by using, for
example, the Java Naming and Directory Interface (JNDI) lookup method.
The EVERYONE special-subject is the default policy for this role.
- CosNamingWrite
- You can perform write operations such as JNDI bind, rebind, or
unbind, plus CosNamingRead operations.
- CosNamingCreate
- You can create new objects in the name space through operations
such as JNDI createSubcontext and CosNamingWrite operations.
- CosNamingDelete
- You can destroy objects in the name space, for example using the
JNDI destroySubcontext method and CosNamingCreate operations.
Data type: |
String |
Range: |
CosNamingRead, CosNamingWrite, CosNamingCreate and CosNamingDelete |