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
we need to mask password properties in all Configurations returned by SLSB AP...
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Core UI (Show other bugs)
4.0.0
All All
high Severity high (vote)
: ---
: ---
Assigned To: Charles Crouch
Mike Foley
:
Depends On:
Blocks: config/individual-config 677348 jon3 jon3-sprint1 715334
  Show dependency treegraph
 
Reported: 2011-03-25 17:34 EDT by Ian Springer
Modified: 2015-02-01 18:26 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-09-03 13:01:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Ian Springer 2011-03-25 17:34:14 EDT
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.
Comment 1 Ian Springer 2011-05-26 17:33:21 EDT
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
Comment 2 Ian Springer 2011-05-26 17:42:34 EDT
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"
Comment 3 Mike Foley 2011-06-01 12:04:16 EDT
verified for resource config, and group resource config.
Comment 6 Heiko W. Rupp 2013-09-03 13:01:43 EDT
Bulk closing of old issues that are in VERIFIED state.

Note You need to log in before you can comment on or make changes to this bug.