Global security settings

Configure administration and the default application security policy. This security configuration applies to the security policy for all administrative functions and is used as a default security policy for user applications. Security domains can be defined to override and customize the security policies for user applications.

From the admin console, click...

Security | Global security

Security has some performance impacts on the applications. The performance impacts can vary depending upon the application workload characteristics. We must first determine that the needed level of security is enabled for the applications, and then measure the impact of security on the performance of the applications.

When security is configured, validate any changes to the user registry or authentication mechanism pages. Click Apply to validate the user registry settings. An attempt is made to authenticate the server ID or to validate the admin ID (if internalServerID is used) to the configured user registry. Validating the user registry settings after enabling administrative security can avoid problems when restarting the server for the first time.

Security configuration wizard

Launches a wizard that enables us to configure the basic administrative and application security settings. This process restricts administrative tasks and applications to authorized users.

Using this wizard, we can configure application security, resource or Java 2 Connector (J2C) security, and a user registry. We can configure an existing registry and enable administrative, application, and resource security.

When we apply changes made using the security configuration wizard, administrative security is turned on by default.

Security configuration report

Launches a security configuration report that gathers and displays the current security settings of the application server. Information is gathered about core security settings, administrative users and groups, CORBA naming roles, and cookie protection. When multiple security domains are configured the report displays the security configuration associated with each domain.

The report does not display application level security information. The report also does not display information on Java Message Service security, bus security, or Web Services Security.

Enable administrative security

Enable administrative security for this application server domain. Administrative security requires that users must authenticate before obtaining administrative control of the application server. Users must be assigned to administrative roles. Set the authentication mechanism configuration and specify a valid user ID and password (or a valid admin ID when internalServerID feature is used) in the selected registry configuration. There is a difference between the user ID (which is normally called the admin ID), which identifies administrators who manage the environment, and a server ID, which is used for server-to-server communication. We do not need to enter a server ID and password when we are using the internal server ID feature. However, optionally, we can specify a server ID and password.

Default: Enabled

To specify the server ID and password...

Security | Global security | User accounts repository | repository | Configure

If we have problems, such as the server not starting after enabling security within the security domain, resynchronize all of the files from the cell to this node. To resynchronize files, from the node:

syncNode -username userid -password password

This command connects to the deployment manager and resynchronizes all of the files.

If the server does not restart after enabling administrative security, we can disable security.

cd app_server_root/bin
./wsadmin.sh -conntype NONE

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.

Local OS user registry users do not need to a password in the user registry (LDAP) configuration.

Enable application security

Enables security for the applications in the environment. This type of security provides application isolation and requirements for authenticating application users. WAS clients must know whether application security is disabled at the target server. Administrative security is enabled, by default. Application security is disabled, by default. To enable application security, enable administrative security. Application security is in effect only when administrative security is enabled.

Default: Disabled

Use Java 2 security to restrict application access to local resources

Enable or disable Java 2 security permission checking. By default, access to local resources is not restricted. We can choose to disable Java 2 security, even when application security is enabled.

When the Use Java 2 security to restrict application access to local resources option is enabled and if an application requires more Java 2 security permissions than are granted in the default policy, 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 not have all the required permissions.

Default: Disabled

Warn if applications are granted custom permissions

That during application deployment and application start, the security runtime issues a warning if applications are granted any custom permissions. Custom permissions are permissions that are defined by the user applications, not Java API permissions. Java API permissions are permissions in the java.* and javax.* packages.

The application server 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. No code base is defined and no relative code base is 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 we do not want an application to have according to the J2EE 1.4 specification.

Important: We cannot enable this option without enabling the option...

Use Java 2 security to restrict application access to local resources

Default: Disabled

Restrict access to resource authentication data

Enable this option to restrict application access to sensitive Java Connector Architecture (JCA) mapping authentication data.

Consider enabling this option when both of the following conditions are true:

• Java 2 security is enforced.

• The application code is granted the accessRuntimeClasses WebSphereRuntimePermission permission in the was.policy file found within the enterprise application archive (EAR) file. For example, the application code is granted the permission when the following line is found in your was.policy file:
  permission com.ibm.websphere.security.WebSphereRuntimePermission "accessRuntimeClasses";

The Restrict access to resource authentication data option adds fine-grained Java 2 security permission checking to the default principal mapping of the WSPrincipalMappingLoginModule implementation. We must grant explicit permission to J2EE applications that use the WSPrincipalMappingLoginModule implementation directly in the JAAS login when Use Java 2 security to restrict application access to local resources and the Restrict access to resource authentication data options are enabled.

Default: Disabled

Current realm definition

Current setting for the active user repository.

This field is read-only.

Available realm definitions

Available user account repositories.

The selections appear in a drop-down list containing:

• Local operating system
• Standalone LDAP registry
• Stand-alone custom registry

Set as current

Enables the user repository after it is configured.

We can configure settings for one of the following user repositories:

Federated repositories

Specify this setting to manage profiles in multiple repositories under a single realm. The realm can consist of identities in:

• The file-based repository built into the system
• One or more external repositories
• Both the built-in, file-based repository and in one or more external repositories

Only a user with administrator privileges can view the federated repositories configuration.

Local operating system

(ZOS) Specify this setting if we want your configured Resource Access Control Facility (RACF ) or System Authorization Facility (SAF)-compliant security server used as the application server user registry.

We cannot use localOS in multiple-node or when running as non-root on a UNIX platform.

The local operating system registry is valid only when we use a domain controller or the WAS ND cell resides on a single machine. In the later case, we cannot spread multiple nodes in a cell across multiple machines as this configuration, using the local OS user registry, is not valid.

Standalone LDAP registry

Use stand-alone LDAP registry settings when users and groups reside in an external LDAP directory. When security is enabled and any of these properties change, go to the Security > Global security page and click Apply or OK to validate the changes.

Since multiple LDAP servers are supported, this setting does not imply one LDAP registry.

Stand-alone custom registry

Implement our own stand-alone custom registry that implements the com.ibm.websphere.security.UserRegistry interface. When security is enabled and any of these properties change, go to the Global security page and click Apply or OK to validate the changes.

Default: Disabled

Configure...

Select to configure the global security settings.

Web and SIP security

Under Authentication, expand Web and SIP security to view links to:

• General settings
• Single sign-on (SSO)
• SPNEGO web authentication
• Trust association

General settings

Select to specify the settings for web authentication.

Single sign-on (SSO)

Select to specify the configuration values for single sign-on (SSO).

With SSO support, web users can authenticate once when accessing both WAS resources, such as HTML, JSP files, servlets, enterprise beans, and Lotus Domino resources.

SPNEGO web authentication

SPNEGO provides a way for web clients and the server to negotiate the web authentication protocol used to permit communications.

Trust association

Select to specify the settings for the trust association. Trust association is used to connect reversed proxy servers to the application servers.

Use the global security settings or customize the settings for a domain.

The use of trust association interceptors (TAIs) for SPNEGO authentication is now deprecated. The SPNEGO web authentication pages now provide a much easier way to configure SPNEGO.

RMI/IIOP security

Under Authentication, expand RMI/IIOP security to view links to:

• CSIv2 inbound communications
• CSIv2 outbound communications

CSIv2 inbound communications

Select to specify authentication settings for requests received and transport settings for connections that are accepted by this server using the Object Management Group (OMG) Common Secure Interoperability (CSI) authentication protocol.

Authentication features include three layers of authentication we can use simultaneously:

• CSIv2 attribute layer. The attribute layer might contain an identity token, which is an identity from an upstream server that already is authenticated. The identity layer has the highest priority, followed by the message layer, and then the transport layer. If a client sends all three, only the identity layer is used. The only way to use the SSL client certificate as the identity is if it is the only information that is presented during the request. The client picks up the interoperable object reference (IOR) from the namespace and reads the values from the tagged component to determine what the server needs for security.
• CSIv2 transport layer. The transport layer, which is the lowest layer, might contain an SSL client certificate as the identity.

• (iSeries) (Dist) CSIv2 message layer. The message layer might contain a user ID and password or an authenticated token with an expiration.

CSIv2 outbound communications

Select to specify authentication settings for requests sent and transport settings for connections initiated by the server using the Object Management Group (OMG) Common Secure Interoperability (CSI) authentication protocol.

Authentication features include three layers of authentication we can use simultaneously:

• CSIv2 attribute layer. The attribute layer might contain an identity token, which is an identity from an upstream server that already is authenticated. The identity layer has the highest priority, followed by the message layer, and then the transport layer. If a client sends all three, only the identity layer is used. The only way to use the SSL client certificate as the identity is if it is the only information that is presented during the request. The client picks up the interoperable object reference (IOR) from the namespace and reads the values from the tagged component to determine what the server needs for security.
• CSIv2 transport layer. The transport layer, which is the lowest layer, might contain an SSL client certificate as the identity.

• (iSeries) (Dist) CSIv2 message layer. The message layer might contain a user ID and password or an authenticated token with an expiration.

Java authentication and authorization service

Under Authentication, expand Java authentication and authorization service to view links to:

• Application logins
• System logins
• J2C authentication data

Application logins

Select to define login configurations used by JAAS.

Do not remove the ClientContainer, DefaultPrincipalMapping, and WSLogin login configurations because other applications might use them. If these configurations are removed, other applications might fail.

System logins

Select to define the JAAS login configurations that are used by system resources, including the authentication mechanism, principal mapping, and credential mapping.

J2C authentication data

Select to specify the settings for the JAAS Java 2 Connector (J2C) authentication data.

Use the global security settings or customize the settings for a domain.

LTPA

Select LTPA to encrypt authentication information so that the application server can send the data from one server to another in a secure manner.

The encryption of authentication information that is exchanged between servers involves the Lightweight Third-Party Authentication (LTPA) mechanism.

Kerberos and LTPA

Encrypt authentication information so that the application server can send the data from one server to another in a secure manner.

The encryption of authentication information that is exchanged between servers involves the Kerberos mechanism.

Kerberos must be configured before this option can be selected.

Kerberos configuration

Encrypt authentication information so that the application server can send data from one server to anther in a secure manner.

The encryption of the authentication information that is exchanged between servers involves the KRB5 of LTPA mechanism.

Authentication cache settings

Select to set your authentication cache settings.

Enable Java Authentication SPI (JASPI)

Enable the use of Java Authentication SPI (JASPI) authentication.

We can then click Providers to create or edit a JASPI authentication provider and associated authentication modules in the global security configuration.

Use realm-qualified user names

That user names that are returned by methods, such as the getUserPrincipal() method, are qualified with the security realm in which they reside.

Security domains

Use the Security Domain link to configure additional security configurations for user applications.

For example, if we want use a different user registry for a set of user applications than the one used at the global level, we can create a security configuration with that user registry and associate it with that set of applications. These additional security configurations can be associated with various scopes (cell, clusters/servers, SIBuses). Once the security configurations have been associated with a scope all of the user applications in that scope use this security configuration.

For each security attribute, we can use the global security settings or customize settings for the domain.

External authorization providers

Select to specify whether to use the default authorization configuration or an external authorization provider.

The external providers must be based on the Java Authorization Contract for Containers (JACC) specification to handle the Java EE authorization. Do not modify any settings on the authorization provider pages unless we have configured an external security provider as a JACC authorization provider.

Custom properties

Select Custom properties to specify name-value pairs of data, where the name is a property key and the value is a string.

Related:

Java 2 security

Security configuration report

Multiple security domains

Configure multiple security domains

Configure security domains

Security domains collection

Secure specific application servers

Enable security

Configure FIPS JSSE files

RSA token authentication settings

LTPA

Local operating system settings

Standalone LDAP registry settings

Stand-alone custom registry settings

Administrative roles

Directory conventions

Java 2 security policy files

Security custom properties

Cryptographic Module Validation Program