From 59e1b487c2c20b5b0a32c2b10418ac217ab9c3fc Mon Sep 17 00:00:00 2001 From: FORESTIER Fabien <fabien.forestier@soprasteria.com> Date: Fri, 21 Jun 2019 16:56:21 +0200 Subject: [PATCH] Update images path --- docs/miscellaneous/authentication&authorization.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/miscellaneous/authentication&authorization.md b/docs/miscellaneous/authentication&authorization.md index f641c7f..fe50108 100644 --- a/docs/miscellaneous/authentication&authorization.md +++ b/docs/miscellaneous/authentication&authorization.md @@ -328,17 +328,17 @@ Each service that need to access protected endpoints will need to have its own k An API key is associated to a consumer, so the first step is to create a consumer that will represent the service. As a convention we decided to prefix the services related consumers by '__' which gives for example `__legacy-auth-middleware`. In the consumers section, we can create a new consumer and enter the username of our choice. - + Once the consumer is created, when clicking on its name, we can management its credentials, its groups and a couple more things. In the credentials section and under the API KEYS tab we can create new keys for this specific user. After clicking the create button, juste leave the key field empty if you want to let kong generate it for you. - + There we go, the service has its own API key! Now every time it needs to make a call to a restricted access endpoint, it will be able to pass along its identity using this key. Though, at this point kong does not know were to look for api keys. To remedy to that we need to configure a `key-auth` plugin. It can be specific to a service or a route but can also be global. Let's say we want a global plugin. In the plugin section, click the "add global plugins" button, and select `key-auth`. Then specify the name of the header where we will put the api key in key names. If you want this plugin blocking your request when you don't specify an api key you can add the id of your `ANONYMOUS` user. This means that when kong doesn't identify an existing user, it will transmit the request server with an `x-anonymous-consumer` header set to true. - + So now the service just need to pass a header `ApiKey:<the service api key>` when calling another service through kong to pass its identity. @@ -352,11 +352,11 @@ In the previous section we have seen how the identity of a user (or a service) i First thing first let's see how to add a group to a consumer. Find the consumer in the list and click on it to see the details. Navigate to the group section. Click the add group button and enter the name of the group. The consumer now belongs to group. This works fboth for user related consumers or service related consumers. - + Then, we need to configure an Access Control List plugin in order for kong to pass the user groups to the upstream. The ACL plugin needs an authentication plugin (JWT plugin, key-auth plugin...) to have indentified an existing user to then get its groups. Go to the global plugin section, click the add plugin button and select `Acl` under security. We don't really want to whitelist or blacklist user here we just want to propagate the user's groups to the upstream server. As the plugin require one of the two fields to be filled, we basically just enter a fake user id under blacklist. - + At this point if a service receive an authenticated request it will find the user/service's groups in the following header: `x-consumer-groups`. -- GitLab