+

Search Tips   |   Advanced Search

Configure security domains

Configure the security attributes of a domain and to assign the domain to cell resources. For each security attribute, we can use the global security settings or customize settings for the domain.

From the admin console, click...


Name

Unique name for the domain. This name can not be edited after the initial submission.

A domain name must be unique within a cell and cannot contain an invalid character.


Description

Description for the domain.


Assigned Scopes

Select to display the cell topology. We can assign the security domain to the entire cell or select the specific clusters, nodes and service integration buses to include in the security domain.

If we select All scopes, the entire cell topology is displayed.

If we select Assigned scopes, the cell topology is displayed with those servers and clusters assigned to the current domain.

The name of an explicitly assigned domain appears next to any resource. Checked boxes indicate resources that are currently assigned to the domain. We also can select other resources and click Apply or OK to assign them to the current domain.

A resource that is not checked (disabled) indicates that it is not assigned to the current domain and must be removed from another domain before it can be enabled for the current domain.

If a resource does not have an explicitly-assigned domain, it uses the domain assigned to the cell. If no domain is assigned to the cell, then the resource uses global settings.

Cluster members cannot be individually assigned to domains; the enter cluster uses the same domain.


Application Security:

Select Enable application security to enable or disable security for user applications. Use the global security settings or customize the settings for a domain.

When this selection is disabled, all of the EJBs and web applications in the security domain are no longer protected. Access is granted to these resources without user authentication. When we enable this selection, the Java EE security is enforced for all of the EJBs and web applications in the security domain. The Java EE security is only enforced when Global Security is enabled in the global security configuration, (that is, we cannot enable application security without first enabling Global Security at the global level).


Enable application security

Enables security for the applications in the environment. This type of security provides application isolation and requirements for authenticating application users

In previous releases of WAS, when a user enabled global security, both administrative and application security were enabled. In WAS v6.1, the previous notion of global security were split into administrative security and application security, each of which we can enable separately.

As a result of this split, 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.

When this selection is disabled, all of the EJBs and web applications in the security domain are no longer protected. Access is granted to these resources without user authentication. When we enable this selection, the Java EE security is enforced for all of the EJBs and web applications in the security domain. The Java EE security is only enforced when Global Security is enabled in the global security configuration, (that is, we cannot enable application security without first enabling Global Security at the global level).


Java 2 security:

Select Use Java 2 security to enable or disable Java 2 security at the domain level or to assign or add properties related to Java 2 security. Use the global security settings or customize the settings for a domain.

This choice enables or disables Java 2 security at the process (JVM) level so that all applications (both administrative and user) can enable or disable Java 2 security.


Use global security settings

Select to specify the global security settings that are being used.


Customize for this domain

Select to specify the settings defined in the domain, such as options to enable application and Java 2 security and to use realm-qualified authentication data.


Use Java 2 security to restrict application access to local resources

Select to specify whether to 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.


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 Java EE 1.4 specification.

Important: We cannot enable this option without enabling the Use Java 2 security to restrict application access to local resources option.


Restrict access to resource authentication data

This option is disabled if Java 2 security has not been enabled.

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

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 Java 2 Platform, Enterprise Edition (Java EE) 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.

Information Value
Default: Disabled


User Realm:

This section enables us to configure the user registry for the security domain. We can separately configure any registry used at the domain level.

When configuring a registry at the domain level we can choose to define our own realm name for the registry. The realm name distinguishes one user registry from another. The realm name is used in multiple places - in the Java client login panel to prompt the user, in the authentication cache, and when using native authorization.

At the global configuration level, the system creates the realm for the user registry. In previous releases of WAS, only one user registry is configured in the system. When we have multiple security domains we can configure multiple registries in the system. For the realms to be unique in these domains, configure our own realm name for a security domain. We also can choose the system to create a unique realm name if it is certain to be unique. In the latter case, the realm name is based on the registry being used used.


Trust Association:

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

Trust association enables the integration of IBM WAS security and third-party security servers. More specifically, a reverse proxy server can act as a front-end authentication server while the product applies its own authorization policy onto the resulting credentials passed by the proxy server.

Tivoli Access Manager's trust association interceptors can only be configured at the global level. The domain configuration can also use them, but cannot have a different version of the trust association interceptor. Only one instance of Tivoli Access Manager's trust association interceptors can exist in the system.

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


Interceptors

Select to access or to specify the trust information for reverse proxy servers.


Enable trust association

Select to enable the integration of IBM WAS security and third-party security servers. More specifically, a reverse proxy server can act as a front-end authentication server while the product applies its own authorization policy onto the resulting credentials passed by the proxy server.


SPNEGO Web Authentication:

Sets for Simple and Protected GSS-API Negotiation (SPNEGO) as the web authentication mechanism.

The SPNEGO web authentication, which enables us to configure SPNEGO for web resource authentication, can be configured at the domain level.

In WAS v6.1, a TAI that uses the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) to securely negotiate and authenticate HTTP requests for secured resources was introduced. In WAS 7.0, this function is deprecated. SPNEGO web authentication has taken its place to provide dynamic reload of the SPNEGO filters and to enable fallback to the application login method.


RMI/IIOP Security:

Sets for Remote Method Invocation over the Internet Inter-ORB Protocol (RMI/IIOP).

An Object Request Broker (ORB) manages the interaction between clients and servers, using the Internet InterORB Protocol (IIOP). It enables clients to make requests and receive responses from servers in a network-distributed environment.

When we configure these attributes at the domain level, the RMI/IIOP security configuration at the global level is copied for convenience. We can change the attributes that need to be different at the domain level. The Transport layer settings for CSIv2 inbound communications should be the same for both the global and the domain levels. If they are different, the domain level attributes are applied to all of the applications in the process.

When a process communicates with another process with a different realm, the LTPA authentication and the propagation tokens are propagated to the downstream server unless that server is listed in the outbound trusted realms list. This can be done using the Trusted authentication realms - outbound link on the CSIv2 outbound communication panel.


CSIv2 inbound communications

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

WAS enables us to specify Internet Inter-ORB Protocol (IIOP) authentication for both inbound and outbound authentication requests. For inbound requests, we can specify the type of accepted authentication, such as basic authentication.


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.

WAS enables us to specify Internet Inter-ORB Protocol (IIOP) authentication for both inbound and outbound authentication requests. For outbound requests, we can specify properties such as type of authentication, identity assertion or login configurations used for requests to downstream servers.


JAAS Application logins

Select to define login configurations used by JAAS.

The JAAS application logins, the JAAS system logins, and the JAAS J2C authentication data aliases can all be configured at the domain level. By default, all of the applications in the system have access to the JAAS logins configured at the global level. The security runtime first checks for the JAAS logins at the domain level. If it does not find them, it then checks for them in the global security configuration. Configure any of these JAAS logins at a domain only when we need to specify a login used exclusively by the applications in the security domain.

For JAAS and custom properties only, once global attributes are customized for a domain they can still be used by user applications.

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.


Use global and domain-specific logins

Select to specify the settings defined in the domain, such as options to enable application and Java 2 security and to use realm-qualified authentication data.


JAAS System Logins:

Configuration settings for the JAAS system logins. Use the global security settings or customize the configuration settings for a domain.


System Logins

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


JAAS J2C Authentication Data:

Sets for the JAAS J2C authentication data. Use the global security settings or customize the settings for a domain.

Java 2 Platform, Enterprise Edition (Java EE) Connector authentication data entries are used by resource adapters and Java DataBase Connectivity (JDBC) data sources.


Use global and domain-specific entries

Select to specify the settings defined in the domain, such as options to enable application and Java 2 security and to use realm-qualified authentication data.


Java Authentication SPI (JASPI)

Configuration settings for a Java Authentication SPI (JASPI) authentication provider and associated authentication modules. We can use the global security settings or customize the settings for a domain. To configure JASPI authentication providers for a domain, select Customize for this domain and then we can enable JASPI. Select Providers to create or to edit a JASPI authentication provider.

The JASPI authentication provider can be enabled with providers configured at the domain level. By default, all of the applications in the system have access to the JASPI authentication providers configured at the global level. The security runtime first checks for the JASPI authentication providers at the domain level. If it does not find them, it then checks for them in the global security configuration. Configure JASPI authentication providers at a domain only when the provider is to be used exclusively by the applications in that security domain.


Authentication Mechanism Attributes:

Various cache settings that must be applied at the domain level.


Authorization Provider:

Sets for the authorization provider. Use the global security settings or customize the settings for a domain.

We can configure an external third party JACC (Java Authorization Contract for Containers) provider at the domain level. Tivoli Access Manager's JACC provider can only be configured at the global level. Security domains can still use it if they do not override the authorization provider with another JACC provider or with the built-in native authorization.

Select either the Default authorization or External authorization using a JAAC provider. The Configure button is only enabled when External authorization using a JAAC provider is selected.

(ZOS) For System Authorization Facility (SAF) authorization, if we set the SAF profile prefix at the domain level, it is applied at the server level so that all applications (both administrative and user) will enable or disable it in that server


(ZOS) Enable application server and z/OS thread identity synchronization

Select to indicate if an operating system thread identity should be enabled for synchronization with the Java 2 Platform, Enterprise Edition (Java EE) identity used in the application server runtime if an application is coded to request this function.

Synchronizing the operating system identity to the Java EE identity causes the operating system identity to synchronize with the authenticated caller, or delegated RunAs identity in a servlet or EJB file. This synchronization or association means that the caller or security role identity, rather than the server region identity, is used for z/OS system service requests such as access to files.

If this value is set at the domain level, it is applied at the server level so that all applications (both administrative and user) will enable or disable it in that server.


Custom properties

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

Set custom properties at the domain level that are either new or different from those at the global level. By default, all of the custom properties at the global security configuration can be accessed by all of the applications in the system. The security runtime code first checks for the custom property at the domain level. If it does not find it, it then attempts to obtain the custom property from the global security configuration.


Web Services Bindings

Click Default policy set bindings to set the domain default provider and client bindings.


Related:

  • Multiple security domains
  • Standalone LDAP registry settings
  • Configuration entry settings for JAAS
  • Java 2 Connector authentication data entry settings
  • External Java Authorization Contract for Containers provider settings
  • Security domains collection
  • Security custom properties