Set admin authentication
An authentication mechanism defines rules about security information, such as whether a credential is forwardable to another Java process, and the format of how security information is stored in both credentials and tokens. The Rivest Shamir Adleman (RSA) token authentication mechanism simplifies the security environment for flexible management topology, that is, the topology where we can locally or remotely submit and manage admin jobs through a job manager that manages applications, perform product maintenance, modify configurations, and control the appserver runtime. You use the admin console to configure admin authentication, which involves the configuring of the Rivest Shamir Adleman (RSA) token authentication mechanism.
The following keystore, truststore, and rootstore descriptions give you an idea of where certificates are stored and how trust is configured between processes.
The NodeRSATokenKeyStore contains the Rivest Shamir Adleman (RSA) token personal certificate used for this process. Not only is the public/private key from this certificate used to create RSA tokens, but the public key is used by other processes to create tokens. The RSA personal certificate is signed by an RSA root certificate. The NodeRSATokenTrustStore contains all RSA signer certificates from other processes that are trusted to send RSA tokens to this process. The signers in this trust store are placed there automatically during the registration process. However, this task allows an administrator to configure trust between to processes not normally involved in the same admin domain. There may be requirements where two base servers are communicating administratively. When using the RSA token authentication mechanism, the base servers need to share RSA signers if admin communications is operating in both directions.
The NodeRSATokenRootStore contains the root personal certificate used to create new RSA personal certificates. Do not use the root certificate to create RSA tokens because this usage compromises the long-lived keys. Only use the root certificate to sign other certificates.
No manual steps are required with these keystores, and this allows uncommon trust establishment among processes not in the same administrative domain. We can also replace the RSA personal certificate with a personal certificate obtained from a CA if desired. In this case, make sure the CA root certificate is placed in all RSA trust stores in the same admin domain.
- Click SSL certificate and key management > Global security . Under Keystore usages select RSA token keystores from the drop-down list.
- Select the RSA token key store you want to administer.
- Modify the description if required.
- Modify the path if required.
- Select read only, initialize at setup, or both if required.
- Enter the correct password to make these modifications
- Click Apply and Save.
Results
You configured admin authentication.
Next steps
In cases where the process is back-level or a target RSA certificate cannot be obtained, the fallback mechanism is Lightweight Third-Party Authentication (LTPA) which is supported in all previous releases for admin communications. The fallback occurs automatically. If the LTPA keys are not shared and a fallback occurs, LTPA will fail as well. However, this situation is typically an error case in the RSA mechanism and should occur infrequently.
Related concepts
Job manager security
Related tasks
Authenticate users