+

Search Tips   |   Advanced Search

Set security domains



Overview

To configure the security attributes of a domain and to assign the domain to cell resources, from the admin console...

Security | Security domains

On the Security domains collection page, select an existing domain to configure, create a new one, or copy an existing domain.

For each security attribute, we can....

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.


Settings

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

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 that are 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 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:

To enable or disable security for user applications, select...

Enable application security

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

When this selection is disabled, all of the EJBs and Web apps 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 apps 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).

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 admin 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 apps 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 apps 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

Enable or disable Java 2 security at the domain level or 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 admin 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 app.policy or was.policy of the application. AccessControl exceptions are generated by applications that do not have all the required permissions.

Warn if applications are granted custom permissions

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

The appserver 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 you do not want an application to have according to the J2EE 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

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

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

  • Java 2 security is enforced.

  • The application code is granted the permission...

    WebSphereRuntimePermission accessRuntimeClasses

    ...in was.policy found within the application EAR file. For example...

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

User Realm

Configure the user registry for the security domain.

We can configure any registry except the federated registry, which can only be configured at the global level but can be 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
  • 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 that is being used.

Trust Association

Specify settings for trust association, which is used to connect reverse proxy servers to appservers.

Reverse proxy servers authenticate users, and send the credentials to WAS, which applies its own authorization policy.

Trust association enables the integration of WAS security with third-party security servers.

TAM’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 TAI. Only one instance of TAM’s TAI can exist in the system.

The use of TAIs for SPNEGO authentication is deprecated. Instead, use the SPNEGO web authentication panels provide a much easier way to configure SPNEGO.

Interceptors

Access or to specify the trust information for reverse proxy servers.

Enable trust association

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

Simple and Protected GSS-API Negotiation (SPNEGO)

SPNEGO Web resource authentication settings at the domain level.

In WAS V6.1, a TAI that uses SPNEGO to authenticate HTTP requests for secured resources was introduced. In WAS 7.0, this function is now deprecated with SPNEGO Web authentication taking its place.

SPNEGO Web authentication provides...

RMI/IIOP

An ORB manages interactions between clients and servers, using IIOP. This enables clients to requests and receive responses from servers in a network-distributed environment.

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

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 you 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 that are sent and transport settings for connections that are initiated by the server using the Object Management Group (OMG) Common Secure Interoperability (CSI) authentication protocol.

WAS enables you 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 that are used for requests to downstream servers.

JAAS Application logins

Select to define login configurations that are 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. Set any of these JAAS logins at a domain only when 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 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

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

J2EE Connector authentication data entries are used by resource adapters and Java DataBase Connectivity (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.

Authentication Mechanism Attributes

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

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

  • LTPA Timeout - 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 that is created in the security domain when accessing user applications is created with this expiration time.

  • Use realm-qualified user names - When this selection 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

Settings for the authorization provider. We can use the global security settings or customize the settings for a domain.

Configure an external third party JACC (Java Authorization Contract for Containers) provider at the domain level. TAM’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

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 concepts


Multiple security domains

 

Related


Standalone LDAP registry settings
Configuration entry settings for Java Authentication and Authorization Service
Java 2 Connector authentication data entry settings
External Java Authorization Contract for Containers provider settings
Security domains collection

 

Related information


Security custom properties