Restrict access to a Service or a Route by whitelisting or blacklisting consumers using arbitrary ACL group names. This plugin requires an authentication plugin to have been already enabled on the Service or Route.
Terminology
plugin
: a plugin executing actions inside IAM before or after a request has been proxied to the upstream API.Service
: the IAM entity representing an external upstream API or microservice.Route
: the IAM entity representing a way to map downstream requests to upstream services.upstream service
: this refers to your own API/service sitting behind IAM, to which client requests are forwarded.
Configuration
This plugin is compatible with requests with the following protocols:
http
https
This plugin is partially compatible with DB-less mode.
Consumers and ACLs can be created with declarative configuration. Admin API endpoints which do POST, PUT, PATCH or DELETE on ACLs will not work on DB-less mode.Enabling the plugin on a Service
With a database
Configure this plugin on a Service by making the following request:
$ curl -X POST http://localhost:8001/services/{service}/plugins \
--data "name=acl" \
--data "config.whitelist=group1" \
--data "config.whitelist=group2" \
--data "config.hide_groups_header=true"
Without a database
Configure this plugin on a Service by adding this section do your declarative configuration file:
plugins:
- name: acl
service: {service}
config:
whitelist:
- group1
- group2
hide_groups_header: true
In both cases, {service}
is the id
or name
of the Service that this plugin configuration will target.
Enabling the plugin on a Route
With a database
Configure this plugin on a Route with:
$ curl -X POST http://localhost:8001/routes/{route}/plugins \
--data "name=acl" \
--data "config.whitelist=group1" \
--data "config.whitelist=group2" \
--data "config.hide_groups_header=true"
Without a database
Configure this plugin on a Route by adding this section do your declarative configuration file:
plugins:
- name: acl
route: {route}
config:
whitelist:
- group1
- group2
hide_groups_header: true
In both cases, {route}
is the id
or name
of the Route that this plugin configuration will target.
Global plugins
- Using a database, all plugins can be configured using the
http://localhost:8001/plugins/
endpoint. - Without a database, all plugins can be configured via the
plugins:
entry on the declarative configuration file.
A plugin which is not associated to any Service, Route or Consumer (or API, if you are using an older version of IAM) is considered "global", and will be run on every request. Read the Plugin Reference and the Plugin Precedence sections for more information.
Parameters
Here's a list of all the parameters which can be used in this plugin's configuration:
form parameter | description |
---|---|
name | The name of the plugin to use, in this case acl |
service_id | The id of the Service which this plugin will target. |
route_id | The id of the Route which this plugin will target. |
enabled default value: true | Whether this plugin will be applied. |
config.whitelist
semi-optional |
Arbitrary group names that are allowed to consume the Service or Route. One of |
config.blacklist
semi-optional |
Arbitrary group names that are not allowed to consume the Service or Route. One of |
config.hide_groups_header
optional default value: false |
Flag which if enabled ( |
Note that the whitelist
and blacklist
models are mutually exclusive in their usage, as they provide complimentary approaches. That is, you cannot configure an ACL with both whitelist
and blacklist
configurations. An ACL with a whitelist
provides a positive security model, in which the configured groups are allowed access to the resources, and all others are inherently rejected. By contrast, a blacklist
configuration provides a negative security model, in which certain groups are explicitly denied access to the resource (and all others are inherently allowed).
Usage
In order to use this plugin, you need to properly have configured your Service or Route with an authentication plugin so that the plugin can identify who is the client Consumer making the request.
Associating Consumers
With a database
Once you have added an authentication plugin to a Service or a Route and you have created your Consumers, you can now associate a group to a Consumer using the following request:
$ curl -X POST http://localhost:8001/consumers/{consumer}/acls \
--data "group=group1"
consumer
: The id
or username
property of the Consumer entity to associate the credentials to.
form parameter | default | description |
---|---|---|
group |
The arbitrary group name to associate to the consumer. |
Without a database
You can create ACL objects via the acls:
entry in the declarative configuration file:
acls:
- consumer: { consumer }
group: group1
consumer
: Theid
orusername
property of the Consumer entity to associate the credentials to.group
: The arbitrary group name to associate to the consumer.
You can have more than one group associated to a consumer.
Upstream Headers
When a consumer has been validated, the plugin will append a X-Consumer-Groups
header to the request before proxying it to the upstream service, so that you can identify the groups associated with the consumer. The value of the header is a comma separated list of groups that belong to the consumer, like admin, pro_user
.
This header will not be injected in the request to the upstream service if the hide_groups_header
config flag is set to true
.
Paginate through the ACLs
You can retrieve all the ACLs for all Consumers using the following request:
$ curl -X GET http://localhost:8001/acls
{
"total": 3,
"data": [
{
"group": "foo-group",
"created_at": 1511391159000,
"id": "724d1be7-c39e-443d-bf36-41db17452c75",
"consumer": { "id": "89a41fef-3b40-4bb0-b5af-33da57a7ffcf" }
},
{
"group": "bar-group",
"created_at": 1511391162000,
"id": "0905f68e-fee3-4ecb-965c-fcf6912bf29e",
"consumer": { "id": "c0d92ba9-8306-482a-b60d-0cfdd2f0e880" }
},
{
"group": "baz-group",
"created_at": 1509814006000,
"id": "ff883d4b-aee7-45a8-a17b-8c074ba173bd",
"consumer": { "id": "c0d92ba9-8306-482a-b60d-0cfdd2f0e880" }
}
]
}
You can filter the list by consumer by using this other path:
$ curl -X GET http://localhost:8001/consumers/{username or id}/acls
{
"total": 1,
"data": [
{
"group": "bar-group",
"created_at": 1511391162000,
"id": "0905f68e-fee3-4ecb-965c-fcf6912bf29e",
"consumer": { "id": "c0d92ba9-8306-482a-b60d-0cfdd2f0e880" }
}
]
}
username or id
: The username or id of the consumer whose ACLs need to be listed
Retrieve the Consumer associated with an ACL
It is possible to retrieve a Consumer associated with an ACL using the following request:
curl -X GET http://localhost:8001/acls/{id}/consumer
{
"created_at":1507936639000,
"username":"foo",
"id":"c0d92ba9-8306-482a-b60d-0cfdd2f0e880"
}
id
: The id
property of the ACL for which to get the associated
Consumer.