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.

Security > Security domains > [domain | New ]

Name	Unique name for the domain. Cannot 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	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 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	Specify the global security settings that are being used.
Customize for this domain	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	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. 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	Consider enabling when both of the following conditions are true: Java 2 security is enforced. The application code is granted the following in was.policy. permission com.ibm.websphere.security.WebSphereRuntimePermission "accessRuntimeClasses"; Enabling adds fine-grained Java 2 security permission checking. Grant explicit permission to Java EE applications using the WSPrincipalMappingLoginModule implementation directly in the JAAS login when options "Use Java 2 security to restrict application access to local resources" and "Restrict access to resource authentication data" are enabled.
User Realm	Configure the user registry (LDAP) for the security domain. At the domain level we can choose to define our own realm name for the registry. 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. With multiple security domains we can configure multiple different registries in the system. For the realms to be unique in these domains, configure unique realm names. The system to can create a unique realm name for us based on the registry being used used.
Trust Association	Trust association is used to connect reverse proxy servers, such as ISAM WebSEAL, to the application servers. 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. IBM Security Verify'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 ISAM's trust association interceptors can exist in the system. The use of TAIs for SPNEGO authentication is deprecated.
Interceptors	Select to access or to specify the trust information for reverse proxy servers.
Enable trust association	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	Set SPNEGO web authentication as the authentication method. Can be configured at the domain level. SPNEGO provides dynamic reload of the SPNEGO filters and enables fallback to the application login method.
RMI/IIOP Security	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 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	Authentication settings for requests received and transport settings for connections accepted by this server using the OMG CSI authentication protocol. WAS enables us to specify 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	Specify authentication settings for requests sent and transport settings for connections initiated by the server using the OMG CSI authentication protocol. WAS enables us to specify 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	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	Set for the JAAS J2C authentication data. Use the global security settings or customize the settings for a domain. Java EE Connector authentication data entries are used by resource adapters and JDBC data sources.
Use global and domain-specific entries	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 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. Authentication cache settings Your authentication cache settings. The configuration specified on this panel is applied only to this domain. LTPA Timeout Specify a different LTPA timeout value at the domain level. The default is 120 minutes, set at global level. If the LTPA timeout is set at the domain level, any token created in the security domain when accessing user applications is created with this expiration time. Use realm-qualified user names When enabled, user names returned by methods such as getUserPrincipal( ) are qualified with the security realm (user registry) used by applications in the security domain.
Authorization Provider:	Set for the authorization provider. Use the global security settings or customize the settings for a domain. We can configure an external third party JACC provider at the domain level. ISAM'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.
Custom properties	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 to have properties different from those at the global level. Custom properties at the global level accessed by all of the applications in the system. The security runtime first checks for properties at domain level. If not found, 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