-
Type:
Task
-
Resolution: Won't Do
-
Priority:
L3 - Default
-
None
-
Affects Version/s: 7.13.0-alpha4
-
Component/s: run
-
None
-
Environment:Kubernetes 1.16
On top of CAM-11293, I propose that HTTP Basic Authentication should be enabled for REST engine out-of-the-box. Reasons:
- Encourage secure-by-default. Requiring a user (especially that Camunda is open source software that can be used without training) understands that Camunda by default is insecure is not realistic.
- Potential risk of security breaches that damages for Camunda users and Camunda itself. Please learn from MongoDB (https://nakedsecurity.sophos.com/2018/09/19/here-we-mongo-again-millions-of-records-exposed-by-insecure-database/) and Elasticsearch (https://securityboulevard.com/2019/11/an-unsecured-elasticsearch-server-exposed-1-2-billion-user-records-containing-their-personal-and-social-information/)
- Most initial users will care more about Cockpit and Tasklist than REST. And when they do care about REST, adding an Authorization header is not a big effort, and with proper documentation/quickstart, should be smooth. And again, *with a good password*, more secure than no authentication.
I'd also argue that having a demo:demo account is a bad idea. It should be an auto-generated password that is shown to console on first startup (and provides a way to reset it if missing), and this auto-generation can be turned off. In Kubernetes/Helm environment, the auto-generated password is saved to a Kubernetes secret, which makes it both secure and convenient. But this is another topic.
Our experience with Camunda BPM Run: https://about.lovia.life/docs/infrastructure/camunda/ 
This is the controller panel for Smart Panels app
- depends on
-
CAM-11840 Broken CORS support: OPTIONS preflight must not require authentication. Include Access-Control-Allow-Credentials, Access-Control-Allow-Headers
-
- Closed
-
-
CAM-10062 Camunda Rest Service Distribution
-
- Closed
-
-
-
- Closed
-
- is related to
-
-
- Closed
-