White/black listing on Key level (OSS)

Product FAQ
, ,
1

It is possible to white/black list on the API key level as in API definition json?

 "white_list": [....]
2

Do you mean IP address or endpoint allow / block list?

3

I mean in the key definition. It is possible to white/black list endpoints?
All I could find in the docs is “allowed_urls”. OK, this is kind a “white list”.

...
"access_rights": {
        "sample-service": {
            "api_name": "Sample service API",
            "api_id": "sample-service",
            "versions": [
                "Default"
            ],
            "allowed_urls": [
                {
                    "url": "/v1/info/(.*)",
                    "methods": [
                        "GET"
                    ]
                }
            ], ...
4

I mean in the key definition. It is possible to white/black list endpoints?

Yes

All I could find in the docs is “allowed_urls”. OK, this is kind a “white list”.

Does this work for your use case?

5

Where can I find examples for white/black listing in key definition?

6

I am not sure we do but I created one. I have added the links the below. There are two main thing to note when using the allowed_urls.

  1. The URLs or paths have to be defined in the API definition file in the extended_paths section. A simple track end point or do not track endpoint middleware will do the trick.
  2. It works as an allow list. If a path or URL is not included then it is marked as blocked or restricted from access

Sample Key Definition

Sample API definition

Hope it helps

7

Huh, not really…
API definition should stay simple and include all endpoints (don’t want 100+ endpoint explicitly defined in API definition).
On the Key definition level I want to limit the access to some endpoints.

E.g.
Hi access key xxxxx → access to all endpoints
Low access key yyyyyy → blocked access to let say: /admin/(.*), but allowed to all other

I see one way doing this with “allowed_urls” on API key definition to somehow “negate” regExp on the /admin endpoint.

8

Agreed. I didn’t understand the number of APIs involved and the full context. Were you able to get this solved?

9

Nope. Just white listing with “allowed_urls”, but for big APIs would be better to just black list few endpoints or resources under E.g. /admin/*.

10

I think you can achieve the same thing with regex as you say. With regex, you don’t have to add anything to the extended paths. I have a sample here that blocks anything with a sub path that starts with /echo. The regex syntax must be in go.

You would simply have to change the url field to be

^/<LISTEN-PATH>/([^a]|a[^d]|d[^m]|m[^i]|i[^n]|n).*

Let me know if it works for you