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 > Global
security > Administrative User
Roles.
- Click Users and Groups > Administrative User
Roles.
Note: If you 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 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 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 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, Deployer, 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 |