Multiple security domains
- Why security domains are useful
- Relationship between global security and security domains
- Contents of a security domain
- Create security domains
- Set attributes for security domains
- Associating scopes to security domains
- Relationship between old server level security and the new security domains
- How domain level security attributes are used by security runtime and applications
- Client and application security model when using security domains
- Application deployment in multiple domains configurations
- Cross realm communication
- Federating a node with security domains
- Security domains in a mixed-version environment
- Modify security domains
WebSphere Security Domains (WSD), also referred to as multiple security domains, or simply, security domains, can be used to assign different security configurations, such as the UserRegistry, to servers, clusters and SIBs hosting admin and user applications.
New feature: Multiple security domain support is new in this release of WAS.
Only users assigned to the administrator role can configure multiple security domains
Why security domains are useful
- WAS admin apps can be configured with a different set of security configurations from those for user applications.
- WSDs enable one set of applications to have a different set of security configurations from another set of applications.
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.
In previous versions of WAS, all admin and user applications use security attributes different from those attributes defined in global security.
All admin and user applications in WAS use global security attributes by default. For example, a user registry defined in global security is used to authenticate a user for every application in the cell.
In this release of WAS, however, we can use multiple security attributes for user applications other than the global security attributes, create a security domain for those security attributes that must differ, and associate them with the servers and clusters that host those user applications. We also can associate a security domain with the cell. 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 admin applications such as the admin console, naming resources and MBeans.
Server level security is deprecated in this release.
Relationship between global security and security domains
Global Security defines the default security configuration for user applications and admin applications, such as the console, naming resources, and Mbeans.
Security domains define a customized security configuration for user applications.
If no security domains are configured, all applications use information from the global security configuration, with user applications such as EJBs and servlets, using the same security configuratin and admin applications.
By creating a security domain, and associating it with a scope, only the user applications in that scope use the security attributes defined in the security domain. The admin applications as well as the naming operations in that scope use the global security configuration.
Define attributes at the security domain level that need to be different from those at the global security level. If the information is common, the security domain does not need to have the information duplicated in it. Any attributes missing in the domain are obtained from the global configuration.
The global security configuration data is stored in...
The figure below shows a cell, a server and a cluster associated with different security domains.
- User applications in server S1.1 use security attributes defined in Domain3
- User applications in the cluster use security attributes defined in Domain3
- User applications in server S2.2, which is not associated with a domain, use security attributes associated with the cell, Domain1, by default.
The following figure shows the various 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
Security domain information is stored under...PROFILE_HOME/config/waspolicies/default/securitydomains/domain
...and contains the files...
Security attributes configured for the security domain, such as...
- User Registry
- Login Configurations
List of WebSphere resources that use the security attributes in security-domain.xml. For example, a cluster name here indicates that all the user applications in that cluster will use these security attributes.
Do not modify these files manually. Use admin console tasks or scripting commands instead.
Create security domains
From the admin console, access security domains by clicking...Security | Security domains
By creating a security domain, supply...
- A unique name for the domain
- Security attributes to configure for the security domain
- 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 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. You must actively manage these attributes.
Any new security domain attributes must be compatible with those global security attributes 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 admin console enables you to assign resources and to select the appropriate security attributes for the 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 (server, cluster, SIB, 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 you to select and assign scopes to the domain, and another view that enables you 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. Still associate the scopes to these copied domains.
Scripting commands also provide you with the ability to create, copy and modify security domains. Once you create a domain, run the appropriate commands to associate security attributes and scopes to it.
Set attributes for security domains
Security attributes that can be configured at the domain level in WAS V7.0 are:
- Application security
- Java 2 security
- User realm (registry)
- Trust association
- SPNEGO Web authentication
- RMI/IIOP security (CSIv2)
- JAAS logins
- Authentication mechanism attributes
- Authorization provider
- Custom properties
The security domains panels in the admin console display all of these security attributes.
Some attributes we cannot override at the domain level are...
- Web Single Sign-on (SSO)
- Tivoli Access Manager (TAM)
- federated repositories
The SSL attribute already supports different scopes, but it is not part of the domain configuration. For all of the attributes 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. You 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.
TAM is used to provide authentication...
Configure these TAM attributes at the global level. We cannot have a different TAM configuration at the domain level to override the configuration at the global level. However, we can override these TAM attributes at the domain level with different Authentication and Authorization security attributes. For example, we can use a different Trust Association Interceptor (TAI) or a different authorization provider.
The federated repositories user registry can only be configured at the global level. There can only be one instance of federated repositories in WAS. Any security domain can use this configuration for its user registry. A security domain can override the configuration with its own user registry. However, it cannot configure a different instance of the federated repository.
Associating scopes to security domainsIn WAS V7.0, we can associate a security domain at the cell level, the server level, the cluster level and the service integration bus level.
When a security domain is associated with a server 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 you want to associate all user applications in WAS to a security domain. In this scenario, all of the admin 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 that is needed.
There are special considerations for a mixed-version environment
If on a base profile server that has its own security domain defined, which is then federated to a dmgr, associate the server scope to the security domain and not the cell scope. When you federate that node, the security domain information is propagated to the dmgr. 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 that is 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
- other security domains associated to various clusters or individual servers
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.
Relationship between old server level security and the new security domains
In previous releases of WAS, you could associate a small set of security attributes at a server level. These attributes were used by all of the applications at the server level. The previous way of configuring the security attributes is deprecated in WAS 7.0, and will be removed in a future release.
You should now use the new security domains support in WAS 7.0, as these security domains are more managed and much more flexible. For example, in previous versions of WAS, manually associate the same security configuration to all of the cluster members by configuring the same security attributes for every server in a cluster.
The migration tool migrates the existing server level security configuration information to the new security domain configuration when the script compatibility mode is false...-scriptCompatibility="false"
A new security domain is created for every server security configuration if it is not part of a cluster. If it is part of a cluster, a security domain is associated with the cluster instead of with all of the servers in that cluster. In both cases, all of the security attributes configured at the server level in previous releases are migrated to the new security domain configuration, and the appropriate scope is assigned to the security domains.
If the script compatibility mode is set to true, the server level security configuration is not migrated to the new security domains configuration. The old server security configuration is migrated without any changes. The security runtime detects that the old security configuration exists and uses that information, even if a security domain is associated either directly or indirectly to the server. If the script compatibility mode is set to true, remove the security configuration from the server level and then create a security domain with the same set of security attributes.
How domain level security attributes are used by security runtime and applications
To enable or disable security for user applications, select...Enable application security
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
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.
User Realm (User Registry)
This section enables you to configure the user registry for the security domain. We can separately configure any registry except the federated registry used at the domain level. The federated repository 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, and 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.
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 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 dmgr, 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, you should not let the system generate the realm name but rather get the realm name used by the processes in the node.
If we allow 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 dmgr. If the realm configured does not match the realm used by the servers there will be 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.
A federated repositories user registry can only be configured at the global level but any domain can use it by configuring it as the active registry. In this case, if the default realm name needs to be changed it has to be changed at the global level.
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 admin applications is bound by the lookup name, “AdminUserRegistry.
As described in Cross realm communication, 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 by using 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 web.xml is not related to the user registry realm.
When you configure the 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 to be used at the domain level.
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 trust association interceptor. Only one instance of TAM's trust association interceptors can exist in the cell.
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 SPNEGO to securely negotiate and authenticate HTTP requests for secured resources was introduced. In WAS 7.0, this function is now deprecated. 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 (CSIv2)
The RMI/IIOP security attribute refers to the CSIv2 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.
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 link...
Trusted authentication realms | outbound
...on the CSIv2 outbound communication panel, or by using addTrustedRealms.
Java Authentication and Authorization Service
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.
Authentication Mechanism Attributes
Various cache settings that must be applied at the domain level.
- Authentication cache settings
Specify 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.
Configure an external third party JACC 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.
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 deployment manager process has to handle all these providers in the same JVM because it has to propagate the authorization policy of applications to the respective provider based on the application name.
If the 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. Is only used at the dmgr process since the managed servers do not host multiple JACC providers.
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.
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 admin 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 that 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 com.ibm.CORBA.loginRealm property in...
...and add the appropriate realms using as the separator. You must also enter the corresponding users and passwords in...
When using the programmatic logon in the Java client code 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 sas.client.props (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 you want the client to cache the subject based on the realm, set property...com.ibm.CSI.isRealmSubjectLookupEnabled
...to true in sas.client.props. If the property...com.ibm.CSI.isRealmSubjectLookupEnabled
...is 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 the property...com.ibm.CSI.isRealmSubjectLookupEnabled
...is 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 property...com.ibm.CORBA.validateBasicAuth
...is set to true (the default value) in sas.client.props, 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 option use_realm_callback 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 admin apps (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.
You 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.
...is set to false in...
...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 for WebSphere Application Version 7.0 does not change the current application security programming model. However, it provides more flexibility and capabilities such as the following:
- User applications can still find the user registry object by using the naming lookup for UserRegistry.
For the registry object used by admin applications, the naming lookup for AdminUserRegistry can be used.
- The application usage of the JAAS login configuration does not change in a multiple domain setup.
However, if an application must refer to the JAAS configuration specified at the domain level, the administrator and the deployer of that application must make sure that this domain is configured with the JAAS configurations required by the application.
- If an application needs to communicate with other applications using different realms, trust relationship should be established for both inbound and outbound communications when using the LTPA tokens.
- When using programmatic login in the applications, to login to the realm used by the application, use <default> as the realm name or provide the realm name that the application is using.
To login to the global realm, provide the global realm name. If we provide any other realm, only a basic authentication subject is created. When the request actually flows to the server hosting that realm, the actual authentication of the user occurs if that server hosts the realm. If the server does not host the realm, the login fails.
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 admin 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, you do not to have to do anything further.
If we do want the cross realm communication to succeed 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 addTrustedRealms command with the –communicationType option set to outbound. It can also be established in the admin console by clicking...Trusted authentication realms - outbound
...on the CSIv2 outbound communications panel.
Inbound trusted realms can be established using the same addTrustedRealms with the –communicationType option set to inbound. It can also be established by using the admin console.
The figure below 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:
- In Domain1, realm1 should trust realm2 for the outbound communication.
- In Domain2, realm2 should trust realm1 for the inbound communication.
- The accessId for user1 should be configured in the authorization table for app2.
When the LTPA token that contains 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 in the above example are deployed in different cells, do the following:
- Share the LTPA keys between the cells.
- Update the authorization table for app2 with foreign users and groups accessIds by using the wsadmin utility. The admin console does not have access to the realms outside of the scope of the cell.
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 admin 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 by 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 dmgr 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 dmgr 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 the property, com.ibm.websphere.allowRegistryLookupOnProcess, to true in the top-level security custom properties. When this property is set, the dmgr code searches one of the servers that is 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 using that domain cannot be accessed, the admin 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 we can obtain the correct format for the domain or realm 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 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 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 not used by using scripting commands or the admin console.
Security domains in a mixed-version environment
You 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:
- If a cell-wide domain is created in a mixed version setup, a domain called PassThroughToGlobalSecurity is created automatically.
All mixed clusters are assigned to this domain at the time of the creation of the cell-wide domain. This PassThroughToGlobalSecurity domain is special in the sense that attributes cannot be added to it, only resources can be assigned to it.
All resources assigned to the PassThroughToGlobalSecurity domain use the global security configuration information. Whenever a node in the mixed version setup is migrated to the latest version, the servers and clusters in these nodes are added to this domain. Applications in all of the servers and clusters in these nodes do not use the cell-wide domain; they instead use the global security configuration before and after migration.
If any of these servers need to use the cell-wide domain, remove these resources from this PassThroughToGlobalSecurity domain. New servers and clusters created in the migrated node use the cell-wide domain, not the PassThroughToGlobalSecurity domain. As a result, we have a mix of servers and clusters, some of them using global security configuration and some using the cell-wide domain.
- Once a cell-wide domain is created, adding any old version cluster members to a WAS V7.0 cluster is restricted since this action makes it a mixed cluster.
This restriction also holds true when a WAS V7.0 cluster is associated with a domain. and a previous version cluster member is added to this cluster. This restriction is needed to avoid associating a security domain to a mixed cluster.
- If possible, you should create a cell-wide domain after all of the nodes have been migrated.
In this case, the cell-wide domain is applicable to the entire cell and not just to parts of it. This also eliminates the need to create the PassThroughToGlobalSecurity domain and the mixed cluster scenario with security domains.
Modify security domains
Use the admin console tasks or scripting commands to modify security domains. For a complete list of admin tasks and scripting commands, see the links in "Related tasks" at the bottom of this document.
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 using the domain configuration.
Before you 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 conceptsSingle sign-on for HTTP requests using SPNEGO Web authentication
Related tasksCreate new multiple security domains
Delete multiple security domains
Copy multiple security domains
Set inbound trusted realms for multiple security domains
Set security domains using scripting
Set multiple security domains using scripting
Remove security domains using scripting
Mapping resources to security domains using scripting
Set CSIV2 inbound and outbound communication settings
Authorizing access to resources
Set programmatic logins for Java Authentication and Authorization Service
Programmatic login for JAAS
Set multiple security domains