Authentication and Authorization using Aerospike REST Client
Tags: aerospike, rest, authentication, authorization
Published: 2020-07-30 11:19:04

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/vv3uf0gkzzadneg2c351.jpg)

In this article we will explain and give some examples of the authentication and authorization flows with the [Aerospike REST client](https://github.com/aerospike/aerospike-client-rest).

If you’re new to the Aerospike REST client please read the [introduction blog post](https://medium.com/aerospike-developer-blog/aerospike-rest-client-cb7e5967f423) by Robert Marks.

Starting from version 1.0.0, the Aerospike REST Client has support for a user and password configuration used to login to the Aerospike cluster. Database administrators need to create these credentials first with the required permissions.

It’s important to mention that the Access Control feature is available only in Aerospike [Enterprise Edition](https://www.aerospike.com/products/product-matrix/).

This setup works perfectly, but what if we want to support multiple users to enable multi-tenancy?

In this case, customers might establish multiple Aerospike REST client clusters, authenticated with different credentials, and route the traffic accordingly. But this setup will require tedious installation operations and will tend to waste resources most of the time.

Starting withAerospike REST client v1.6.0, multi-user authentication is supported. So how does it work? As we already know, the REST client uses the Java client under the hood. Using the single authentication configuration, the REST client shares a singleton authenticated Java client for all requests.

The multi-user feature introduces an LRU based Java client cache. To start using it, customers will need to send Aerospike login credentials using [Basic access authentication](https://en.wikipedia.org/wiki/Basic_access_authentication).

> For example, using the default `admin:admin` credentials, send the `Authorization: Basic YWRtaW46YWRtaW4=` header with your requests to make authenticated queries.

The REST client will seek for a properly authenticated Java client in the LRU cache and if such does not exist, it will create a new one using the given username and password.
If the cache capacity is exceeded, the least recently used client will be dropped.

To use the new feature, set the following configuration variables:
* **aerospike.restclient.requireAuthentication** - Set this boolean flag to true to require Basic Authentication on each request.
* **aerospike.restclient.pool.size** - Represents the max size of the authenticated clients LRU cache (default value: 16). Please note that an oversized client cache will consume a lot of resources and affect performance.

Refer to the [Installation and Configuration](https://github.com/aerospike/aerospike-client-rest/blob/master/docs/installation-and-config.md) REST client page for installation, configuration and running manual.

All this is good but we should talk about different approaches to setting up a multi-user environment, right? Let’s move to the next one.

---

## Kubernetes
To deploy the Aerospike REST client in [Kubernetes](https://kubernetes.io/) please use the official [Helm chart](https://github.com/aerospike/aerospike-client-rest-kubernetes).

The installation and configuration details are available in the readme file, but still, here are the first steps we need to get started.

### Add Aerospike repository
`helm repo add aerospike https://aerospike.github.io/aerospike-kubernetes-enterprise`

### Install the chart
`helm install rest-client aerospike/aerospike-rest-client --set config.hostname=<aerospike_hostname>`

We can configure [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) and route the traffic to different K8s deployments. Kubernetes will manage the resources for us. The multi-user header based authentication is available here as well though.

---

## Using a proxy server authentication middleware
This approach changes the way we handle auth flows and shifts it to a third party software layer instead of using the Aerospike cluster Access Control (hey there Community Edition folks...)

To get things up and running we need the following:

* A proxy server. It can be Traefik, Envoy, Nginx or any other proxy that we like with the auth middleware support.

* An authentication and authorization software to handle the auth requests (like [Auth0](https://auth0.com/) or any other [OAuth](https://en.wikipedia.org/wiki/OAuth) provider).

* The Aerospike REST client itself.

The proxy will require authorization from the auth middleware and if the check passed will route the request to the REST client. See the following [example](https://github.com/aerospike-examples/aerospike-rest-client-auth) implementing this architecture.

I’ll paste here the architecture diagram just in case.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/9dcnw00076d80vf9ij42.png)


Also, you may find the [REST client gateway example](https://github.com/aerospike-examples/rest-client-gateway-spa-example) using an API Gateway and Auth0 to be useful.

---

In this article we’ve listed a number of approaches on how to use the authentication and authorization with the Aerospike REST client and have seen some examples.

I hope it was interesting and beneficial at the same time. If you have any questions regarding the Aerospike REST client, don’t hesitate to open an issue under the [GitHub repository](https://github.com/aerospike/aerospike-client-rest) or contact our team on the <https://discuss.aerospike.com/>.