search

SAP-archive / cloud-espm-v2

This sample is a reference application project, showcasing an end-to-end development scenario for a Java-based app on SAP BTP. The app has a SAPUI5 web frontend, uses OData to connect to a Java-based cloud backend which in turn connects via JPA to an SAP HANA DB in the cloud.
https://open.sap.com/courses/hcp2-1
Apache License 2.0
104 stars 85 forks source link

Secure storage for the secretKey? #6

Closed gregorwolf closed 7 years ago

gregorwolf commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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)