OpenRPA Best Practises

OpenRPA
1

We have deployed OpenFlow using Docker, and our OpenRPA robots connect to it using:

OpenFlow Web UI: http://:80**
OpenRPA robot connection: ws://:80**

We are planning to use this setup for production and possibly for projects involving sensitive or financial/banking data, so I wanted to understand the recommended security practices.

I have a few questions:

1-How can we change our current setup from HTTP/WS to HTTPS/WSS?
2-What is the recommended approach? Should we use a reverse proxy such as Nginx or Traefik, or does OpenFlow support HTTPS/WSS directly?
3-Is HTTPS/WSS recommended even if OpenFlow is hosted inside a private network, or is HTTP/WS acceptable in that case?
4-What security best practices do you recommend for a production deployment? For example:
HTTPS/WSS
SSL/TLS certificates
Authentication and authorization
Credential/secrets management
Audit logging
Docker security
Firewall/network configuration
5- Can we connect OpenRPA to any SaaS applications or only SAP?

2
  1. In the docker repo, you simply use the Let’s Encrypt version (docker-compose-letsencrypt.yml). This requires the installation to have a public IP. If you cannot do that, you can use the docker-compose-letsencrypt-dns01.yml example instead.
  2. It is already using Traefik as an ingress controller.
  3. If the server and clients are always inside and will never be accessible from the outside, it’s not strictly needed. It really depends on the compliance and regulation demands your company is working under. Your IT department should have the answer to this.
  4. HTTPS/WSS and SSL/TLS certificates are the same. This is already answered in point 1 and 3. Unless you run everything with the guest account or enable api_bypass_perm_check. You are already using authentication on everything. But I would highly recommend you disable basic authentication (using username/password) and use federation with your existing Active Directory/Microsoft Entra ID/Google Workspace or whatever you’re using for enhanced security. OpenFlow (or OpenCore as we call it now) is meant to run on Kubernetes or OpenShift for highly scalable or enterprise settings, but that requires a license. So, if Docker and a single point of failure work for you, that is perfectly fine too. OpenFlow already has excessive audit logging, and you can lock down the installation even more by enabling entity restrictions.
  5. OpenRPA was made for doing RPA in the old literal sense, i.e., controlling mouse and keyboard. All API integrations are meant to be done using agents in OpenFlow, with the exception of SAP GUI scripting and mainframe automation.
3

Thank you for answering all my questions!