RSA token authentication mechanism for flexible management
The RSA Authentication Mechanism is used to register new servers to the Flexible Management topology, which allows us to submit administrative jobs using a job manager to manage applications, perform maintenance, modify configurations, control the runtime. The RSA token is the default administrative authentication mechanism for the job manager
RSA tokens are 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. From a security perspective, flexible management isolates and preserves base profile configurations. Base profiles managed by an administrative agent can have different LTPA keys, user registries, and administrative users. The RSA token is not related to the RSA SecureId token. WebSphere application server does not provide support for SecureId.
Authentication process
After the RSA root signer certificate (15 year lifetime) is exchanged between two administrative processes, there is no need to synchronize security information among disparate profiles for administrative requests. The RSA personal certificate (1 year lifetime) peforms the cryptographic operations on the RSA tokens and is 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; this includes a nonce value that makes it a one-time use token, a short expiration period (since it's a one-time use token), and 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, allowing 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 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 administrative requests. The RSA token is easier to use while still maintaining a secure transportation of the identity. The data in an RSA token includes:
- Version
- Nonce
- Expiration
- Realm
- Principal
- Access ID
- Roles (not currently used)
- Groups
- Custom data
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 .
-
import com.ibm.websphere.security.cred.WSCredential;
java.util.Properties props = new java.util.Properties();
props.setProperty("myAttribute", "myValue");
WSCredential.put ("customRSAProperties", props);
After the Subject is created at the target process we can 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 containing 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 that is 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.
Example: server-as-client to a target server
The server-as-client has an administrative 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 signs 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 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: