WAS v8.5 > Secure applications > Authorizing access to resources

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 WAS administrative functions. Refer to the descriptions of these roles in Administrative roles.

• Before you 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.

Use dmgr console to assign users and groups to administrative roles and to identify users who can perform WAS administrative functions. In the dmgr console,

1. Click Users and Groups. Click either Administrative User Roles or Administrative Group Roles.
2. To add a user or a group, click Add on the Console users or Console groups panel.
3. 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.
4. 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.
5. 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.
6. 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.
7. After the modifications are complete, click Save to save the mappings.

8. Restart the application server for changes to take effect.

After you assign users to administrative roles, you must restart the server 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 dmgr 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.
• 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 dmgr console or wsadmin scripting. The authority requirements are only effective when administrative security is enabled. Use the Common Object Request Broker Architecture (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 dmgr 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 your 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.
• 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 dmgr 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.
• 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 dmgr console or wsadmin scripting. The authority requirements are only effective when administrative security is enabled. Use the Common Object Request Broker Architecture (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 dmgr 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 your 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

Authorizing access to resources
Assigning users and groups to roles
Assigning users to RunAs roles

+

Search Tips   |   Advanced Search