Allow any jwt field to be used as an acl variable

memelet · December 18, 2018, 8:14pm

JWT rule variables

Allow any jwt field to be used as an acl variable.

We encode all permissions into the jwt. Each of our services can then use only the jwt for authn.

It would be ideal if ror could do the same: Allow for referencing a jwt variable by path for acl substitution.

Let’s do this?

1
2
3
4
5

0 voters

sscarduzio · September 16, 2019, 5:14am

this was done a month ago!

github.com

beshu-tech/readonlyrest-docs/blob/master/elasticsearch.md#dynamic-variables-from-jwt-claims

# For Elasticsearch

## Overview: The ReadonlyREST Suite

ReadonlyREST is a light weight Elasticsearch plugin that adds encryption, authentication, authorization and access control capabilities to Elasticsearch embedded REST API. The core of this plugin is an ACL engine that checks each incoming request through a sequence of **rules** a bit like a firewall. There are a dozen rules that can be grouped in sequences of blocks and form a powerful representation of a logic chain.

The Elasticsearch plugin known as `ReadonlyREST Free` is released under the GPLv3 license, or alternatively, a commercial license \(see [ReadonlyREST Embedded](https://readonlyrest.com/embedded)\) and lays the technological foundations for the companion Kibana plugin which is released in two versions: [ReadonlyREST PRO](https://readonlyrest.com/pro) and [ReadonlyREST Enterprise](https://readonlyrest.com/enterprise).

Unlike the Elasticsearch plugin, the Kibana plugins are commercial only. But rely on the Elasticsearch plugin in order to work.

For a description of the Kibana plugins, skip to the [dedicated documentation page](kibana/) instead.

### ReadonlyREST Free plugin for Elasticsearch

In this document we are going to describe how to operate the Elasticsearch plugin in all its features. Once installed, this plugin will greatly extend the Elasticsearch HTTP API \(port 9200\), adding numerous extra capabilities:

* **Encryption**: transform the Elasticsearch API from HTTP to HTTPS
* **Authentication**: require credentials
* **Authorization**: declare groups of users, permissions and partial access to indices.
* **Access control**: complex logic can be modeled using an ACL \(access control list\) written in YAML.

This file has been truncated. show original