Create new multiple security domains

By creating multiple security domains, we can configure different security attributes for administrative and user applications within a cell environment. 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 applications can use different security attributes like user registry or login configurations.

Use multiple security domains to achieve the following goals:

• Configure different security attributes for administrative and user applications within a cell
• Consolidate server configurations by managing different security configurations within a cell
• Restrict access between applications with different user registries, or configure trust relationships between applications to support communication across registries

Only users assigned to the administrator role can create new multiple security domains. Enable global security in the environment before creating new multiple security domains.

Create a new security domain

1. Click...
   Security > Security domains > New

2. Specify a unique name for the domain. A domain name must be unique within a cell and cannot contain an invalid character. This field is required.

3. Specify a unique description for the domain. After clicking Apply we are returned to the Security domains detail page

4. Under Assigned Scopes, assign the security domain to the entire cell or select the specific servers, clusters, and service integration buses to include in the security domain.

5. Customize the security configuration by specifying security attributes for our new domain and by assigning it to cell resources.

   We can change security attributes such as the following:

   Application Security

   Settings for application security and Java 2 security. 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 we 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 us 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 we 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 our needs. Only configure those interceptors that are to be used at the domain level.

   SPNEGO Web Authentication

   The SPNEGO web authentication, which enables us to configure SPNEGO for web resource authentication, can be configured at the domain level. EGO web authentication provides 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 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 application in the process.

   JAAS application logins

   Configuration settings for the Java Authentication and Authorization Service (JAAS) application logins. 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. Be 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.

   JAAS system logins

   Specifies the configuration settings for the JAAS system logins. Use the global security settings or customize the configuration 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. Be 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 both JAAS application logins and JAAS system logins, the collections are not populated until one is created first. We can do this by selecting customize for this domain under JAAS application logins or JAAS system logins and then by selecting Apply or OK.

   JAAS J2C authentication

   Configuration settings for the JAAS J2C authentication data. 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. Be 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.

   Java Authentication SPI (JASPI)

   Configuration settings for a Java Authentication SPI (JASPI) authentication provider. 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 echanism Attributes

   Various cache settings that need to applied at the domain level.

   Select Authentication cache settings to specify your 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. Security 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 WAS
   • 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.

6. Click Apply.

7. After we have saved the configuration changes, restart the server for our changes to take effect.

Related:

Multiple security domains

Configure multiple security domains

Deleting multiple security domains

Copy multiple security domains

Configure inbound trusted realms for multiple security domains

Configure security domains using scripting

Configure multiple security domains using scripting

Remove security domains using scripting

Mapping resources to security domains using scripting

Administrative roles