Configure multiple security domains

By default, all administrative and user applications in WebSphere Application Server use the global security configuration. For example, a user registry defined in global security is used to authenticate users for every application in the cell. Out-of-the-box, this behavior is the same as it was in previous releases of WAS. We can create additional WebSphere security domains to specify different security attributes for some or all of your user applications.

Only users assigned to the administrator role can configure or create new multiple security domains. Enable global security in our environment before configuring multiple security domains.

Read about Multiple security domains for a better understanding of what multiple security domains are and how they are supported in this version of WAS.

Security domains enable you to define multiple security configurations for use in the environment. For example, we can define different security (such as a different user registry) for user applications than for administrative applications. We can also define separate security configurations for user applications deployed to different servers and clusters.

Best practice: When configuring an application domain with a realm name that is identical to the realm name at the global domain, a lookup of users, groups or other registry attributes returns that of the application domain. You should configure unique realm names for each domain.bprac

Perform the following steps to configure a new security domain using the console:

1. Click Security > Security domains.

2. For a new multiple security domain, click New. Supply a unique name and description for the domain and click Apply. To configure an existing multiple security domain, select one to edit. Once you click Apply the domain name and additional sections are displayed. One section enables you to define the security attributes for the domain, and another section enables you to select the scopes to which the domain applies.

3. Under Assigned Scopes, select whether to assign the security domain to the entire cell or to select the specific servers, clusters, and service integration buses to be included in the security domain. The Assigned Scopes section has two views. The default view is a cell topology. To assign the security domain to the entire cell, click the check box for the cell and then click Apply or OK.

   The name of the security domain appears next to the cell name, which indicates that the domain is now assigned to the cell. We can expand the topology and assign the domain to one or more servers and clusters. When an item in the topology is already assigned to another security domain, the check box is disabled and the name of the assigned domain is displayed next to the scope name. To assign one of these scopes to the domain, first disassociate it with its current domain.

   Select All assigned scopes to view a list of only those resources that are currently assigned to the security domain.

4. Customize the security configuration by specifying security attributes for the new domain. Attributes that are not listed can not be customized at the domain level. Domains inherit attributes from the global security configuration.

   There are twelve individually configurable security attribute sections. We can expand and collapse each section. In the collapsed state, the name and a summary value for the section are displayed. Additionally, the summary value text indicates whether the attribute is defined in global security and is reused by the domain (as indicated by gray text) or if it is customized for the domain (as indicated by black text prefixed by the word "Customized").

   Initially, each security attribute is set to use the global security settings. When an attribute is set to use global security, there is no domain-specific configuration for that attribute. Applications that use the domain use the global configuration for these security attributes.

   Only configure the security attributes to change. To configure a security attribute for a domain, expand the security attribute section. The key properties of the global configuration display beneath the Use global security option. These properties are provided for convenience.

   To customize the configuration for the domain, select Customize for this domain. Configure the property and then click OK or Apply.

   In general, when you select Customize for this domain, you override all of the security configurations defined for that section in global security. Application logins, system logins, and J2C authentication data entries are some exceptions. When you define entries for a domain, applications in the domain are able to access the global entries in addition to the domain-specific entries.

   For example, you might want to use a different user registry for applications that use the security domain but also want to use the global security configuration for all of the other security properties. In this case, expand the User Realm section and select Customize for this domain. Select a user registry type, click Configure, and provide the appropriate configuration details on the subsequent panel.

   We can change security attributes such as the following:

   Application Security

   Settings for application security and Java 2 security. We can use the global security settings or customize the settings for a domain.

   Select Enable application security to enable or disable security this choice for user applications. 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 you enable this selection, the J2EE security is enforced for all of the EJBs and web applications in the security domain. The J2EE 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 Java 2 security to enable or disable Java 2 security at the domain level. 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.

   User realm

   This section enables you to configure the user registry for the security domain. We can separately configure any registry used at the domain level. Read about Multiple security domains for more information.

   Trust association

   When you configure the trust association interceptor (TAI) at a domain level, the interceptors configured at the global level are copied to the domain level for convenience. We can modify the interceptor list at the domain level to fit the needs. Only configure those interceptors that are to be used at the domain level.

   SPNEGO Web Authentication

   The SPNEGO web authentication, which enables you 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. This function was deprecated in WebSphere Application Server 7.0. 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

   The RMI/IIOP security attribute refers to the CSIv2 (Common Secure Interoperability version 2) protocol properties. When you 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 application in the process.

   JAAS application logins

   Configuration settings for the JAAS application logins. We can use the global security settings or customize the settings for a domain.

   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 specify a login used exclusively by the applications in the security domain.

   JAAS system logins

   Configuration settings for the JAAS system logins. We can use the global security settings or customize the configuration settings for a domain.

   JAAS J2C authentication

   Configuration settings for the JAAS J2C authentication data. We can use the global security settings or customize the settings for a domain.

   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 enable JASPI. Select Providers to define providers for the domain.

   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 need to applied at the domain level.

   Select Authentication cache settings to specify the authentication cache settings. The configuration specified on this panel is applied only to this domain.

   Select LTPA Timeout to configure a different LTPA timeout value at the domain level. The default timeout value is 120 minutes, which is set at the 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.

   When Use realm-qualified user names is 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

   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.

   (zos) We can additionally configure the SAF authorization options at the security domain level, which are the following:

   • The unauthenticated user id

   • The SAF profile mapper

   • Whether to enable SAF delegation

   • Whether to use the APPL profile to restrict access to WebSphere Application Server

   • Whether to suppress authorization failed messages

   • The SMF audit record strategy

   • The SAF profile prefix

   (zos) For more information on the SAF authorization options, read about z/OS System Authorization Facility authorization.

   
   (zos)

   z/OS security options

   We can set z/OS specific security options at the process (JVM) level so that all applications (both administrative and user) can enable or disable these options. These properties are:

   • Enable application server and z/OS thread identity synchronization

   • Enable the connection manager RunAs thread identity.

   For more information on the z/OS security options, read about z/OS security options

   Custom properties

   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 cell. 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.

5. Once we have configured the security attributes and assigned the domain to one or more scopes, click Apply or OK.

6. Restart all servers and clusters for the changes to take effect.

Subtopics

• Multiple security domains
  The WebSphere Security Domains (WSD) provide the flexibility to use different security configurations in WebSphere Application Server. The WSD is also referred to as multiple security domains, or simply, security domains. We can configure different security attributes, such as the UserRegistry, for different applications.

• Create new multiple security domains
  We can create multiple security domains in the configuration. By creating multiple security domains, we can configure different security attributes for administrative and user applications within a cell environment.

• Delete multiple security domains
  We can delete multiple security domains from the configuration. We must remove the resources assigned to the security domains before deleting them. Only remove those security domains that are not needed in the security configuration.

• Copy multiple security domains
  We can copy selected multiple security domains from the domain collection to create a new domain. This is useful to create a domain that is similar to a previous domain. However, you might want to make a few slight adjustments. When copying an existing domain, supply a unique domain name for the new one.

• Configure inbound trusted realms for multiple security domains
  We can configure which realms to grant inbound trust to for multiple security domains. The trust relationship between realms is used when communicating with LTPA tokens. Once a LTPA token is decrypted by the receiving server, the realm in the token is checked to see if it is trusted. If it is not, the validation of the token fails. A realm represents a user registry in WebSphere Application Server.

• Configure security domains
  Use this page to 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.

• External realm name
  Use this page to add a WAS realm that is external to this cell. The realm is initially not trusted. Use the Trusted authentication realms - inbound page to establish trust.

• Trust all realms
  Use this page to configure which realms to grant inbound or outbound trust to.

• Security domains collection
  Security domains provide a mechanism to use different security settings for administrative applications and user applications. They also provide the ability to support multiple security settings so different application servers can use different security attributes like user registry or login configurations.

• Authentication cache settings
  Use this page to specify the authentication cache settings.

Related tasks

Task overview: Securing resources

Configure security domains

Configure multiple security domains

Remove security domains

Mapping resources to security domains

Administrative roles