Red Hat Bugzilla – Bug 690943
we need to mask password properties in all Configurations returned by SLSB APIs and unmask them in SLSB APIs that update existing Configurations
Last modified: 2015-02-01 18:26:52 EST
This will ensure that the current values of password properties are not viewable by users of the GUI or the CLI, which is important for the sake of security.
This is done - [master fb5b7de].
A summary of the changes:
1) add two new methods to PropertySimple domain entity: mask() and isMasked(); mask() sets the value field to a special constant (MASKED_VALUE) if the original value was non-null, and isMasked() returns true if the property's value is MASKED_VALUE
2) add a ConfigurationMaskingUtility class to server jar that provides two methods: maskConfiguration() and unmaskConfiguration(); maskConfiguration() recursively iterates a Configuration and calls mask() on all PASSWORD simple properties; unmaskConfiguration() iterates a Configuration, and for all simple properties for which isMasked() returns true, sets their value to the value of the same property from a second "reference" (unmasked) Configuration that is also provided by the caller
3) update all SLSB methods in ConfigurationManagerBean that return resource or plugin Configurations to call ConfigurationMaskingUtility.maskConfiguration() on them before returning them; make sure to call clear() on the entity context before masking to prevent the masked version of the Configuration from being persisted (masked values should -never- get persisted)
4) update all SLSB methods in ConfigurationManagerBean that update resource or plugin Configurations to call ConfigurationMaskingUtility.unmaskConfiguration() on them before persisting them, to ensure properties with masked values get set back to their actual values before persisting
5) remove the old, now superseded, masking code from a) the PropertySimple entity (the unmaskedValue field), b) core-gui (the old ConfigurationMaskingUtility class and its usages in the ConfigurationSet class), and c) all calls to the old masking/unmasking logic in portal-war UI beans
QA Verification Steps
do the following steps for a resource config, a plugin config, a group resource config, and a group plugin config:
1) edit a config that has one or more PASSWORD properties (e.g. - an RHQ Agent resource config contains several)
2) set one of the password props to some value (e.g. "foobar") and then save the config
3) wait for the config update to complete
4) go the underlying managed resource and look at its config and make sure the value of the prop you updated is "foobar"
5) edit the config again; look at the live HTML/DOM source using the Firebug or Web Developer plugin and verify that the value "foobar" is nowhere to be found. this value should not even be sent over the wire - instead a masked value ("_._._[MaSKeD]_._._") is sent
6) change some prop *other than the one you updated in step 2)* and save the config
7) repeat steps 3 and 4
8) edit the config again; set the password prop from step 2) to a new value (e.g. "yomama") and save the config
9) repeat steps 3 and 4, except check that the underlying managed resource value is now "yomama"
verified for resource config, and group resource config.
Bulk closing of old issues that are in VERIFIED state.