Skip to content

Inter process function security

cdmdotnet edited this page May 11, 2018 · 1 revision

In versions prior to 2.4 (2.3 and lower) inter-function and inter-handler security when using multiple servers/processes with a service-bus as the network communication tool to distribute your loads security was left mainly up to the credentials and access to the bus.

This is fine in many cases. Much like a database, you have one connection and control access with credentials. In some cases security can as broad as creating read-write credentials and read-only credentials. This is however very limiting.

Source: CloudAMQP from CloudAMQP

Trusted publishers

This type of security requires trusting all of the possible code that is allowed to raise and send messages. While we can always assume that we can trust applications, functions and website developed within an organisation, some basic questions do have to be asked. Question like "While it might make sense for a travel website to trigger a message that can issue a ticket... should the same website be able to buy new $200 million dollar air-planes?" Of course not.

While this might sound trivial, there are many situations where System A should only be able to issue certain requests in System B. This is the notion of partially trusted publishers.

Version 2.3 and prior security.

As mentioned, in version 2.3 and prior, this would be solved by setting up multiple service-buses with different credentials and splitting the receiving functions/applications of System B across those service-buses. When you have simple requirements such as just two permission groups this is workable... but soon you'll realise that the problem of security is rapidly overtaken by highly complex deployments and set-ups. What becomes necessary is security on a per request/message type.

Version 2.4 per message-type security.

From version 2.4 security in the Azure service-bus modules will allow per message-type security with a fallback to the existing mode as required.

There are several ways of implementing such a change and we've chosen a simple, yet effective, non-centralised model that doesn't suffer from single-point-of-failure bottlenecks.

Each receiving application can be configured with a Default Signing Token. Any message that is signed with the master token will be permitted. For more granular control, each type of message (IssueTicket, CreateAccount, PayNewPlane) can be optionally configured to have it's own Signing Token. Doing so will enable certain types of messages to require signing with the specific Signing Token rather than the Default Signing Token. With this security mechanism in-place sensitive messages can only be raised by approved applications and website without having to add the complexity multiple service-buses.

Clone this wiki locally
You can’t perform that action at this time.