Propagating administrative role changes to Tivoli Access Manager

These steps provide an example of how to migrate the admin-authz.xml file.

Additions and changes to console users and groups are not automatically added to the Tivoli Access Manager object space after the Java Authorization Contract for Containers (JACC) provider for Tivoli Access Manager is configured. Changes to console users and groups are saved in the admin-authz.xml file and this file must be migrated before any changes take effect. The JACC provider for Tivoli Access Manager includes the migrateEAR migration utility for incorporating console user and group changes into the Tivoli Access Manager object space.

The migrateEAR utility is used to migrate the changes made to console users and groups after the JACC provider for Tivoli Access Manager is configured. The utility does not need to run for changes and additions to console users and groups made prior to the configuration of the JACC provider for Tivoli Access Manager because the changes made to the admin-authz.xml and naming-authz.xml files are automatically migrated at configuration time. Furthermore, the migration tool does not need to run before deploying standard Java EE applications; Java EE application policy deployment is also performed automatically.

For example, if we wanted to migrate the admin-authz.xml file, perform the following steps:

1. (dist)(zos) Set up the environment.

   Before running the migrateEAR utility, set up the environment by running the setupCmdLine.bat or setupCmdLine.sh file located in the app_server_root/bin directory.

   Make sure that the WAS_HOME environment variable is set to the WebSphere Application Server installation directory.

2. Change to the app_server_root/bin directory where the migrateEAR utility is located.

3. Run the migrateEAR utility to migrate the data contained in the admin-authz.xml file. Use the parameter descriptions listed in migrateEAR utility for Tivoli Access Manager.

   For example:

   migrateEAR
   -j "app_server_root/profiles/profile_name/config/cells/cell_name/xml_filename"
   -a sec_master  -p password  -w wsadmin  -d o=ibm,c=us
   -c file:/"app_server_root/java/jre/PdPerm.properties"
   -z Roles

   where xml_filename might be admin-authz.xml or naming-authz.xml. The -z Roles parameter is optional and when specified adds a subdirectory under the current directory structure in which to store the role mapping. For example,
   /WebAppServer/deployedResouces/Roles

   If -z Roles is not specified, the role mapping is stored in the current directory structure. For example,

   /WebAppServer/deployedResouces

   (iseries) For example:

   migrateEAR -profileName default -j  profile_root/config/cells/cell_name/xml_filename
   -a sec_master
   -p password -w wsadmin -d o=ibm,c=us
   -c file: profile_root/etc/pd/PdPerm.properties
   -z Roles

   where xml_filename might be admin-authz.xml or naming-authz.xml.

   • The -j parameter defaults to the file: profile_root/config/cells/cell_name/admin-authz.html

   • The -c parameter defaults to the file: profile_root/etc/pd/PdPerm.properties. The output of the utility is logged in the pdwas_migrate.log file. The pdwas_migrate.log file is created in the profile_root/logs directory.

   • The -profile_name parameter is optional and defaults to the default profile name.

   • The -z Roles parameter is optional and when specified adds a subdirectory under the current directory structure in which to store the role mapping. For example,
     /WebAppServer/deployedResouces/Roles

     If -z Roles is not specified, the role mapping is stored in the current directory structure. For example,

     /WebAppServer/deployedResouces

   A status message is displayed when the migration completes. Output of the utility is logged to the pdwas_migrate.log file, which is created in the directory where the utility is run. Check the log file after each migration. If the log file displays errors, check the last recorded transaction, correct the source of the error, and rerun the migration utility. If the migration is unsuccessful, verify that you supplied the correct values for the -c and -j options.

4. WAS does not require a restart for the changes to take effect.

Related tasks

Authorizing access to administrative roles

migrateEAR utility for Tivoli Access Manager