Performing identity mapping for authorization across servers in different realms
Identity mapping is a one-to-one mapping of a user identity between two servers so that the proper authorization decisions are made by downstream servers. Identity mapping is necessary when the integration of servers is needed, but the user registries are different and not shared between the systems.
In most cases, requests flow downstream between two servers that are part of the same security domain. In WAS, two servers that are members of the same cell are also members of the same security domain. In the same cell, the two servers have the same user registry and the same LTPA keys for token encryption. These two commonalities verify the LTPA token, among other user attributes, which flows between the two servers, not only can be decrypted and validated, but also the user identity in the token can be mapped to attributes that are recognized by the authorization engine.
The most reliable and recommended configuration involves two servers within the same cell. However, sometimes we need to integrate multiple systems that cannot use the same user registry. When the user registries are different between two servers, the security domain or realm of the target server does not match the security domain of the sending server.
WAS enables mapping to occur either before sending the request outbound or before enabling the existing security credentials to flow to the target server. The credentials are mapped inbound with the spec that the target realm is trusted.
An alternative to mapping is to send the user identity without the token or the password to a target server without actually mapping the identity. The use of the user identity is based on trust between the two servers. Use CSIv2 identity assertion. When enabled, the server sends just the X.509 certificate, principal name, or distinguished name (DN) based upon what was used by the original client to perform the initial authentication. During CSIv2 identity assertion, trust is established between WASs.
The user identity must exist in the target user registry for identity assertion to work. This process can also enable interoperability between other Java2 Platform, Enterprise Edition (J2EE) V1.4 and higher compliant application servers. If both the sending server and target servers have identity assertion configured, WAS always uses this method of authentication, even when both servers are in the same security domain.
See on CSIv2 identity assertion, see Identity assertion to the downstream server. When the user identity is not present in the user registry of the target server, identity mapping must occur either before the request is sent outbound or when the request comes inbound. This decision depends upon the environment and requirements. However, it is typically easier to map the user identity before the request is sent outbound for the following reasons:
- You know the user identity of the existing credential as it comes from the user registry of the sending server.
- You do not have to worry about sharing Lightweight Third Party Authentication (LTPA) keys with the other target realm because we are not mapping the identity to LTPA credentials. Typically, we are mapping the identity to a user ID and password that are present in the user registry of the target realm.
When you do perform outbound mapping, in most cases, IBM recommends that you use SSL to protect the integrity and confidentiality of the security information sent across the network. If LTPA keys are not shared between servers, an LTPA token cannot be validated at the inbound server. In this case, outbound mapping is necessary because the user identity cannot be determined at the inbound server to do inbound mapping.
See Set outbound identity mapping to a different target realm.
When you need inbound mapping, potentially due to the mapping capabilities of the inbound server, ensure that both servers have the same LTPA keys so that we can get access to the user identity. Typically, in secure communications between servers, an LTPA token is passed into the WSCredTokenCallback callback of the inbound JAAS login configuration for the purposes of client authentication. A method is available that enables you to open the LTPA token, if valid, and get access to the user unique ID so that mapping can be performed. For more information, see Set inbound identity mapping. In other cases, such as identity assertion, we might receive a user name in the NameCallback callback of the inbound login configuration that enables you to map the identity.
The following topics are covered in this section:
- Set inbound identity mapping For inbound identity mapping, we can write a custom login module and configure WAS to run the login module first within the system login configurations. Consider the following steps when you write the custom login module: Set inbound identity mapping.
- Set outbound identity mapping to a different target realm
By default, when WAS makes an outbound request from one server to another server in a different security realm, the request is rejected. This page details alternatives for enabling one server to send outbound requests to a target server in a different realm. For more information, see Set outbound identity mapping to a different target realm
Set inbound identity mapping
Set outbound identity mapping to a different target realm
Set CSIV2 inbound and outbound communication settings