Need to understand Consumer -> Service / Routes relationship

Questions
1

I am trying to figure out how key-auth works? When a Consumer creates a an apikey it is stored in the keyauth_credentials table. When key-auth is applied to a service for instance, an entry is made in the plugins table with the service id.

I can only assume that when a request is processed, the apikey is extracted from the Header in this case and the apikey value is queried on keyauth_credentials table? If validated, then the request continues on its journey. Does this sound about right?

1 Like
2

Couple of Steps to consider:

Do you want your Route or Service to be able to be called by any Kong consumer with a valid Key or a specific consumer with a valid Key?

  1. If your answer was any consumer, all you need is a Key generated for the consumer and to enable key-auth plugin on the route/service itself. The key functionality from client perspective is flexible in that it can be passed via header or query parameter (I never recommend query parameters because that will always be insecure).

https://getkong.org/plugins/key-authentication/

  1. If your answer was a specific consumer you need to also consider the ACL plugin, which is the plugin that says even though they have a pair of credentials, they must be whitelisted as a user to be allowed to invoke this service. In which case you create a whitelist group when enabling the ACL plugin against your Route/Service. Then you must also add that same group to the consumer resource as well. This will take step 1 further to say not only does this consumer have a valid key, but they also have been authorized to call this specific service via ACL control groups.

https://getkong.org/plugins/acl/

-Jeremy

3

Randy,

Thank you so much for the concise answers. Currently there is only one consumer associated with an apikey. In the very near future we’d like to be able to assign a key on a per user basis or groups of users and we have something like 10k users. Our user ids are stored in a SQL Server database

Aside from an Authentication Service like LDAP, Gluu etc… Is there a Best Practice pattern for keeping consumers in Kong synced with a user database?

4

Ooo now that is a tricky one :slight_smile: . Can’t say honestly I have ran into a use case where I have had to keep Kong “consumer” resources synced with something that lives in a database externally. ONE way to do this since you are using user keys is as follows:

  1. Keep tabs on users in your external database, do reconcile logic to query to make sure user exists in Kong if they exist in your database. If they do not, create the consumer and assign them an API Key as well as the ACL whitelist group to the API they need access too programmatically with REST API calls. It may make sense in your external DB to make a new column called gateway-key or something of that sort where you even store the API Key with their record they will use on Kong for easy lookup in the future.

I don’t love that implementation because it sounds like you are building out external IDP that way, and there are lots of apps like keycloak https://www.keycloak.org/ to manage users for you and then OIDC Kong plugins that will let you focus on browser driven API access to data via some portal UI.

Hope my comments get the head gears turning :),
Thanks
-Jeremy