+

Search Tips   |   Advanced Search

JACC policy propagation

When an application is installed or deployed in WebSphere Application Server, the security policy information in the application is propagated to the provider when the configuration is saved. The context ID for the application is saved in its application.xml file, used for propagating the policy to the Java Authorization Contract for Containers (JACC) provider, and also for access decisions for Java EE resources.

This topic references one or more of the application server log files. As a recommended alternative, we can configure the server to use the High Performance Extensible Logging (HPEL) log and trace infrastructure instead of using SystemOut.log , SystemErr.log, trace.log, and activity.log files on distributed and IBM i systems. We can also use HPEL in conjunction with the native z/OS logging facilities. If we are using HPEL, we can access all of the log and trace information using the LogViewer command-line tool from the server profile bin directory. See the information about using HPEL to troubleshoot applications for more information on using HPEL.

When an application is uninstalled, the security policy information in the application is removed from the provider when the configuration is saved.

If the provider implemented the RoleConfiguration interface, the security policy information that is propagated to the policy provider also contains the authorization table information. See Interfaces that support JACC for more information about this interface.

If an application does not contain security policy information, the PolicyConfiguration (and the RoleConfiguration, if implemented) objects do not contain any information. The existence of empty PolicyConfiguration and RoleConfiguration objects indicates that security policy information for the module does not exist.

After an application is installed, it can be updated without being uninstalled and reinstalled. For example, a new module can be added to an existing application, or an existing module can be modified. In this instance, the information in the impacted modules is propagated to the provider by default. A module is impacted when the deployment descriptor of the module or annotations within the module are changed as part of the update. If the provider supports the RoleConfiguration interfaces, the entire authorization table for that application is propagated to the provider.

If the security information is not propagated to the provider during application updates, we can set the com.ibm.websphere.security.jacc.propagateonappupdate JVM property to false in the deployment manager, in a Network Deployment environment, or the unmanaged base application server. If false, any updates to an existing application in the server are not propagated to the provider. You also can set this property on a per-application basis using the custom properties of an application. The wsadmin tool can be used to set the custom property of an application. If this property is set at the application level, any updates to that application are not propagated to the provider. If the update to an application is a full update, for example, a new application EAR file is used to replace the existing one, and the provider is refreshed with the entire application security policy information.

When an application is installed and saved, the security policy information in that application is updated in the provider from the deployment manager. The application is not propagated to its respective nodes until the synchronization command is issued and completed. Also, when an application is uninstalled and saved at the deployment manager, the policy for that application is removed from the JACC provider.

However, unless the synchronization command is issued and completed from the deployment manager to the nodes hosting the application, the applications are still running in the respective nodes. In this instance, deny any access to this application because the JACC provider does not contain the required information to make the access decision for that application. Any updates to the application already installed as described previously are also propagated to the provider from the deployment manager. The changes in the provider are not synchronized with the applications in the nodes until the synchronization is completed.

As mentioned earlier, the security policy information is propagated to the JACC provider during the save operation. The SystemOut.log file indicates the success or failure of the propagation to the provider. Check the log file after the installation to ensure that the propagation had no problems. If the propagation had any problems, access to the application fails when Tivoli Access Manager is used as the JACC provider.

If the security policy information for the application is successfully propagated to the provider, the audit statements with the message key SECJ0415I appear. However, if there was a problem propagating the security policy information to the provider (for example: network problems, JACC provider is not available), the SystemOut.log files contain the error message with the message keys SECJ0396E during install or SECJ0398E during modification. The installation of the application is not stopped due to a failure to propagate the security policy to the JACC provider. Also, in the case of failure, no exception or error messages appear during the save operation. When the problem causing this failure is fixed, run the propagatePolicyToJaccProvider tool to propagate the security policy information to the provider without reinstalling the application. For more information, see Propagating security policy of installed applications to a JACC provider .


Related concepts

  • Authorization providers
  • Tivoli Access Manager integration as the JACC provider
  • JACC support in WebSphere Application Server
  • Security annotations


    Related tasks

  • Enable an external JACC provider
  • Authorizing access to Java EE resources using Tivoli Access Manager
  • Propagating security policy of installed applications to a JACC provider
  • Propagating security policies and roles for previously deployed applications

  • Interfaces that support JACC
  • Security authorization provider troubleshooting tips