Revolutionary simple Multi-Tenancy Approach for OPAL

[plduser]

This repository https://github.com/plduser/opa-zero-poll-single-topic-multi-tenant contains a breakthrough solution for multi-tenancy in OPAL designed for high-scale SaaS applications that eliminates both the need for system restarts and the complexity of incremental updates (PATCH operations) when adding new tenants.

Traditional (restart required):
┌─────────────────┐ topics: tenant_1_data ┌─────────────────┐
│ OPAL Server │◄─────────────────────────────│ OPAL Client │
│ │ topics: tenant_2_data │ │
│ Multi Topics │◄─────────────────────────────│ Multi Subscribe │
└─────────────────┘ topics: tenant_3_data └─────────────────┘
⚠️ New topic = RESTART

The solution (no restart):
┌─────────────────┐ topic: tenant_data ┌─────────────────┐
│ OPAL Server │◄─────────────────────────────│ OPAL Client │
│ │ (for all tenants) │ │
│ Single Topic │ │ Single Subscribe │
│ Multi Sources: │ │ Multi Data Fetch │
│ - /acl/tenant1 │ │ - URL1→/acl/ten1 │
│ - /acl/tenant2 │ │ - URL2→/acl/ten2 │
│ - /acl/tenant3 │ │ - URL3→/acl/ten3 │
└─────────────────┘ └─────────────────┘
✅ One topic, multiple sources, different paths

The idea and the proof of concept is described in the documentation. Repo is working docker-compose file, ready to test.
Would be great to discuss it!

[gemanor]

Nice approach! You're more than invited to open a PR and contribute it to the OPAL docker files folder

[plduser]

That's great! I have a question about how to prepare it properly. The provided example should work out of the box after running docker-compose, using the example data — both the policies and the external data source configured in Nginx (just a few entries in nginx.conf). In my repo, I have docker-compose.yml, a policies directory, and a simple example API provider as an nginx.conf file. I'm wondering how to best integrate the solution into the current folder structure of "docker files folder".