- There are some password usages in the product without support of obfuscated/encrypted passwords. These areas need to support obfuscated/encrypted passwords as well.
- At this time, passwords can only be provided obfuscated. There are needs to enhance this security to encrypted passwords.
Conditions of Satisfaction:
a) I can use the standard password routine (at this time obfuscation only) for Kitchen (bug
PDI-11191 derived from PDI-9352)
b) I can use the standard password routine (at this time obfuscation only) for Pan (bug
c) I can use the standard password routine (at this time obfuscation only) within the <repository><password> also for Carte (it works for the DI Server) (bug
d) I can use the standard password routine (at this time obfuscation only) for Carte Web Services (DI-Server) (bug
e) I have a plugin type to support pluggable encryption/decryption of passwords (derived from
f) The existing obfuscation routine is the standard password encryption/decryption plug-in (for backward compatibility) and can be replaced by a custom plug-in (enable using a variable in kettle.properties KETTLE_ENCRYPTION_PLUGIN)
- The encryption and decryption is out of scope for this Epic. It can be done by the customer or services engagement by building this plugin. This Epic only enables this plugin-option.Follow up on this: PDI-10642
- For backward compatibility: When a password starts with "Encrypted ", we need to use the (old) obfuscation routine.
- When a password starts with a special string (e.g. "PluginEncrypted ") the plug-in encryption is used
- Consider the same approach across the platform, there is a comment from Marc on
PDI-6168(17/Oct/11) regarding the BA-Server, see also BISERVER-3497
- Consider including consistent handling of decryption (architectural): sometimes the encryption is done in loadRep, loadXML, execute - sometimes only in loadRep, loadXML (see PDI-11187 as a follow up from
UX Notes: No UX on this case at this time. If the requirements change please let us know.