Create a classes subdirectory in the profile for custom classes

We can create a classes subdirectory in the profile in which we can place the custom security components.

WebSphere Application Server resides in two main default directories:

app_server_root

Contains product JAR files, scripts, and the master copies of the administrative application, samples, and properties files. This directory is referred to by the ${WAS_INSTALL_ROOT} WebSphere Application Server variable. Do not modify files in these directories.

profile_root

Contains user profile data, that is a combination of unique files and symmetric links to files in the app_server_root directories. This directory is referred to by the ${USER_INSTALL_ROOT} WebSphere Application Server variable.

The product files are separated for the following reasons:

• To separate the files that run the product from files we can modify, either by editing or through the administrative interfaces. When you apply product fixes, the separate directory structure keeps these fixes from overwriting user-defined data, such as modifying properties files.

• To isolate configuration differences between profiles. For example, each profile subdirectory can have its own copy of the Java 2 Security files, by which the profile can have a unique Java 2 Security configuration, rather than all profiles conforming to one product-wide configuration only.

WebSphere Application Server provides APIs that we can use to develop our own security components for WebSphere Application Server. For example, we can create custom user registries, custom trust association interceptors, and custom login modules. For other WebSphere Application Server platforms, place the files for the custom security component in the app_server_root/classes directory.

For the IBM i platform, this action is not recommended because the files are accessible from all server profiles, which might not be a desirable or secure behavior. Additionally, the classes directory is granted Java 2 Security AllPermissions authority, which might not be appropriate for the secured environment.

Therefore, create a /classes subdirectory in the profile in which we can place the custom security components. Additionally, the QEJBSVR user profile must have authority to the directory. To create the classes subdirectory and grant the necessary authorities...

1. Use the CRTDIR DIR command to create the classes subdirectory. For example, run the following command from the CL command line:
   CRTDIR DIR(' profile_root/classes')

   Alternatively, we can map or mount a workstation network drive to the iSeries server and create the /classes subdirectory from the workstation command prompt or a graphical file explorer utility such as Windows Explorer.

2. If we are using Java 2 Security, update the profile_root/properties/server.policy file to grant the appropriate Java 2 Security permissions to the classes in the directory. For more information about the permissions, see server.policy file permissions.

3. If we create the directory from the Qshell command line, explicitly grant the QEJBSVR user profile read, write, and run (*RWX) authority to the directory because the proper authorities are not inherited from the parent directory. For example, run the following command:
   CHGAUT OBJ(' profile_root/classes') USER(QEJBSVR) DTAAUT(*RWX)

Results

You have a classes subdirectory that we can use for custom classes.

Related tasks

Develop stand-alone custom registries

server.policy file permissions