RSA token authentication mechanism
The Rivest Shamir Adleman (RSA) Authentication Mechanism is used to simplify the security environment for the Flexible Management Topology. It supports the ability to securely and register new servers to the Flexible Management topology. With the Flexible Management topology, we can submit and manage administrative jobs, locally or remotely, by using a job manager that manages applications, performs product maintenance, modifies configurations, and controls the appserver runtime.
The RSA authentication mechanism is only used for server-to-server administrative authentication, such as admin connector and file transfer requests. The RSA authentication mechanism does not replace LTPA or Kerboros for use by applications.
New feature: The RSA token authentication mechanism is new to this release of WAS. It aids the flexible management objective to preserve the base profiles configurations and isolate them from a security perspective. This mechanism permits the base profiles managed by an administrative agent to have different LTPA keys, different user registries, and different admin users
The RSA token is not related to the RSA SecureId token. Please note that the appserver does not provide support for SecureId.
Authentication is the process of establishing whether a client is who or what it claims to be in a particular context. A client can be either an end user, a machine, or an application. An authentication mechanism in WAS typically collaborates closely with a user registry.
The user registry is the user and groups account repository that the authentication mechanism consults with when performing authentication. The authentication mechanism is responsible for creating a credential, which is an internal product representation of a successfully authenticated client user. Not all credentials are created equally. The abilities of the credential are determined by the configured authentication mechanism.
Authentication process
The RSA token authentication mechanism ensures that after the RSA root signer certificate (15 year lifetime) is exchanged between two admin processes, there is no need to synchronize security information among disparate profiles for admin requests. The RSA personal certificate (1 year lifetime) is used to perform the cryptographic operations on the RSA tokens and can be verified by the long-lived RSA root.
RSA token authentication is different from LTPA where keys are shared and if one side changes, all sides need to change. Since RSA token authentication is based on a PKI infrastructure, it benefits from the scalability and manageability of this technology in a large topology.
An RSA token has more advanced security features than LTPA, including...
- nonce value that makes it a one-time use token
- short expiration period (since its a one-time use token)
- trust, which is established based on certificates in the target RSA trust store
RSA token authentication does not use the same certificates as used by SSL. This is the reason RSA has it's own keystores.
In order to isolate the trust established for RSA, the trust store, keystore, and root keystore, need to be different from the SSL configuration.
SSL personal certificates given to pure clients are often signed by the same SSL root certificate used by servers, and this allows a pure client to send an RSA token to a server and act as an administrator.
This should be avoided for the RSA token authentication mechanism.
The RSA token authentication mechanism has its own root certificate which signs personal certificates that are used to encrypt and sign parts of the token.
The data stored in an RSA token is based on the identity of the client subject. The client subject can be based on LTPA or Kerberos, but the RSA token does not use this protection for admin requests. The RSA token is easier to use while still maintaining a secure transportation of the identity.
The data in an RSA token includes:
Custom data can be added to the WSCredential on the sending side (prior to going outbound) by creating a properties object, adding custom attributes, and adding this to the WSCredential in the following way.
import com.ibm.websphere.security.cred.WSCredential;
java.util.Properties props = new java.util.Properties();
props.setProperty("myAttribute", "myValue");
WSCredential.put ("customRSAProperties", props);
Once the Subject is created at the target process, to access these attributes...
java.util.Properties props = (java.util.Properties) WSCredential.get("customRSAProperties");
This data is placed into a hash table at the target side and the hash table is used in a (JAAS) login to obtain a subject at the target that contains the same attributes from the RSA token. With the target containing the same attributes from the RSA token, we can have a subject at the target side not from the same realm used by the target. For this authorization to succeed, a cross-realm mapping is required within the administrative authorization table unless the identity is a trusted server ID.
The figure (below) is an overview of the RSA token authentication mechanism and describes the process that takes place when a request is sent from a server-as-client to a target server. The server-as-client has an admin subject on the thread used as input to create the RSA token. The other information needed is RSA public certificate of the target server. This certificate must be retrieved by making a bootstrap MBean request to the target process prior to sending any real requests. The target bootstrap request retrieves the public certificate from the target process. When creating an RSA token, the primary purpose of obtaining the target's public certificate is to encrypt the secret key. Only the target can decrypt the secret key, which is used to encrypt the user data.
The client's private key is used to sign both the secret key and the user data. The client's public key is embedded in the RSA token and validated at the target.
If the client's public key is not trusted when calling the CertPath APIs at the target, the RSA token validation cannot continue. If the client's public key is trusted, it can be used to verify the secret key and user data signatures.
The basic goal is to convert the client subject into a subject at the target by securely propagating the required information. After the subject is generated at the target, the RSA authentication mechanism process is complete.
Related concepts
Job manager security
Related tasks
Set the RSA token authentication mechanismSelect an authentication mechanism
Related
RSA token authentication settingsRSA token certificate use