Secure storage for the secretKey?

[gregorwolf]

Hello,

as this is a reference application I can't understand why it should be required that the secretKey for the SAP CP Document Repository is stored in a property file:
config.properties. I would think that can't a good example for production code. Isn't there a place in the SAP Cloud Platform Cockpit where such security critical information can be provided to the app in a secure fashion instead of storing it in a versioned file for the source code.

Best regards
Gregor

[dguendisch]

Hi Gregor,

the repository key has quite some historics and originates from SAP (HANA) Cloud Platform days when it was THE authentication mechanism for apps on their repositories.
Nowadays the main authentication on a document service repository is a dedicated client certificate being present on every app/VM. It is used when establishing the ssl connection to the document service.
A repository created in account A can only be accessed by apps running in account A (but not by apps running in account B) and this isolation is secured by the aformentioned certificate.
Some more details on this can be found here: https://help.sap.com/viewer/b0cc1109d03c4dc299c215871eed8c42/Cloud/en-US/f639d68ff43347e6ac0453541b5daada.html

As account authentication and isolation is enforced by the client cert now, the repository key has "lost" its importance. Theoretically it can be used to e.g. only allow app X in account A to access a repository R and at the same time ensure that app Y in account A cannot access this repository R, but that's a more rare usecase given the fact that typically people who are allowed to deploy app X or App Y can reset repository keys as well or simply redeploy app X or Y again to extract the repository key.

Given that, it's not a security issue to store the repository key in plain text, but I agree that the reference app could be improved by showing the usage of the CP password storage which people might need for other scenarios anyway.

Regards,
Dieter

[skrishnakumar]

Thanks Dieter for the detailed information.

The password store usecase is something that we showcased in the Authorization Management API scenario with ESPM. So, i think it would be best when enhancing the app, we can try out the client certificate for espm use case.

[dguendisch]

Just to be clear: you are already using the client certificate, otherwise you wouldn't be able to access your repository (it's happening automatically, the preprovisioned OpenCMIS clients already take care of the client cert authentication)