Authorizing access to administrative roles
We can assign users and groups to administrative roles to identify users who can perform WebSphere Application Server administrative functions.
Administrative roles enable you to control access to WebSphere Application Server administrative functions. Refer to the descriptions of these roles in Administrative roles. (zos)
- Use System Authorization Facility (SAF) authorization to control access to administrative roles: When the com.ibm.security.SAF.authorization is set to true, SAF EJBROLE profiles are used to control access to administrative roles. See System Authorization Facility for role-based authorization for more information.
- If we select Use a z/OS security product during profile creation in the z/OS Profile Management Tool, and we additionally specify a value for the SAF profile prefix (previously referred to as the z/OS security domain), the following administrative roles are defined by the customization jobs. The SAF profile prefix can be specified during profile creation, and the configGroup represents the WAS configuration group name that you chose.
RDEFINE EJBROLE (optionalSAFProfilePrefix.)administrator UACC(NONE) RDEFINE EJBROLE (optionalSAFProfilePrefix.)monitor UACC(NONE) RDEFINE EJBROLE (optionalSAFProfilePrefix.)configurator UACC(NONE) RDEFINE EJBROLE (optionalSAFProfilePrefix.)operator UACC(NONE) RDEFINE EJBROLE (optionalSAFProfilePrefix.)auditor UACC(NONE) PERMIT (optionalSAFProfilePrefix.)administrator CLASS(EJBROLE) ID(configGroup) ACCESS(READ) PERMIT (optionalSAFProfilePrefix.)monitor CLASS(EJBROLE) ID(configGroup) ACCESS(READ) PERMIT (optionalSAFProfilePrefix.)configurator CLASS(EJBROLE) ID(configGroup) ACCESS(READ) PERMIT (optionalSAFProfilePrefix.)operator CLASS(EJBROLE) ID(configGroup) ACCESS(READ) PERMIT (optionalSAFProfilePrefix.)auditor CLASS(EJBROLE) ID(configGroup) ACCESS(READ)
- If we decide at a later date to turn on SAF authorization, issue these Resource Access Control Facility (RACF) commands to enable proper WebSphere Application Server operation. We can give a user access to all administrative functions by connecting to the configuration group:
CONNECT mvsid GROUP(configGroup)
- We can also assign individual users to specific roles by issuing the following RACF command:
PERMIT (optionalSAFProfilePrefix.)rolename CLASS(EJBROLE) ID(mvsid) ACCESS(READ)
- You do not need to restart the server for SAF EJBROLE changes to take effect. However, after the SAF changes are made, issue the following RACF command, (or the equivalent for the security system), to refresh the security tables:
SETROPTS RACLIST(EJBROLE) REFRESH
- Use WebSphere Authorization to control access to administrative roles: When com.ibm.security.SAF.authorization is set to false, WebSphere Application Server authorization and the administrative console are used to control access to administrative roles.
- Before we assign users to administrative roles, set up the user registry. For information on the supported registry types, see Select a registry or repository.
- The following steps are needed to assign users to administrative roles.
About this task
Use administrative console to assign users and groups to administrative roles and to identify users who can perform WebSphere Application Server administrative functions. In the administrative console,
- Click Users and Groups. Click either Administrative User Roles or Administrative Group Roles.
- To add a user or a group, click Add on the Console users or Console groups panel.
- To add a new administrator user, follow the instructions on the page to specify a user, and select the Administrator role. Once the user is added to the Mapped to role list, click OK. The specified user is mapped to the security role.
- To add a new administrative group, follow the instructions on the page to specify either a group name or a Special subject, highlight the Administrator role, and click OK. The specified group or special subject is mapped to the security role.
- To remove a user or group assignment, click Remove on the Console Users or the Console Groups panel. On the Console Users or the Console Groups panel, select the check box of the user or group to remove and click OK.
- To manage the set of users or groups to display, click Show filter function on the User Roles or Group Roles panel. In the Search term(s) box, type a value, then click Go. For example, user* displays only users with the user prefix.
- After the modifications are complete, click Save to save the mappings.
- Restart the application server for changes to take effect.
- Shut down the nodes, node agents, and the deployment manager.
- Verify that Java processes are not running. If they are running, discontinue these processes.
- Restart the deployment manager.
- (dist) Resynchronize the nodes. To resynchronize the nodes, run the install_root/bin/syncNode or the install_root/bin/syncNode.sh command for each node. Use the synchNode command.
- (iseries) Resynchronize the nodes. To resynchronize the nodes, run the install_root/bin/syncNode script from the Qshell command line for each node. Use the synchNode command.
- (dist) Restart the nodes. To restart the nodes, run the install_root/bin/startNode or the install_root/bin/startNode.sh command for each node. Use the startNode command.
- (iseries) Restart the nodes. To restart the nodes, run the install_root/bin/startNode script from the Qshell command line for each node. Use the startNode command.
- Start any clusters, if applicable.
(dist)
What to do next
(dist) After we assign users to administrative roles, you must restart the dmgr for the new roles to take effect. However, the administrative resources are not protected until you enable security.
Subtopics
- 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 administrative 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.
- Administrative group roles and CORBA naming service groups
Use the Administrative Group Roles page to give groups specific authority to administer application servers through tools such as the administrative console or wsadmin scripting. The authority requirements are only effective when administrative security is enabled. Use the Common Object Request Broker (CORBA) naming service groups page to manage CORBA Naming Service groups settings.
- Assigning users to naming roles
Use this task to assign users to naming roles using the administrative console.
- Propagating administrative role changes to Tivoli Access Manager
These steps provide an example of how to migrate the admin-authz.xml file.
- migrateEAR utility for Tivoli Access Manager
The migrateEAR utility migrates changes made to console users and groups in the admin-authz.xml and naming-authz.xml files into the Tivoli Access Manager object space.
- Assigning users from a foreign realm to the admin-authz.xml
Operating with the administrative agent and job manager topology allows more situations where we might need to add an administrative user from a different registry into the administrative authorization table (admin-authz.xml). Each administrative user that needs to be added requires the "accessID" format of the user from the remote registry. When that user finally is active in the local cell, the authorization table will already have that accessID required. This task demonstrates how this assignment of users is performed.
Related concepts
Role-based authorization Access control exception for Java 2 security Administrative roles and naming service authorization
Related tasks
Authorizing access to resources Assigning users and groups to roles Assigning users to RunAs roles (zos) Controlling access to console users when using a Local OS Registry