+

Search Tips   |   Advanced Search

Multiple security domains

WebSphere Security Domains (WSD) allow us to configure different security attributes, such as the UserRegistry, for different applications. WSDs are also referred to as multiple security domains. Create different security configurations and assign them to different applications in WAS processes. With multiple security domains, we can configure different security attributes for both administrative and user applications within a cell environment. We can configure different applications to use different security configurations by assigning the servers or clusters or service integration buses that host these applications to the security domains. Only users assigned to the administrator role can configure multiple security domains.

WebSphere Security Domains provide two major benefits:

For example, WAS administration can be configured to a user registry of federated repository while the applications can be configured to a user registry of LDAP. All of the user applications in the cell use this security domain if they do not have a domain previously associated with them. Global security attributes are still required for administrative applications such as the administrative console, naming resources and MBeans.

Server level security is deprecated in WAS v9.


Global security vs. security domains

Global Security applies to all administrative functions and the default security configuration for user applications. Security domains can be used to define a customized configuration for user applications.

We must have a global security configuration defined before creating security domains. The global security configuration is used by all of the administrative applications such as the administrative console, naming resources, and Mbeans. If no security domains are configured, all of the applications use information from the global security configuration. User applications such as EJBs, servlets and administrative applications use the same security configuration.

When we create a security domain and associate it with a scope, only the user applications in that scope use the security attributes defined in the security domain. The administrative applications as well as the naming operations in that scope use the global security configuration. Define the security attributes at the domain level to be different from those at the global level. If the information is common, the security domain does not need to have the information duplicated in it. Any attributes that are missing in the domain are obtained from the global configuration. The global security configuration data is stored in...


Scopes that can be associated to a security domain

High-level security attributes that can be defined at the global security configuration and those that can be overridden at the domain level.


Contents of a security domain

A security domain is represented by two configuration files. One configuration file contains the list of attributes configured in the security domain. The other configuration file contains the scopes that use the security domain. The security domain information is stored in the directory...

For every security domain configured, a securitydomain directory is created with two files in it:

Do not modify these files manually. Use administrative console tasks or scripting commands to modify the files instead.


Create security domains

In the administrative console, go to...

Set a unique name for the domain, any security attributes, and the scopes that need to use the security domain. Once configured, the servers that use the security domain must be restarted. The user applications in those scopes then use the attributes defined in the security domain. Any attributes that are not configured at the domain level are obtained from the global security configuration. Administrative applications and naming operations in the scopes always use the security attributes from the global security configuration. Any new security domain attributes must be compatible with those global security attributes that are inherited by the user applications assigned to the domain. Other than for JAAS and custom properties, once global attributes are customized for a domain they are no longer used by user applications.

The security domains panel in the administrative console enables us to assign resources and to select the appropriate security attributes for our domain. The panel displays the key security attributes at the global configuration; we can make the decision to override them at the domain level if necessary. Once we have configured and saved the attributes at the domain level, the summary value on the panel displays the customized value for the domain (tagged with the word "customized" in black text).

A scope (a server, cluster, service integration bus or a cell) can be associated with only one domain. For example, we cannot define two domains that both have the cell-wide scope. Multiple scopes, however, can be defined in the same security domain. For example, a domain can be scoped to Server1 and to Server2 only within the cell.

The assigned scopes section on the security domain panel displays two views: one view that enables us to select and assign scopes to the domain, and another view that enables us to see a list of the currently assigned scopes. For convenience, you also have the flexibility to copy all of the security attributes from an existing security domain or the global configuration into a new security domain, and then modify only those attributes that must be different. We must still associate the scopes to these copied domains.

Script commands also provide you with the ability to create, copy and modify security domains. Once we create a domain, run the appropriate commands to associate security attributes and scopes to it.


Configure attributes for security domains

Security attributes that can be configured at the domain level in WAS v9.0 are:

The security domains panels in the administrative console display all of these security attributes.


Attributes that we cannot override at the domain level

The Secure Socket Layer (SSL) attribute already supports different scopes, but it is not part of the domain configuration. For all of the attributes that are not supported at the domain level, user applications in a domain share their configuration from the global level.

Any new security domain attributes must be compatible with those global security attributes inherited by the user applications assigned to the domain. We must actively manage these attributes. For example, if we customize only a JAAS configuration at the domain level make sure that it works with the user registry configured at the global level (if the user registry is not customized at the domain level).

Other than for JAAS and custom properties, once global attributes are customized for a domain they are no longer used by user applications.

There is only one ISAM runtime shared by all servers in a cell. The ISAM client runtime is used to provide authentication (used by TrustAssociationInterceptor and PDLoginModule) and authorization (used for JACC) by contacting TAM servers.

We cannot have a different ISAM configuration at the security domain level to override the configuration at the cell level. However, we can to some degree specify Trust Association Interceptor (TAI) and JACC configuration at the security domain level. For example, we can use a different TAI or a different authorization provider. Since TAM server connectivity can only be defined at the global level, we can have a variety of TAIs defined and configured at the security domain level. Some of these TAIs might not use the TAM user repository, while others do. The TAIs that do need to connect to TAM will also connect to the globally-defined TAM server. Similarly, for authorization, we can have a variety of external authorization providers configured at the domain level. However, if any of these external authorization providers require connection to TAM they end up talking to the singular globally-configured TAM server.


Associating scopes to security domains

In WAS v9.0, we can associate a security domain at the cell level, the server level, the cluster level and the service integration bus level.

For more information about the service integration bus and bus security in multiple security domains for WAS v9.0, see Messaging security and multiple security domains.

When a security domain is associated with a server that is not part of a cluster, all user applications in that server use the attributes from the security domain. Any missing security attributes are obtained from the global security configuration. If the server is part of a cluster, we can associate the security domain with the cluster but not with the individual members in that cluster. The security behavior then remains consistent across all of the cluster members.

If a server is to be part of a cluster, create a cluster first and associate the security domain to it. We might have associated a domain to a server before it was a member of a cluster. If so, even though the domain is associated with the server directly, the security runtime code does not look at the domain. When a server is a cluster member, the security runtime disregards any security domains associated directly to the server. Remove the server scope from the security domain and associate the cluster scope to it instead.

A security domain can also be associated to the cell. This is usually done when we want to associate all user applications in WAS to a security domain. In this scenario, all of the administrative applications and the naming operations use the global security configuration while all of the user applications use the domain level configuration. To split the security configuration information for administrative and user applications, this is all needed.

If we are on a base profile server that has its own security domain defined, which is then federated to a deployment manager, associate the server scope to the security domain and not the cell scope. When we federate that node, the security domain information is propagated to the deployment manager. If the cell scope is associated to it, the network deployment configuration uses this security configuration, which might impact existing applications. During federation, the cell scope is changed to the server scope being federated. If the server scope is associated with the security domain, only that server uses the security domain after the federation. Other applications in other servers and clusters are not impacted. However, if this base profile server is registered to the Administrative Agent process we can associate the cell scope to the security domain if we want all of the servers from the base profile to use the same security domain for all of their user applications.

We can have a security domain associated at the cell level and also other security domains associated to various clusters or individual servers (those that are not part of any clusters). In this case, the security runtime first checks if any security domains are associated with the server or a cluster. If there is a security domain associated with the server or a cluster, the security attributes defined in it are used for all of the applications in that server or cluster. Any security attributes missing from this server or cluster domain are obtained from the global security configuration, and not from the domain configuration associated with the cell.

If the server or cluster does not have its own domain defined, the security runtime code uses the security attributes from the domain associated with the cell (if one is defined). Any security attributes missing from the cell domain are inherited from the global security configuration.


How domain level security attributes are used by security runtime and applications

  1. Application Security:

    Select "Enable application security" to enable or disable security 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).

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

  3. User Realm (User Registry):

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

    For LDAP registries, the host:port of the LDAP server is the system-generated realm name. For localOS, the name of the localOS machine is the realm name. For custom user registries, the realm is the one returned by the getRealm ( ) method of the custom registry implementation. If the system generated realm names are unique enough, we can choose the option for the system to generate the realm name. If not, choose a unique realm name for each security domain where we have the user registry configured. If the underlying user repository is the same, use the same realm name in different domains. From a security runtime perspective, same realm names have the same set of users and groups information. For example, when users and groups information is required from a realm, the first user repository that matches the realm is used.

    If a localOS registry that is not centralized is configured for any domain, and that domain is associated with servers or clusters in nodes not on the same system as the deployment manager, the realm name has to be provided. This realm name has to be the same as it would be if it were generated on the node. This realm name can be obtained by calling the getRealm() method on the SecurityAdmin MBean on that node. Typically, the realm name for localOS registries is the hostname of the machine. In this case, we should not let the system generate the realm name but rather get the realm name used by the processes in the node. If we select the system to generate the realm for the localOS registry at the time of the user registry configuration, it chooses the localOS registry used by the deployment manager. If the realm configured does not match the realm used by the servers then there are authorization issues. Also note that in this case, the domain using this local registry can only be associated with servers and clusters that belong to nodes on the same machine.

    We can configure a unique instance of a federated repository at the domain level in a multiple security domain environment. When a security domain is copied from the global level, the users and groups defined at the global level are also copied to the security domain. This is also true when copying from an existing domain. A newly-created security domain that uses the file-based VMM repository requires that the user populate the repository with users and groups.

    A checkbox on the Realm configurations settings administrative console page, "Use global schema for model", sets the global schema option for the data model in a multiple security domain environment. Global schema refers to the schema of the admin domain.

    When more than one user registry is in a process, the naming lookup that uses "UserRegistry" as the lookup name returns the user registry used by user applications. The user registry used by administrative applications is bound by the lookup name, "AdminUserRegistry".

    When an application in one realm communicates with an application in another realm using LTPA tokens, the realms have to be trusted. The trust relationship can be established using the Trusted authentication realms - inbound link in the user registry panel or using the addTrustedRealms command. We can establish trust between different realms. A user logged into one realm can access resources in another realm. If no trust is established between the two realms the LTPA token validation fails.

    The realm name used in the web.xml file is not related to the user registry realm.

  4. Trust Association:

    Trust association interceptors configured configured at the global level are copied to the domain level. 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. ISAM'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 cell.

  5. SPNEGO web authentication:

    SPNEGO web authentication for web resources can be configured at the domain level. SPNEGO web authentication provides dynamic reload of SPNEGO filters. SPNEGO web authentication replaces SPNEGO TAI, which was deprecated in WAS v7.

  6. RMI/IIOP Security (CSIv2):

    The RMI/IIOP security attribute refers to the CSIv2 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. When a process communicates with another process with a different realm, the LTPA authentication and the propagation tokens are not 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, or using the addTrustedRealms command task.

  7. Java Authentication and Authorization Service (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.

  8. Java Authentication SPI (JASPI)

    Configuration settings for a Java Authentication SPI (JASPI) authentication provider and associated authentication modules to be applied at the domain level. 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.

  9. Authentication Mechanism Attributes:

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

      Authentication cache settings Specify your authentication cache settings. The configuration specified on this panel is applied only to this domain.
      LTPA Timeout We can 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.
      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.

  10. External third party JACC:

    We can configure an external third party Java Authorization Contract for Containers (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. The JACC attributes, for example the Policy object, are based at the JVM level. This implies that there can be only be one JACC policy object in a JVM process. However, when we have multiple JACC providers configured, the dmgr process has to handle all these providers in the same JVMust because it has to propagate the authorization policy of applications to the respective provider based on the application name. If our JACC provider can handle propagating the authorization policy to multiple providers, we can configure it at the global level. In this case, when an application is installed, this JACC provider is called in the dmgr process and it is the responsibility of this JACC provider to propagate the information to the corresponding JACC provider based on the application name passed in the contextID. Another way to achieve this is to set the custom property...

      com.ibm.websphere.security.allowMultipleJaccProviders=true

    ...at the global security level. When this property is set, WAS propagates the authorization policy information to the JACC provider associated with the domain that corresponds to the target server where the application is installed. This property is only used at the dmgr process since the managed servers do not host multiple JACC providers.

  11. 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 not found, it then attempts to obtain the custom property from the global security configuration. For JAAS and custom properties only, once global attributes are customized for a domain they can still be used by user applications.


Client and application security programming model when using security domains

A Java client or an application acting as a client that accesses an EJB typically does a naming lookup first. The naming resource, which is used by both administrative and the user applications, is considered an administrative resource. It is protected by the global security configuration information. In a multiple domain setup where the global security is using one realm (the user registry) and a domain is using a different realm, the Java client must authenticate to two different realms. The first authentication is required for the realm in the global security configuration for the naming operation to succeed, and the second authentication is required to access the EJB, which uses a different realm.

The CosNamingRead role protects all naming read operations. This role is usually assigned the Everyone special subject. This implies any user, valid or not, can look up the name space. When a multiple domain is defined, if the CosNamingRead role has the Everyone special subject the security runtime code in the client side does not prompt you to log in. It uses the UNAUTHENTICATED subject to access the naming operation instead. Once the naming lookup operation is completed, when the client attempts to access the EJB it is prompted with a login panel that indicates the realm that is currently used by that EJB application (that is, the realm used in the domain). The client then presents the appropriate user credentials for that realm, which can then access the EJB. This logic applies to all variations of login source, including properties and stdin, not just when the login source is set to prompt.

If the Everyone special subject is removed from the CosNamingRead role, we are prompted twice. If the login source is properties, we can uncomment the property...

...in...

...and add the appropriate realms using "|" as the separator. We must also enter the corresponding users and passwords in the properties...

When using the programmatic logon in the Java client code we must authenticate twice with different user credentials; once prior to do a naming lookup for the EJB (the user should be in the global realm), and later prior to calling any method in the EJB (the user should be in the EJB domain's realm).

In general, when a Java client needs to authenticate to multiple and different realms it has to provide the credential information for all of those realms. If the login source is prompt or stdin it is prompted to login multiple times, once for each realm. If the login source is set to properties, the appropriate properties in the sas.client.props file (or any related file) are used for authenticating to different realms.

In certain scenarios, a client might make multiple calls to the same realm. For example, the Java client can access a resource using realm1 followed by access to a resource using realm2, and then come back to access a resource in realm1 again. In this case, the client is prompted three times; first for realm1, secondly for realm2 and finally for realm1 again.

By default, the subject used to login at a realm is not cached by the client side code. If we have this scenario, and we want the client to cache the subject based on the realm, set the property...

...in the sas.client.props file. If set, the client code caches the subject based on the realm name. The next time the Java client needs to authenticate to this realm, the cache is located to obtain the subject and the client is not prompted. Also, when set, the same subject that was logged in the first time is used for subsequent logins. If the subject information needs to change then this property should not be set.

If the client is doing a programmatic login it can pass the realm along with the user and password that it needs to authenticate. In this case, when...

...in the sas.client.props file, the registry that matches the realm name is used for login. That realm must be supported in the process where the authentication takes place.

When using the WSLogin JAAS configurations, you also must set the use_realm_callback option in...

...for the realm name to be passed to the call back handler. To specify a different provider URL for the name server, set the use_appcontext_callback option and pass in the provider URL properties in a hash map to WSLogin.

If we do not know the realm name, use <default> as the realm name. The authentication is performed against the application realm. If the naming read operation does not have the Everyone special subject assigned, provide the realm used by the administrative applications (the registry used in the global security configuration), as well as the appropriate user and password information in that registry for the lookup operation to succeed.

After the lookup operation succeeds, perform another programmatic login by providing the application realm (or <default>) and the user and password information for the appropriate user in the registry used by the application. This is similar to the case where the login source is prompt. We must authenticate twice, once for the registry used by the global security configuration (for the naming lookup operation) and again for the registry used by the application to access the EJB.

If com.ibm.CORBA.validateBasicAuth is set to false in the $WAS_HOME/profiles/profilename/properties/sas.client.props file then the programmatic login can use <default> as the realm name for both the lookup and the EJB operations. The actual authentication occurs only when the resource is accessed on the server side, in which case the realm is calculated based on the resource that is accessed.

The new security domain support starting in WebSphere Application v7.0 does not change the current application security programming model. However, it provides more flexibility and capabilities such as the following:


Application deployment in multiple domains configurations

When deploying an application in a multiple domain setup, all of the modules in the application should be installed in the servers or clusters that belong to the same security domain. If not, depending on the security attributes configured in these security domains, inconsistent behavior can result. For example, if the domains contain different user registries, the users and groups information can be different, which can cause inconsistent behavior when accessing the modules. Another example is when the JAAS data is different between the security domains. The JAAS configurations is not accessible from all of the modules in the application. The security runtime code and the command tasks rely on one domain being associated with an application when dealing with attributes such as user registry, JAAS login configurations, J2C authentication data, and authorization.

In most cases, application deployment fails when an application is deployed across different domains. However, since this was possible in earlier releases of WAS when only a few attributes were supported at the server level, the deployment tool first checks for attributes configured at the domains. If the attributes in the domain are the same as those supported in previous releases, the administrative console requests confirmation to ensure to deploy application modules across multiple security domains. Unless there is an absolute requirement to deploy the applications across different domains, stop the deployment and select the servers and clusters in the same security domain.


Cross realm communication

When applications communicate using the RMI/IIOP protocol and LTPA is the authentication mechanism, the LTPA token is passed between the servers involved. The LTPA token contains the realm-qualified uniqueId, (also called the accessId), of the user who is logging into the front-end application. When this token is received by the downstream server it attempts to decrypt the token. If the LTPA keys are shared between the two servers, decryption succeeds and the accessId of the user is obtained from the token. The realm in the accessId is checked with the current realm used by the application. If the realms match, the LTPA token validation succeeds and it proceeds with the authorization. If the realms do not match, the token validation fails since the user from the foreign realm cannot be validated in the current realm of the application. If applications are not supposed to communicate with each other when using RMI/IIOP and the LTPA authentication mechanism, we do not to have to do anything further.

To have cross realm communication when using RMI/IIOP and LTPA tokens, first establish trust between the realms involved, both for inbound and outbound communications. For the server originating the request, its realm must have the realms that it can trust to send the token to. This is referred to as outboundTrustedRealms. For the server receiving the request, its realm needs to trust the realms that it can receive LTPA tokens from. This is referred to as inboundTrustedRealms. Outbound trusted realms can be established using the addTrustedRealms command with the -communicationType option set to outbound. It can also be established in the administrative console by clicking Trusted authentication realms - outbound on the CSIv2 outbound communications panel. Inbound trusted realms can be established using the same addTrustedRealms command task with the -communicationType option set to inbound. It can also be established using the administrative console.

The figure later in this section shows the communication between applications that use different user realms (registries) using RMI/IIOP. In this example, application app1 (for example, a servlet) is configured to use the realm1 user registry. The app2 application (for example, an EJB) is configured to use the realm2 user registry. The user (user1) initially logs into the servlet in app1, which then attempts to access an EJB in app2. The following must be set:

When the LTPA token containing the accessId of user1 is received by app2, it decrypts the token. Both of the servers share the same LTPA keys. The LTPA token then ensures that the foreign realm is a trusted realm, and performs the authorization based on the accessId of user1. If security attribute propagation is not disabled, then the group information of user1 is also propagated to app2. The groups can be used for the authorization check, provided that the authorization table contains the group information. We can associate a special subject, AllAuthenticatedInTrustedRealms, to the roles instead of adding individual users and groups to the authorization table.

If the applications are deployed in different cells:

Cross realm communication in a multiple realm environment

Once trust has been established between the realms, when the server receives the LTPA token and the token is decrypted, it checks to see if the foreign realm is in its inbound trusted realms list. If it is trusted, the authentication succeeds. However, since it is a foreign realm, it does not go search the user registry to gather information about the user. Whatever information is in the LTPA token is used to authorize the user.

The only information in the LTPA token is the unique id of the user. This unique id of the user should exist in the authorization table for this application. If it does, authorization succeeds. However, if attribute propagation is enabled, additional authorization attributes (groups that this user belongs to) for the user are sent from the originating server to the receiving server. These additional attributes are used to make the access decisions. If the groups information exists in the propagation tokens it is used when making the authorization decision.

As previously mentioned, the information about the users and or the groups from the trusted realms should exist in the authorization table of the receiving application. Specifically, the accessId of the users and or groups should exist in the binding file of the application. This must be the case when the application is deployed. In the administrative console, when an application is deployed in a domain we can add the accessIds of the users and groups from any of its trusted realms to the authorization table.

We also have an option to associate a special subject, AllAuthenticatedInTrustedRealms, to the roles instead of adding individual users and groups. This is similar to the AllAuthenticated special subject that is currently supported. The difference is that the AllAuthenticated special subject refers to users in the same realm as the application while the AllAuthenticatedInTrustedRealms special subject applies to all of the users in the trusted realms and in the realm of the application.

We can associate the accessId using the $AdminApp install script. Because the accessId takes a unique format, use the command task listRegistryUsers with displayAccessIds set to true. If an invalid name or format is entered in this field, the authorization fails.

User and group information from the trusted realms is obtained by the deployment manager since it has access to all of the user registry configurations in all domains. However, in certain situations it is not possible to obtain the users and group information.

For example, if a server hosted on an external node is using localOS as the registry for its domain, the deployment manager cannot obtain the users and groups information unless it is running in the same operating system setup. The external operating system should be contacted to obtain this information. This can be done by directly invoking the registry in the server associated with that domain. The servers associated with the domain have to be started for this to work. We also must set...

...in the top-level security custom properties. When this property is set, the deployment manager code searches one of the servers associated with the security domain and obtains the users and groups information directly from it. This is possible by calling an MBean in one of the servers.

If the MBean in any of the servers that are using that domain cannot be accessed, the administrative console displays a panel where we can enter the user and accessId information manually for each user and group. It is important that the correct accessId format be entered in this field. The accessId format for the user is user:realmName/userUniqueId. The realmName is the name of the realm where the user resides, and the userUniqueId is the uniqueId that represents the user, depending on the registry used.

For example, for LDAP, the uniqueUserId is the Distinguished Name (DN), for the Windows localOS registry and is the SID of the user. For Unix platforms, it is the UID. For custom registries, it depends on the implementation. Similarly, for groups, the accessId format is group:realmName/groupUniqueId. As previously mentioned, use the listRegistryUsers and listRegistryGroups command with the -displayAccessIds option set to true so that we can obtain the correct format for the domain or realm that we are interested in.

Once users and groups from the trusted realms or the AllAuthenticatedInTrustedRealms special subject is added to the authorization table of the application, it is ready to accept requests from other applications that are using any of its trusted realms. The LTPA token validation on the receiving server first checks to make sure that the realm is trusted. The authorization engine then checks to see if the external user and/or the groups or the AllAuthenticatedInTrustedRealms special subject are given access to the roles needed to access the resource. If true, access is granted.

Cross realm communication is only applicable when using the WebSphere built-in authorization. If we are using other authorization engines including SAF for z/OS, any cross realm authorization can be achieved by implementing custom login modules that map external users to users in its own repository.


Federating a node with security domains

When a security domain is configured in the base version and is federated to a cell, the security domain configured at the base version is also configured for that server in the cell. The same domain security configuration can be used by the server before and after the federation. If a base server is to be federated to a cell, the resource assigned to the security domain should be the server scope instead of the cell scope. If the base server is expected to be registered with an Administrative Agent process, use the cell scope as the resource if the intention is to have all of the servers in the base profile use this security domain.

If during federation the security domain at the base already exists at the cell level, the addNode command fails. Use the -excludesecuritydomains option not to include the security domain during federation. When the federated node is removed from a cell, the resources in that node should be removed from the security domains. If security domains have clusters associated with them that span nodes, the nodes are not removed. We can always remove resources from the security domains or any domains that are not used using scripting commands or the administrative console.


Security domains in a mixed-version environment

We should create security domains once all of the nodes have been migrated to the latest version. This is especially true if there is a need to associate the cell with a domain. However, to create security domains in a mixed- version environment, be aware of the following:


Modifying security domains

Use the administrative console tasks or scripting commands to modify security domains. Once a security domain is created and associated to a set of scopes, the servers associated with this new domain must be restarted. After the restart, the applications in the scopes associated with the new domain use the security attributes defined in the domain. Changes to any of the domain attributes requires the restart of all of the scopes assigned to it. If new scopes are added they also need to be restarted. Any modifications to the domain configuration, either to the security attributes or to the scopes, has impacts on those applications that are using the domain configuration.

Before we make modifications to an existing domain, consider the following potential impacts. For example, if a user registry configured at a domain is removed, and the servers restarted, the user registry from the cell-wide domain (if one is defined), or the global security configuration is then used. This can impact application authentication and authorization. Users and groups associated with an application might no longer be valid in the new registry. Another example to consider is when JAAS configurations are removed from a domain. Applications that rely on this are no longer be able to use the JAAS configurations. Whenever a security configuration is changed it might impact the applications, so all security configuration changes should be made with the utmost care.


Related:

  • Single sign-on for HTTP requests using SPNEGO web authentication
  • Configure multiple security domains
  • Create new multiple security domains
  • Delete 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
  • Configure multiple security domains using scripting
  • Map resources to security domains using scripting
  • Configure CSIv2 inbound and outbound communication settings
  • Authenticate users
  • Authorize access to resources
  • Configure programmatic logins for JAAS
  • Programmatic login for JAAS
  • Administrative roles
  • ISAM JACC provider configuration