Skip to main content


Using Consumers

Each time an API call is made, Tachyon checks if the:

  • Principal making the call has sufficient permissions to do that call

  • Consumer they're using fulfills the three prerequisites - licensed, registered with Tachyon and enabled.

The Consumer is checked first, the Principal's permissions are checked second, only if the Consumer is successfully verified.

How does software notify Tachyon what Consumer it is?

To define what Consumer is issuing the call, add an X-Tachyon-Consumer field to the header of the HTTP call. Because each HTTP call is independent, each call must include this field in its header.

Some API endpoints do not require or check this header, but most do, so it should be included in each Consumer API call.

Registering a new Consumer

API endpoints relating to Consumers do not check if the software calling them is a Consumer that meets the three prerequisites listed above. This means Consumers can be added or removed by, for instance, their installation or uninstall processes. Although these API endpoints do not check for the X-Tachyon-Consumer HTTP header, they will always check the permissions of the calling Principal.

A Consumer can be registered (added) directly using the API. All the endpoints responsible for Consumer management are located in the Consumer's controller of the API. This is available under https://<MyTachyonServer>/Consumer/Consumers URI. Read the Consumer API reference documentation for details.

A Consumer can also be registered through the Tachyon Settings web application. Browse to Configuration and select the Consumers menu item.

To manage Consumers, the Principal making the call must have Write permission on Consumers' securable type. Set this by assigning the Principal to the Consumer Administrator role.

Consumers vs Principals

In addition to the concept of a Consumer, Tachyon has a concept of a Principals. A Principal can be a user or a group taken from Active Directory. While Tachyon does come with at least one Principal that represents a machine account (therefore a local account, not an Active Directory one), this Principal is created during installation for the purpose of internal communication between various Tachyon components and you cannot add non Active Directory Principals yourself.

A Consumer is a piece of software. A Principal is the user of that software. A "user" is something or someone using the software, for example a computer account running a service is a user even though it's not a person. Consumers are subject to Consumer check as described above. Principals are subject to RBAC checks.

How do Consumers, Principals and Permissions interact

It is important to understand how Permissions interact with Consumers and Principals.

Consumers cannot be assigned Permissions. They cannot be limited to only certain Principals either. In short, Consumers have no link or interaction whatsoever with Permissions or Principals.

Principals have Permissions through Roles they are assigned to, as per standard RBAC model.

This means that a Principal will have the same set of Permissions regardless of what Consumer they use.

If you were to launch a web browser and open Tachyon Explorer, you would have exactly the same set of Permissions as if you had opened Guaranteed State application, made an API call through Postman or run a Powershell script that contacts Consumer API.

When Princiapls and Permissions are concerned, the Consumer is irrelevant. Any Consumer can be used, as long as it is licensed and registered in Tachyon. It is only a tool that is used to perform an action. For RBAC what matter is who performs the action.

What happens when I make a call to Consumer API?

Tachyon performs two independent checks when it receives an API call:

  1. A Consumer API check for X-Tachyon-Consumer header is performed for the vast majority of API endpoints, Consumer management and Information endpoints being notable exceptions.

    1. If given endpoint is excluded from Consumer name check, this first check concludes and the second check in performed.

    2. Consumer API will check the header of the incoming request and retrieve the value of X-Tachyon-Consumer.

      1. If this header is missing the call is rejected and an error is returned stating that X-Tachyon-Consumer field was missing in the header.

    3. Consumer API verifies that the Consumer name obtained from X-Tachyon-Consumer represents a Consumer that is known to Tachyon, that said Consumer is licensed and enabled.

      1. If any of these checks fail, the call is rejected and an error is returned that will describe the issue that caused the Consumer to be rejected, be that it not being registered, unlicensed etc.

  2. Consumer API checks Permissions on the Principal making the call

    1. If the calling Principal doesn't possess the necessary Permissions to perform the operation requested, the call is rejected and an error is returned.