Administrative roles and naming service authorization

Administrative roles and naming service authorization

WebSphere Application Server extends the Java EE security role-based access control to protect the product administrative and naming subsystems.

Administrative roles

A number of administrative roles are defined to provide the degrees of authority needed to perform certain WAS administrative functions from either the administrative console or the system management scripting interface called wsadmin. The authorization policy is only enforced when administrative security is enabled. The following table describes the administrative roles:

Role Description
Monitor Least amount of administrative privileges. A monitor can...

View the WAS configuration.
View the current state of the Application Server.

Configurator Monitor privilege plus the ability perform day-to-day configuration tasks...

Create a resource.
Map an application server.
Install and uninstall an application.
Deploy an application.
Assign users and groups-to-role mapping for applications.
Set up Java 2 security permissions for applications.
Customize the CSIv2, SAS, and SSL configurations.

Operator Monitor privileges plus ability to change the runtime state. For example, an operator can complete the following tasks:

Stop and start the server.
Monitor the server status in the administrative console.

Administrator Operator and configurator privileges plus additional privileges:

Modify the server user ID and password.
Configure authentication and authorization mechanisms.
Enable or disable administrative security.
Enforce Java 2 security using the Use Java 2 security to restrict application access to local resources option.
Change the LTPA password and generate keys.
Create, update, or delete users in the federated repositories configuration.
Create, update, or delete groups in the federated repositories configuration.

An administrator cannot map users and groups to the administrator roles.

For information on how to assign federated repository management rights to users who are not assigned the WAS Administrator role, see the topic, Mapping users and groups to roles for assigning federated repository management rights in the topic, Providing security.

Adminsecuritymanager Only users granted this role can map users to administrative roles. Also, when fine-grained administrative security is used, only users granted this role can manage authorization groups.
Deployer Users granted this role can perform both configuration actions and runtime operations on applications.
Auditor Users granted this role can view and modify the configuration settings for the security auditing subsystem. For example, a user with the auditor role can complete the following tasks:

Enable and disable the security auditing subsystem.
Select the event factory implementation to be used with the event factory plug-in point.
Select and configure the service provide, or emitter. or both to be used with the service provider plug-in point.
Set the audit policy that describes the behavior of the application server in the event of an error with the security auditing subsystem.
Define which security events are to be audited.
The auditor role includes the monitor role. This allows the auditor to view but not change the rest of the security configuration.
iscadmins This role is only available for administrative console users and not for wsadmin users. Users granted this role have administrator privileges for managing users and groups in the federated respositories. For example, a user of the iscadmins role can complete the following tasks:

Create, update, or delete users in the federated repositories configuration.
Create, update, or delete groups in the federated repositories configuration.

Deployer This role is only available for wsadmin users and not for administrative console users. Users granted this role can perform both configuration actions and run-time operations on applications.

When administrative security is enabled, the administrative subsystem role-based access control is enforced. The administrative subsystem includes the security server, the administrative console, the wsadmin scripting tool, and all the JMX MBeans. When administrative security is enabled, both the administrative console and the administrative scripting tool require users to provide the required authentication data. Moreover, the administrative console is designed so the control functions that display on the pages are adjusted, according to the security roles that a user has. For example, a user who has only the monitor role can see only the non-sensitive configuration data. A user with the operator role can change the system state.

When we are changing registries (for example, from a federated repository to LDAP), remove the information that pertains to the previously configured registry for console users and console groups.

The WAS run-time code, which runs under the server identity, requires authorization for some run-time operations. We can either explicitly enter the server identity and password or the identity can be auto-generated. In the former case, the server identity is a valid user in the registry. In the latter case, use the internalServerId feature to generate a server identity automatically. The configuration panel for each user registry enables us to make this choice. For an internalServerId, enter the administrator ID or adminID in the Primary administrative user name field. This adminID is a valid user in the registry, and the password for this ID is not required and is not saved in the configuration. See "Internal server ID" in the section below.
If no explicit users or groups are assigned to administrative roles, we can log into the administrative console or to the wsadmin scripting tool using the server identity or adminID when using the internalServerId feature to perform administrative operations and to assign other users or groups to administrative roles. This is possible because the server identity (or the adminID) is assigned automatically to the adminsecuritymanager role. Only the users/groups associated with the adminsecuritymanager can manage the users/groups to all administrative roles. Once you login using the server identity (or adminID), the administrative security policy allows us to perform the operations such as:

Change server ID and server password
Enable or disable WAS administrative security
Enforce Java 2 security using the Use Java 2 security to restrict application access to local resources option.
Change the LTPA password or generate keys

A special configuration is not required to enable the server identity as specified when enabling administrative security for administrative use because the server identity is automatically mapped to the administrator role. We can add or remove users and groups to or from the administrative roles from the WAS administrative console. However, we must restart the server for the changes to take effect. A best practice is to map a group, rather than specific users, to administrative roles because this approach is more flexible and easier to administer. By mapping a group to an administrative role, adding or removing users to or from the group occurs outside of WAS and does not require a server restart for the change to take effect.

When administrative security is enabled, appservers run under the server identity that is defined under the active user registry configuration. Although it is not shown on the administrative console and in other tools, a special Server subject is mapped to the administrator role. The WAS runtime code, which runs under the server identity, requires authorization to runtime operations. If no other user is assigned administrative roles, we can log into the administrative console or to the wsadmin scripting tool using the server identity to perform administrative operations and to assign other users or groups to administrative roles. Because the server identity is assigned to the administrative role by default, the administrative security policy requires the administrative role to perform the following operations:

Change server ID and server password
Enable or disable WASadministrative security
Enforce Java 2 security using option: Use Java 2 security to restrict application access to local resources
Change the LTPA password or generate keys
Assign users and groups to administrative roles

v6.1 release of WAS and subsequent releases require the following:

An administrative user, distinguished from the server user identity, to improve auditability of administrative actions. The user name specifies a user with administrative privileges defined in the local operating system.
Distinguish the server identity from the administrative user identity to improve auditability. The server user identity is used for authenticating server-to-server communications.
The internal server ID enables the automatic generation of the user identity for server-to-server authentication. Automatic generation of the server identity supports improved auditability for cells only for v6.1 or later nodes. In the v6.1 release of WAS, we can save the internally-generated server ID because the Security WebSphere Common Configuration Model (WCCM) model contains a new tag, internalServerId. We do not need to specify a server user ID and a password during security configuration except in a mixed-cell environment. An internally-generated server ID adds a further level of protection to the server environment because the server password is not exposed as it is in releases prior to v6.1. However, to maintain backwards compatibility, we must specify the server user ID if we use earlier versions of WAS.
When enabling security, we can assign one or more users and groups to naming roles. However, before assigning users to naming roles, configure the active user registry. User and group validation depends on the active user registry.
Ability to map a special-subject to the administrative roles. A special-subject is a generalization of a particular class of users. The AllAuthenticated or the AllAuhenticatedInTrustedRealms (when cross realm is involved) special subjects mean that the access check of the administrative role ensures that the user making the request is at least authenticated. The Everyone special subject means anyone, authenticated or not, can perform the action as if security is not enabled.

ZOS notes

WAS for z/OS security customization dialogs prime the administrative subsystem to accept the MVS identities of all the started WAS system tasks (for example, controllers, servants, and so on) as WebSphere administrators and the configured administrator identity. If a federated repository, a stand-alone LDAP registry, or a stand-alone custom registry is specified, the configured server identities are used for work that is run by the system instead of for work that is run by the started task identities.

The value of the com.ibm.security.SAF.authorization setting controls whether SAF EJBROLE profiles or the console settings are used to control access to administration profiles rather than the console users. When property, com.ibm.security.SAF.authorization, is set to true, SAF authorization is selected and SAF EJBROLE profiles are used to control access to administrative roles.
With System Authorization Facility (SAF) authorization any values in the console users and console groups are ignored.
If WAS authorization rather than SAF authorization is used to restrict access to Java EE roles, WAS for z/OS automatically maps the server identity specified when enabling administrative security to the administrative role. When administrative security is enabled, WASs for z/OS runs under the server identity that is defined under the active user registry configuration. Although it is not shown on the administrative console and in other tools, a special Server subject is mapped to the administrator role.

Naming service authorization

CosNaming functions affect the content of the WAS name space through either JNDI calls or with CORBA clients invoking CosNaming methods directly.

Four security roles...

CosNamingRead

We can query the WAS name space, using, for example, the JNDI lookup method. The special-subject, Everyone, is the default policy for this role.

CosNamingWrite

We can perform write operations such as JNDI bind, rebind, or unbind, and CosNamingRead operations. As a default policy, Subjects are not assigned this role.

CosNamingCreate

Create new objects in the name space through such operations as JNDI createSubcontext and CosNamingWrite operations. As a default policy, Subjects are not assigned this role.

CosNamingDelete

We can destroy objects in the name space, for example using the JNDI destroySubcontext method and CosNamingCreate operations. As a default policy, Subjects are not assigned this role.

(ZOS) When we configure a local operating system registry with WAS for z/OS, factors require some additional considerations. Refer to Select a registry or repository and Configure local operating system registries for more information. If we specify federated repositories, a stand-alone LDAP registry, or a stand-alone custom registry, we must remove the local operating system customization by deleting the pre-configured WAS configuration group and administrator identity from the console group and delete the console users.

A Server special-subject is assigned to all of the four CosNaming roles by default. The Server special-subject provides a WAS process, which runs under the server identity, to access all the CosNaming operations. The Server special-subject does not display and cannot be modified through the administrative console or other administrative tools.

Special configuration is not required to enable the server identity as specified when enabling administrative security for administrative use because the server identity is automatically mapped to the administrator role.

Users, groups, or the special subjects AllAuthenticated and Everyone can be added or removed to or from the naming roles from the WAS administrative console at any time. However, a server restart is required for the changes to take effect.

(ZOS) Configuration is not required to enable the server identity (as specified) when enablingadministrative security for administrative use because the server identity is automatically mapped to the administrator role. Users, groups, or the special subjects AllAuthenticated and Everyone can be added or removed to or from the naming roles from the WAS administrative console at any time. However, a server restart is required for the changes to take effect. When SAF Authorization is chosen, a server restart is not needed to authorize additional users or groups.

A best practice is to map groups or one of the special-subjects, rather than specific users, to naming roles because it is more flexible and easier to administer in the long run. By mapping a group to a naming role, adding or removing users to or from the group occurs outside of WAS and does not require a server restart for the change to take effect.

The CosNaming authorization policy is only enforced when administrative security is enabled. When administrative security is enabled, attempts to do CosNaming operations without the proper role assignment result in an org.omg.CORBA.NO_PERMISSION exception from the CosNaming server.

Each CosNaming function is assigned to only one role. Therefore, users who are assigned the CosNamingCreate role cannot query the name space unless they have also been assigned CosNamingRead. And in most cases a creator needs to be assigned three roles: CosNamingRead, CosNamingWrite, and CosNamingCreate. The CosNamingRead and CosNamingWrite roles assignment for the creator example are included in the CosNamingCreate role. In most of the cases, WAS administrators do not have to change the roles assignment for every user or group when they move to this release from a previous one.

Although the ability exists to greatly restrict access to the name space by changing the default policy, unexpected org.omg.CORBA.NO_PERMISSION exceptions can occur at runtime. Typically, Java EE applications access the name space and the identity they use is that of the user that authenticated to WAS when accessing the Java EE application. Unless the Java EE application provider clearly communicates the expected naming roles, use caution when changing the default naming authorization policy.

Subtopics

Administrative roles for business level applications

Related:

Authorization technology
Administrative roles
Assign users and groups to roles
Assign users to naming roles
Select a registry or repository
(ZOS) (ZOS) Control access to console users when using a Local OS Registry

Role	Description
Monitor	Least amount of administrative privileges. A monitor can... View the WAS configuration. View the current state of the Application Server.
Configurator	Monitor privilege plus the ability perform day-to-day configuration tasks... Create a resource. Map an application server. Install and uninstall an application. Deploy an application. Assign users and groups-to-role mapping for applications. Set up Java 2 security permissions for applications. Customize the CSIv2, SAS, and SSL configurations.
Operator	Monitor privileges plus ability to change the runtime state. For example, an operator can complete the following tasks: Stop and start the server. Monitor the server status in the administrative console.
Administrator	Operator and configurator privileges plus additional privileges: Modify the server user ID and password. Configure authentication and authorization mechanisms. Enable or disable administrative security. Enforce Java 2 security using the Use Java 2 security to restrict application access to local resources option. Change the LTPA password and generate keys. Create, update, or delete users in the federated repositories configuration. Create, update, or delete groups in the federated repositories configuration. An administrator cannot map users and groups to the administrator roles. For information on how to assign federated repository management rights to users who are not assigned the WAS Administrator role, see the topic, Mapping users and groups to roles for assigning federated repository management rights in the topic, Providing security.
Adminsecuritymanager	Only users granted this role can map users to administrative roles. Also, when fine-grained administrative security is used, only users granted this role can manage authorization groups.
Deployer	Users granted this role can perform both configuration actions and runtime operations on applications.
Auditor	Users granted this role can view and modify the configuration settings for the security auditing subsystem. For example, a user with the auditor role can complete the following tasks: Enable and disable the security auditing subsystem. Select the event factory implementation to be used with the event factory plug-in point. Select and configure the service provide, or emitter. or both to be used with the service provider plug-in point. Set the audit policy that describes the behavior of the application server in the event of an error with the security auditing subsystem. Define which security events are to be audited. The auditor role includes the monitor role. This allows the auditor to view but not change the rest of the security configuration.
iscadmins	This role is only available for administrative console users and not for wsadmin users. Users granted this role have administrator privileges for managing users and groups in the federated respositories. For example, a user of the iscadmins role can complete the following tasks: Create, update, or delete users in the federated repositories configuration. Create, update, or delete groups in the federated repositories configuration.
Deployer	This role is only available for wsadmin users and not for administrative console users. Users granted this role can perform both configuration actions and run-time operations on applications.