Acosix / alfresco-simple-content-stores

Addon to provide a set of common content store implementations and easy-to-use configuration (no Spring config)
Apache License 2.0
44 stars 19 forks source link

Not encrypting existing files #29

Open monicakumari opened 4 years ago

monicakumari commented 4 years ago

Hi AFaust, This add-on is too good and worked but its not working for existing documents. If I apply this on a new instance to encrypt contentstore, then its working fine but If I apply the amps to the existing instance, then its not working for existing data. The new files created are encrypting but existing files are not encrypting. Is there any way we can apply rule or something to encrypt existing files ?

Thanks.

AFaust commented 4 years ago

It is correct that the addon is not encrypting existing documents - I consciously did not design an automatic encryption process because if you'd make a mistake in configuration, it would be hard to undo / reverse. There are actually two parts to the question of encrypting existing documents: 1) encrypting the live state of a document in workspace://SpacesStore, 2) encrypting the state of any node, even in version or archive store

Variant 1) can already be dealt with by this addon. It would be possible to implement a routing store based on a selector property / aspect which is backed by the default content store and an encrypting store. Then, a batch process could apply the selector on all nodes in workspace://SpacesStore and that would copy/move the content over to the encrypted content store (provided the move/copy flag is set in configuration), encrypting existing content on the fly. If the old content is no longer reference, it would be orphaned and removed after the configured orphan protection period.

Variant 2) would be extremely invasive and potentially hard to do. This addon is not just designed to provide the encrypting content store, but also various routing stores. For old versions or archived nodes it would potentially be impossible to determine if their routing would include an encrypting content store, and if they needed to be encrypted or not. Variant 2) can only work if you decide to globally put EVERY content in the encrypted content store, whereas the design goal of the addon was more towards using many more, granular stores instead of one global one. So that's also the main reason I have not considered this (yet).

I'll have to think about it and see if I can come up with a potential approach to deal with 2).

sagar-nimmala commented 3 years ago

Hi Alex,

Can you please give me a sample configuration to encrypt existing content using variant 1. Below is my present config for encryption.

simpleContentStores.enabled=true

simpleContentStores.customStores=myEncryptingStore,defaultTenantFileContentStore simpleContentStores.rootStore=myEncryptingStore

simpleContentStores.customStore.myEncryptingStore.type=encryptingFacadeStore simpleContentStores.customStore.myEncryptingStore.ref.backingStore=defaultTenantFileContentStore simpleContentStores.customStore.myEncryptingStore.value.keyStorePath=classpath:keystore.jks simpleContentStores.customStore.myEncryptingStore.value.keyStorePassword=password1234 simpleContentStores.customStore.myEncryptingStore.value.masterKeyAlias=myRsaKey simpleContentStores.customStore.myEncryptingStore.value.masterKeyPassword=password1234 simpleContentStores.customStore.myEncryptingStore.value.masterKeyStoreId=SimpleContentStores