WAS v8.5 > Secure applications > Authenticate usersConfigure administrative 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 administrative jobs through a job manager that manages applications, perform product maintenance, modify configurations, and control the application server runtime. Use dmgr console to configure administrative 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 administrative 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 administrative 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 certificate authority (CA) if desired. In this case, make sure the CA root certificate is placed in all RSA trust stores in the same administrative domain.
- Click Security > SSL certificate and key management.
- Under Related Items, click Key stores and certificates.
- Under Keystore usages, select RSA token keystores.
- Select the RSA token key store 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 administrative authentication.
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 administrative 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
Authenticate users