[
https://issues.apache.org/jira/browse/SLING-13282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18120148#comment-18120148
]
Stefan Seifert commented on SLING-13282:
----------------------------------------
> i agree the encryption should be part if the caconfig impl as well - Can you
> suggest where exactly?
that's a very good question.
encryption has to take place when writing configurations. configuration write
is handled via the ConfigurationManager, but this just delegates the actual
write to configuration persistence strategy implementations. although the sling
caconfig impl comes with a default implementation, the encryption part should
not go into this, as every implementation will then have to reproduce this
logic - that will likely lead to diverging results.
currently, i would see the solution for encryption roughly like this:
* within ConfigurationManagerImpl, before actually handing over the
ConfigurationPersistData to the persistence strategy implementation, this data
should be preprocessed, applying any encrypting as needed for some of the
properties.
* this preprocessed data is then passed over to the persistence strategy,
making the encryption completely transparent for it
* as an implementation detail, we should not actually modify the passed over
ConfigurationPersistData, but create a clone of it with the partially encrypted
data
thoughts on the decryption part:
* likewise, the decryption should be implemented as a thin layer to
post-process the data returned by the persistence strategy, again making the
decryption transparent to the persistence implementation
* we have three different APIs to read configuration data:
** ConfigurationResolver/Builder: "high-level" access with maps, classes etc.
** ConfigurationResourceResolver: "low-level" access with directly returning
resources
** ConfigurationManager: reading configurations plus all the
configuration/property metadata for editor support
* ideally, we would support encryption for all three APIs at a central place,
e.g. as a thin layer about the persistence strategy implementation
* but: the current SPI interfaces are probably not perfectly suited for this
integration - we would need to shadow the returned resources. therefore, maybe
the better approach is to support it only for the "high-level" read APIs
(ConfigurationResolver, ConfigurationManager), and skip the "low-level" API
(ConfigurationResourceResolver). in that case, the decryption part would be
take place in the high-level configuration builder and the configuration
management interface implementations. we would need to document this
restriction for the low-level API very clearly.
> Support automatic decryption in Context-Aware Configurations
> ------------------------------------------------------------
>
> Key: SLING-13282
> URL: https://issues.apache.org/jira/browse/SLING-13282
> Project: Sling
> Issue Type: Improvement
> Affects Versions: Context-Aware Configuration API 1.3.0, Context-Aware
> Configuration Impl 1.7.2
> Reporter: Konrad Windszus
> Assignee: Konrad Windszus
> Priority: Major
>
> The high-level API described at
> https://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration.html#context-aware-configurations
> relies on annotations to map a property to an underlying resource property:
> https://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration.html#describe-configurations-via-annotation-classes.
> Those should allow to optionally decrypt the underlying resource property
> while reading from the resource through
> https://sling.apache.org/documentation/bundles/commons-crypto.html#crypto-service.
> Either the annotation
> https://github.com/apache/sling-org-apache-sling-caconfig-api/blob/master/src/main/java/org/apache/sling/caconfig/annotation/Property.java
> could be extended with an additional boolean flag or one could use the
> existing {{properties}} element to use that.
> This is useful for sensitive data (like passwords, API keys, ...) which is
> site specific (and therefore hard to store inside OSGi configurations) but
> should nevertheless not be stored in clear text in the underlying repository.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
