Problem: Tentant keys cannot be changed during runtime

[eponsko]

It's a bit annoying that tenant keys are fixed in the beginning when starting the broker. Solution: Add a mechanism for dynamically adding and removing tenant keys. Solution1: Could be via the very basic REST interface;
keylist = GET /keys PUT /keys [new key] Question is how to make sure the one adding/removing keys is allowed to do it, HTTP Basic auth?

Solution2: Add a Client->Broker command for doing it, already authenticated via initial keys.

[DavideXX92]

Hi Pontus,

I'd like to add new tenant keys during broker runtime and the feature you have described above looks like what I'm looking for! Do you have any updates about this feature?

[eponsko]

Hi Davide,

No updates have been done so far regarding this. I think the easiest way would be to once in a while check if the broker keyfile has been modified and if so, re-open it. In that case, you could just put a new file there and have the new key read after say maximum 60 seconds or something like that (could add a signal to the broker to re-read the file as well). This would require some rewrites to the key generator though (it's quite crappy at the moment anyway).

Would that work for your use-case or do you need something that can be done over the network?

[DavideXX92]

Dear Pontus,

what you have described could work for my use case. When a new tenant registers to my service I need to generate a new DD key and someway to communicate it both to the message broker and to the public tenant. I think this scenario needs some new features: 1) ddkey should provide a way to update .keys files in order to add or remove keys 2) both DD broker and agent should be able to reload the .keys file runtime

Moreover I need to communicate at least the updated public.keys file to my public tenant, such a communication may be performed either by my application or by a DD API, depending on what you can provide me

[eponsko]

Hmm given that the keys need to go to the public clients (forgot about that), probably it should be something provided by the protocol itself, especially when taking a case with hierarchical brokers into account (annoying to have to update N key files). I guess a more proper solution would be to have a protocol by which all brokers could synchronize the keys, during runtime. E.g. if two brokers connect to each other, they should automatically synchronize the keys they both have, allowing one to start with only the broker key and receive all tenant-keys after starting. When (regular) clients then connect they should also receive the key to public clients, if it exists. Finally, tenant keys should be distributed to public clients when they connect, and when new keys are added. Hmm, I'll need to think about it a bit, I don't remember exactly how the keys are constructed, so not sure if it would be possible :)

[frisso]

Your proposal would be exactly what we need in order to allow tenants to dynamically join and leave the infrastructure.

[eponsko]

Hi guys,

Sorry for the slow response here, have been busy traveling and with the usual lovely deliverables.. I am working on implementing this, but currently a bit lacking time to work a lot on it. It's coming though!