Determine if your application depends on the Java thread identity and the OS thread identity being synchronized to the same value. Important: Application Synch to OS Thread Allowed support is only supported if your WebSphere Application Server is configured to use local OS registry. For more information on why you would use this function, refer to:
Enabling and Disabling Operating System Thread Synchronization: The WebSphere Application Server for z/OS server provides a global switch controlled by the administrator to enable or disable any association (or synchronization) of Java thread identities and OS thread identities. The default settings disable the ability to synchronize the operating system thread identity to the WebSphere Application Server for z/OS identity regardless of the values specified in the installed applications. Refer to WebSphere Application Server for z/OS global security options for more information.
Note: Exercise caution when enabling this support because it can cause general z/OS system resources (such as files and sockets) to run using identities established by other WebSphere Application Server for z/OS applications.
Thread identity and access control: When setting the OS thread identity, you must consider the roles of the different identities involved thread identity synchronization. For more information, refer to Understanding Java 2 Platform, Enterprise Edition identities and operating system thread identities.
Security migration considerations: When setting thread identity, use application Synch to OS Thread Allowed support to obtain the required compatible behavior between WebSphere Application Server for z/OS Version 3.5 and WebSphere Application Server for z/OS Version 5. WebSphere Application Server for z/OS Version 3.5 always made the Java thread identity and the OS thread identity the same. WebSphere Application Server for z/OS Version 5 does not and runs with servant identity on the OS thread by default. This means that if you are migrating servlets or Java Server Pages from WebSphere Application Server for z/OS Version 3.5 to WebSphere Application Server for z/OS Version 5, use the WebSphere application Server Synch to OS Thread Allowed option to synchronize your identities so the application functions correctly between versions.
Refer to Deploying secured applications and Developing secured applications for details on WebSphere role-based security.
Application events that modify the Java thread identity: Use application Synch to OS Thread Allowed to synchronize the Java thread identity with the OS thread identity for the duration of the current Java 2 Platform, Enterprise Edition (J2EE) application request. Application or system events that modify the Java thread identity and OS thread identity values include:
When RunAs Caller is specified, both the identity of the called object and the identity of the thread object are unchanged. Specifying RunAs System and RunAs Specified can change the WebSphere security identity. When Synch to OS Thread Allowed is enabled, specifying RunAs System and RunAs Caller modifies the OS thread identity.
Programming considerations when using application Synch to OS Thread Allowed: Programming considerations when using Synch to OS Thread Allowed exist because your security configuration establishes access control to application files, logs, binaries, and Hierarchical File System (HFS) files only for the servant identity. Using Synch to OS Thread Allowed support might require other identities to request access to these resources as well. All resource usage by applications other than those specifically described above require you to specifically grant access to all identities that might require access. This includes:
Synch to OS Thread Allowed support lets you use a consistent user identity to manage J2EE application access control to native system resources (such as the application configuration files, logs, binaries, and the HFS file system) and J2EE-protected resources (J2EE methods, Java Naming and Directory Interface (JNDI) or COSNaming name space, and WebSphere administrative operations).
When application users have to manipulate HFS files, you can control access to these files in two ways: