Table of Contents

How to : retrieve data from a multitenant cluster using anonymous route

Preamble : security concerns

As a security measure, to prevent exposure of sensitive data, it is not possible to directly expose routes from a multitenant cluster without requiring authentication and tenant specification.

If an unauthenticated route is found to lead to unwanted behavior, it is essential to implement a process to revoke the route.

An unauthenticated URL should not be guessable from another, for example it is excluded that the route contains an incremental number (eg: /order/1, we can easily guess /order/2, etc.). Guid is simple and safe way to prevent such guessing.

Example of implementation

Use case

A cluster Technical demos has an Order entity with business data.

We want to send a link to customers so they can check the status of their order (eg: Pending, Shipped, Canceled, ...).

Since users doesn't necessary have an account on the cluster, the url should be accessible without authentication.

Clusters architecture

To avoid exposing unauthenticated routes directly from Technical demos cluster which is multitenant, we create a simple unauthenticated cluster Tracking demo which role will be to expose the unauthenticated routes and link the requests to the right data.

Technical demos

In this cluster, each Order entity is defined by the following properties :

  • OrderId : the unique identifier of the order for a specific tenant
  • TenantId : the tenant on which is associated the order
  • Status : the order status we want to expose to the customer
  • Identifier : the unique identifier of the order (even between several tenants)

The order identifier property is the one which will be visible to the customer.

Tracking demo

This cluster only has one OrderTracking entity with the following properties :

  • ID : the entity key property, not used
  • Identifier : the unique identifier of the order (even between several tenants)
  • OrderId : the unique identifier of the order for a specific tenant
  • TenantId : the tenant on which is associated the order

Inter cluster communications

Since order data is dependant of the associated tenant, it can be persisted in several databases.

If we want to retrieve a specific order from the cluster, we need to know its tenant and its id.

In addition, we don't want to expose these two keys to the customer. That is were the identifier is put into use.

When a customer sends a request for a specific identifier, it is handled by the tracking demo cluster.

The cluster will first search in its database which orderId/tenantId pair is associated to the identifier.

Then, it will use service invocation targeting technical demo cluster with the right tenant and pass the order id.

The technical demos cluster will then retrieve the order data from the right database and send it back to tracking demo cluster.

Finally, the tracking demo cluster will respond to the customer with the order data.