Data Object with sensitive fields, should only mask the field values not the field itself

[harmeet-status]

Data Object with sensitive fields, should only mask the field values not the field itself.

See @MarD0607 comment below for details https://github.com/sartography/spiff-arena/issues/1437#issuecomment-2074575808

[calexh-sar]

@harmeet-status Spiff is not fined grained enough in our permission system at this time. Need additional information about the use cases you have in mind.

[MarD0607]

@calexh-sar The use case and how I see it happening in Spiff is the following:

• as a process analyst I design a process model and as part of that model there are arrays of data fields which are imported or inputted and then transformed into other arrays or data and so on
• the process analyst can then enter the data fields used in the process into a list , can be a dmn table
• there is a reusable call activity which can then be added to the process model and this call activity does the following:
  1. checks the list of data fields for the data fields related to the current process
  2. for each data field in the list it uses an encryption mechanism that will transform the Values to strings such as *** or other encryption string Therefore instead of using data objects that hide all the details of the data fields , we can only hide the values of the data fields. And that is actually where the security issue is, with the values not the data field name itself.

The only part which I need to figure out is when we need as part of the process to pass the data fields and the values to a service task, like a POST url, because we would need do decrypt the values before passing them on as output data. However we should not be able to see the values even then.

I can try building this myself with support from you.

[danfunk]

2 Options:

1) Add Json Schemas to data stores, add some non-standard flag to fields in a data store that signify that information should be redacted - would require some additional front-end, backend-end and bpmn-io work to fully implement.
2) We split the data objects up so that only the data that needs to be secured is stored there.

Discussed all options, and Marius will try option 2 and get back to us.

[calexh-sar]

@MarD0607 any feedback on this?

[MarD0607]

Option no.2 is a valid approach It requires additional scripting in order to separate unsensitive data from sensitive data before creating the data object

[calexh-sar]

@harmeet-status is option #2 sufficient going forward? If so, will close this issue. If not, we will estimate option #1.

[harmeet-status]

Ok close ticket. Going with option 2.

[calexh-sar]

Closing per Harmeet's comment