Is there any security concern with having no org ids for keys or apis?

Product FAQ
, ,
1

I was wondering if there was any security concern for creating all keys and apis without an org id. My main reason for doing this is to get around the fact that Tyk automatically prepends the org id to a key when creating it via the admin api. I can see that there are reasons for doing this from the docs (Other Root Objects), but I want to disable this behavior.

The only way I can accomplish this is to not set an org id on the key, but then of course the apis would also need to have no org id set so the key could access those apis. If there’s another solution for disabling this default behavior, I’d love to know what that is. Thanks!

2

I might be wrong but I don’t think there is a way to disable the behaviour. I would have to check internally and get back to you.

As a workaround, I think you could use the Create Custom Key / Import Key

3

This issue actually first surfaced for us because we wanted to create some custom keys and Tyk still prepends the org id to that custom key. So creating a custom key returns with a response that shows the key was modified.

POST /tyk/keys/test_key
{
  "org_id": "1",
   ...
}

// Response: 200
{
  "key": "1test_key",
  "status": "ok",
  "action": "added",
  "key_hash": "b7a48f95"
}

And we get a 404 when trying to retrieve the key by our custom name, but not when we query it with the preceding 1

GET /tyk/keys/test_key

// Response: 404
{
  "status": "error",
  "message": "Key not found"
}`
4

Can you share your version and config settings?

5

We’re on tyk-gateway:v5.3.1

{
  "log_level": "info" ,
  "listen_port": 8080,
  "secret": "secret",
  "template_path": "/opt/tyk-gateway/templates",
  "tyk_js_path": "/opt/tyk-gateway/js/tyk.js",
  "middleware_path": "/opt/tyk-gateway/middleware",
  "use_db_app_configs": false,
  "app_path": "/opt/tyk-gateway/apps/*",
  "storage": {
    "type": "redis",
    "host": "redis",
    "port": 6379,
    "username": "",
    "password": "",
    "database": 0,
    "optimisation_max_idle": 2000,
    "optimisation_max_active": 4000
  },
  "enable_analytics": false,
  "analytics_config": {
    "type": "",
    "ignored_ips": []
  },
  "health_check": {
    "enable_health_checks": false,
    "health_check_value_timeouts": 60
  },
  "enable_non_transactional_rate_limiter": true,
  "enable_sentinel_rate_limiter": false,
  "enable_redis_rolling_limiter": false,
  "allow_master_keys": false,
  "policies": {
    "policy_source": "file",
    "policy_path": "/opt/tyk-gateway/policies/*"
  },
  "hash_keys": true,
  "enable_hashed_keys_listing": true,
  "close_connections": false,
  "http_server_options": {
    "enable_websockets": true
  },
  "allow_insecure_configs": true,
  "coprocess_options": {
    "enable_coprocess": true,
    "coprocess_grpc_server": ""
  },
  "enable_bundle_downloader": true,
  "bundle_base_url": "",
  "global_session_lifetime": 100,
  "force_global_session_lifetime": false,
  "max_idle_connections_per_host": 500,
  "enable_jsvm": true
}
6

Turns out the issue is with the hash_key_function. If you were to specify murmur32, murmur64, or murmur128 then you should get the correct value

{
...
  "hash_keys": true,
  "enable_hashed_keys_listing": true,
  "hash_key_function": "murmur64",
  "close_connections": false,
...
}
7

But this will hash the key, which obfuscates the original key name that I want to support. I want to be able to easily create and query for test_key without hashing and without the preceding org_id.

8

But this will hash the key, which obfuscates the original key name that I want to support

Not necessarily. You may observe that the value of the key field is simply a base64 encoding of the org_id, the specified key_id and the hashing algorithm

{"org":"1","id":"test_key","h":"murmur64"}

You can use the exact id specified as the value for your Auth header and it should still work.

I want to be able to easily create and query for test_key without hashing and without the preceding org_id.

Querying the key from Tyk is the stumbling block. I don’t see how you can retrieve the key definition without specifying a matching org_id in an encoded or decoded format. The API definitions and keys are scoped or tied to the organisation IDs specified.

The only other alternative is to use an empty org_id value or completely strip it from the API definition and the key definition.

I was wondering if there was any security concern for creating all keys and apis without an org id

So to answer your concern, there isn’t any security issue when you create all keys and APIs without an org_id as long as you disable master keys and manage the access control to the APIs appropriately.

Hope this helps

9

Okay, I believe that answers all of my questions and I’ll have to test whether this configuration will suit my needs. Thanks so much for the help, @Olu !

10

I’m running into the same issue here:

Are you saying that in the example above, passing “test_key” should still work? That has not been my experience.

11

Yes it should

I see the issue is being addressed in this topic. Can you let us know the feedback based on my colleagues reply.