Support for attaching API plugins to groups

Currently a plugin can be attached to either an API or a consumer for an API.

For APIs with a larger number of users it would be useful to be able to create a group concept that could be shared between plugins and ACLs.

For example this could be used to define rate limits by a group instead of either for the whole API or a consumer. Consider two groups Applications and Developers. The Applications group contains consumers for authorized applications and might have very high limits. The Developers group contains authorized Developers who would have low limits for development purposes only. Or your could have Premium vs Free groups. Names here are irrelevant and would be defined by the API for their needs.

Another extension for this would be a priority number attached to the plugin. So that if the consumer is in multiple groups then the first matching plugin with the highest policy would be used.

The general order of precedence for plugin selection would be consumer, plugin (by priority), api.

By implementing this as part of the core kong it could be used for all plugins. I looked at the effort to implement for a single plugin and it would require a lot of ugly hacks.

2 Likes

Hi,

This is definitely on our roadmap (and has been for a while). Stay tuned.

Hi, any update on this? I’m especially interested in applying rate-limiting to groups. ( When using a local strategy, if the number of nodes changes, it’s possible that every API consumer would have to be updated with a new local limit. :frowning: )

Thanks!

Hi! Is this still on your roadmap? It would come in very useful. I have a use-case that currently can be solved with a somewhat messy workaround, which is not without caveats: