Open leochr opened 2 weeks ago
The question that arose was whether an ltpa.keys
can be shared between Liberty servers where some use the default password encryption key while others use a custom password encryption key (wlp.password.encryption.key
).
I tested the following and I believe it confirms that ltpa.keys can be shared as long as the original (plain text) LTPA password is encrypted accordingly (using the appropriate default/custom key) and set in server config (using the keysPassword
field of ltpa
element):
ltpa.keys was generated by the following command:
securityUtility createLTPAKeys --file=ltpa.keys --password=mypassword --passwordEncoding=aes
<?xml version="1.0" encoding="UTF-8"?>
<server>
<ltpa keysFileName="${server.config.dir}/managedLTPA/ltpa.keys" keysPassword="{aes}AN4QZlt4JCdRVhzoOphGMnTETt9gYZSqax3RSnUVHH/FcydnjHmIwvXJyiYKMc900g==" />
</server>
[8/29/24, 17:05:39:066 UTC] 0000003b com.ibm.ws.security.token.ltpa.internal.LTPAKeyCreateTask I CWWKS4105I: LTPA configuration is ready after 0.162 seconds.
wlp.password.encryption.key
with the same ltpa server config and restarted the pod :<?xml version="1.0" encoding="UTF-8"?>
<server>
<variable name="wlp.password.encryption.key" value="randomkey" />
</server>
[8/29/24, 17:06:54:614 UTC] 00000039 com.ibm.websphere.crypto.PasswordUtil E CWWKS1856E: The password was not processed because an unknown password algorithm exception was reported.
com.ibm.websphere.crypto.UnsupportedCryptoAlgorithmException
...
...
Caused by: javax.crypto.BadPaddingException: Given final block not properly padded. Such issues can arise if a bad key is used during decryption.
...
...
[8/29/24, 17:06:54:666 UTC] 00000039 com.ibm.ws.logging.internal.impl.IncidentImpl I FFDC1015I: An FFDC Incident has been created: "java.lang.NullPointerException com.ibm.ws.security.token.ltpa.internal.LTPAKeyCreateTask 123" at ffdc_24.08.29_17.06.54.0.log
[8/29/24, 17:06:54:671 UTC] 00000039 com.ibm.ws.security.token.ltpa.internal.LTPAKeyCreateTask E CWWKS4106E: LTPA configuration error. Unable to create or read LTPA key file: /opt/ol/wlp/usr/servers/defaultServer/managedLTPA/ltpa.keys
sh-4.4$ securityUtility encode --encoding=aes --key=randomkey mypassword
{aes}ANH8n3T0silDbCmfXvzrB2ZPOpR5PHfhlYPVyGtBFsjebKzM4r87BMHtb9owv8nyGw==
The ltpa.keys is still the same one from step 1.
<?xml version="1.0" encoding="UTF-8"?>
<server>
<ltpa keysFileName="${server.config.dir}/managedLTPA/ltpa.keys" keysPassword="{aes}ANH8n3T0silDbCmfXvzrB2ZPOpR5PHfhlYPVyGtBFsjebKzM4r87BMHtb9owv8nyGw==" />
</server>
[8/29/24, 17:09:05:962 UTC] 0000003b com.ibm.ws.security.token.ltpa.internal.LTPAKeyCreateTask I CWWKS4105I: LTPA configuration is ready after 0.137 seconds.
@arkarkala This is the workitem related to our discussion on sharing ltpa.keys between different Liberty servers (where some use the default password encryption key while others use a custom password encryption key). I believe the above tests results validate your statement: "passwordKey is used to encrypt the ltpa.password. the plain text ltpa.password is used to encrypt the keys in the ltpa.keys file"
Please review and let us know if you see any problems with this proposed approach or for any reason the ltpa.keys can not (or must not) be shared in this manner.
Share the LTPA key between OpenLibertyApplication CR instances using the default password encryption key and those using custom password encryption key (specified via
wlp.password.encryption.key
variable).ltpa
element andkeyPassword
according to the usage ofwlp.password.encryption.key
securityUtil encode