Global security settings

Use this page to configure security. When you enable security, you are enabling security settings on a global level. When security is disabled, WebSphere Application Server performance is increased between 10-20%. Therefore, consider disabling security when it is not needed.

To view this administrative console page, click Security > Global Security.

If you are configuring security for the first time, complete the steps in Configuring server security to avoid problems. When security is configured, validate any changes to the registry or authentication mechanism panels. Click Apply to validate the user registry settings. An attempt is made to authenticate the server ID to the configured user registry. Validating the user registry settings after enabling global security can avoid problems when you restart the server for the first time.

 

Configuration tab

Enabled

Specifies for the server to enable security subsystems.

This flag is commonly referred to as the global security flag in WebSphere Application Server information. When enabling security, set the authentication mechanism configuration and specify a valid user ID and password in the selected user registry configuration.

If you have problems such as the server not starting after enabling security within the security domain, then resynchronize all of the files from the cell to this node. To resynchronize files, run the following command from the node: syncNode -username your_userid -password your_password. This command connects to the deployment manager and resynchronize all of the files.

Data type:	Boolean
Default:	Disable

Enforce Java 2 Security

Specifies whether to enable or disable Java 2 security permission checking. By default, Java 2 security is disabled. However, enabling global security, automatically enables Java 2 security. You can choose to disable Java 2 security, even when global security is enabled.

When Java 2 security is enabled and if an application requires more Java 2 security permissions than are granted in the default policy, then the application might fail to run properly until the required permissions are granted in either the app.policy file or the was.policy file of the application. AccessControl exceptions are generated by applications that do have all the required permissions. Consult the WebSphere Application Server documentation and review the Java 2 Security and Dynamic Policy sections if you are unfamiliar with Java 2 security.

If your server does not restart after you enable global security, you can disable security. Go to your $install_root\bin directory and execute the wsadmin -conntype NONE command. At the wsadmin> prompt, enter securityoff and then type exit to return to a command prompt. Restart the server with security disabled to check any incorrect settings through the administrative console.

Data type:	Boolean
Default:	Disabled
Range:	Enabled or Disabled

Use Domain Qualified User Names

Specifies the user names to qualify with the security domain within which they reside.

Data type:	Boolean
Default:	Disabled
Range:	Enable or Disable

When you specify Use Domain Qualified User Names from the Security > Global Security configuration panel, the run-time call to the getCallerPrincipal() API from an enterprise bean returns the qualified name with the realm prepended twice. For example, the format return is realm/realm/user. You can strip the first realm from the returned value when making API calls. The servlet API getUserPrincipal() works correctly.

Cache Timeout

Specifies the timeout value in seconds for security cache. This value is a relative timeout.

If WebSphere Application Server security is enabled, the security cache timeout can influence performance. The timeout setting specifies how often to refresh the security-related caches.

Security information pertaining to beans, permissions, and credentials is cached.

When the cache timeout expires, all cached information becomes invalid.

Subsequent requests for the information result in a database lookup. Sometimes, acquiring the information requires invoking a Lightweight Directory Access Protocol (LDAP)-bind or native authentication. Both invocations are relatively costly operations for performance. Determine the best trade off for the application, by looking at usage patterns and security needs for the site.

In a 20-minute performance test, setting the cache timeout so that a timeout does not occur yields a 40% performance improvement.

Data type:	Integer
Units:	Seconds
Default:	600
Range:	Greater than 30 seconds

Issue Permission Warning

Specifies that when the Issue permission warning option is enabled, during application deployment and application start, the security run time emits a warning if applications are granted any custom permissions. Custom permissions are permissions defined by the user applications, not Java API permissions. Java API permissions are permissions in package java.* and javax.*.

The WebSphere product provides support for policy file management. A number of policy files are available in this product, some of them are static and some of them are dynamic. Dynamic policy is a template of permissions for a particular type of resource. There is no code base defined or relative code base used in the dynamic policy template. The real code base is dynamically created from the configuration and run-time data. The filter.policy file contains a list of permissions that an application should not have according to the J2EE 1.3 specification. For more information on permissions, see Java 2 security policy files.

Data type:	Boolean
Default:	Disabled
Range:	Enable or Disable

Active Protocol

Specifies the active authentication protocol for Remote Method Invocation over the Internet Inter-ORB Protocol (RMI IIOP) requests when security is enabled. In previous releases the Security Authentication Service (SAS) platform (or z/OS Security Authentication Service on the z/OS platform) was the only available protocol.

An Object Management Group (OMG) protocol called Common Secure Interoperability V2 (CSIv2) supports increased vendor interoperability and additional features. If all of the servers in your security domain are V5 servers, specify CSI as your protocol.

If some servers are 3.x or 4.x servers, specify CSI and SAS.

Data type:	String
Default:	BOTH
Range:	CSI and SAS, CSI

Active Authentication Mechanism

Specifies the active authentication mechanism when security is enabled.

In WebSphere Application Server Network Deployment, Version 5, the active authentication mechanism is not configurable. Also, this version of the product only supports LTPA authentication.

Data type:	String
Default:	LTPA (WebSphere Application Server Network Deployment)

Active User Registry

Specifies the active user registry, when security is enabled. LDAP or a custom user registry is required when running as a UNIX nonroot user or in a multi-node environment.

You can configure settings for one of the following user registries:

• Local operating system.

• LDAP user registry. The LDAP user registry settings are used when users and groups reside in an external LDAP directory. When security is enabled and any of these properties change, go to the Global Security panel and click Apply or OK to validate the changes.

• Custom user registry

Data type:	String
Default:	Local OS
Range:	Local OS, LDAP, Custom

Use FIPS  

Enables the use of FIPS (Federal Information Processing Standard)-approved cryptographic algorithms.

The IBM JSSE Federal Information Processing Standards (FIPS) provider is not supported on the HP-UX platform.

When Use FIPS is enabled, the Lightweight Third Party Authentication (LTPA) implementation uses IBMJCEFIPS. IBMJCEFIPS supports the Federal Information Processing Standard (FIPS)-approved cryptographic algorithms for DES, Triple DES, and AES. Although the LTPA keys are backwards compatible with prior releases of WebSphere Application Server, the LTPA token is not compatible with prior releases.

Note: The IBMJSSEFIPS and IBMJCEFIPS modules are undergoing certification.

WebSphere Application Server provides a FIPS-approved Java Secure Socket Extension (JSSE) provider called IBMJSSEFIPS. A FIPS-approved JSSE requires the Transport Layer Security (TLS) protocol as it is not compatible with the Secure Sockets Layer (SSL) protocol. If you select the Use FIPS checkbox prior to specifying a FIPS-approved JSSE provider and a TLS protocol, the following error message displays at the top of the Global Security panel:

The security policy is set to use only FIPS approved cryptographic 
algorithms. However at least one SSL configuration may not be using a 
FIPS approved JSSE provider. FIPS approved cryptographic algorithms 
may not be used in those cases.

To correct this problem, configure your JSSE provider and security protocol on the SSL Configuration Repertoires panel by completing one of the following tasks:

• Clicking Security > SSL and modifying an existing configuration

• Clicking New and creating a new configuration

---

Configuring global security

Administrative console buttons
Administrative console page features
Administrative console scope settings
Administrative console filter settings
Administrative console preference settings
    

 

---