Basic Authentication and API Keys

Support Installation and Deployment
1

Imported Google Group message. Original thread at: Redirecting to Google Groups Import Date: 2016-01-19 21:33:35 +0000.
Sender:Victor Franzonatto.
Date:Friday, 15 May 2015 23:15:34 UTC+1.

Hi,

I have the API:
[
{
“id”: “5556621ff6b73b0001000002”,
“name”: “Test API”,
“slug”: “test-api”,
“api_id”: “c793e0f762e7478e5f4df2b4cf6aa451”,
“org_id”: “55565e51f6b73b0001000001”,
“use_keyless”: false,
“use_oauth2”: false,
“oauth_meta”: {
“allowed_access_types”: [
],
“allowed_authorize_types”: [
],
“auth_login_redirect”: “”
},
“auth”: {
“use_param”: false,
“auth_header_name”: “Authorization”
},
“use_basic_auth”: true,
“notifications”: {
“shared_secret”: “”,
“oauth_on_keychange_url”: “”
},
“enable_signature_checking”: false,
“hmac_allowed_clock_skew”: -1,
“definition”: {
“location”: “header”,
“key”: “x-api-version”
},
“version_data”: {
“not_versioned”: true,
“versions”: {
“Default”: {
“name”: “Default”,
“expires”: “”,
“paths”: {
“ignored”: [
],
“white_list”: [
],
“black_list”: [
]
},
“use_extended_paths”: true,
“extended_paths”: {
“ignored”: [
],
“white_list”: [
],
“black_list”: [
],
“cache”: [
],
“transform”: [
],
“transform_headers”: [
]
}
}
}
},
“proxy”: {
“listen_path”: “/c793e0f762e7478e5f4df2b4cf6aa451/”,
“target_url”: “http://test-api:8080/”,
“strip_listen_path”: true
},
“custom_middleware”: {
“pre”: [
],
“post”: [
]
},
“cache_options”: {
“cache_timeout”: 60,
“enable_cache”: true,
“cache_all_safe_requests”: false,
“enable_upstream_cache_control”: false
},
“session_lifetime”: 0,
“active”: true,
“auth_provider”: {
“name”: “”,
“storage_engine”: “”,
“meta”: {
}
},
“session_provider”: {
“name”: “”,
“storage_engine”: “”,
“meta”: null
},
“event_handlers”: {
“events”: {
}
},
“enable_batch_request_support”: false,
“enable_ip_whitelisting”: false,
“allowed_ips”: [
],
“dont_set_quota_on_create”: false,
“expire_analytics_after”: 0
}
]

And i do the request:
POST /tyk/keys/55564c62a5ed9c0001000001a81a9484a24442ca72947822765b03c5 -d ’
{
“allowance”: 999,
“rate”: 1000,
“per”: 60,
“expires”: 0,
“quota_max”: -1,
“quota_renews”: 1406121006,
“quota_remaining”: 0,
“quota_renewal_rate”: 60,
“access_rights”: {
“c793e0f762e7478e5f4df2b4cf6aa451”: {
“api_name”: “Test API”,
“api_id”: “c793e0f762e7478e5f4df2b4cf6aa451”
}
},
“org_id”: “55565e51f6b73b0001000001”
}
’

Gateway log:
time=“2015-05-15T22:07:58Z” level=info msg=“New key added or updated.” key=“55564c62a5ed9c0001000001a81a9484a24442ca72947822765b03c5”

When I try to get the API Keys, none is returned:
GET tyk/keys/?api_id=c793e0f762e7478e5f4df2b4cf6aa451

Return:
{
“keys”:[
]
}

Any thoughts?

Thanks,
Victor.

2

Imported Google Group message.
Sender:Martin Buhr.
Date:Saturday, 16 May 2015 10:06:16 UTC+1.

Hi Victor,

There is a way around this, though it isn’t that well documented (it’s an integration case, the docs are still being written).

For users that want to have users pay for access, it is possible to set the “Redirect Key Requests” option, this will send the user to your desired URL with an added parameter: tyk_key_request_id.

On the page that you redirect the user to you can get their basic auth password or generate their HMAC secret, then call

GET /api/portal/key-request/{requestId}/approve

To approve the key, this request will also return the new API key, you can then use the REST API or the Advanced Management API to set the HMAC secret on the generated key.

If you wanted to create a basic auth key you’d actually need to add (not generate) a brand new one, since the requirements for basic auth are a user name and a password, however you could do this, again, with the Gateway REST API (see the basic aiuth object requirements here: https://tyk.io/v1.6/access-control/basic-auth/), it’s also possible with the advanced API (since the dashboard can do it), but I think the endpoint and parameters are slightly different - I can’t seem to find the docs at the moment, maybe because they are missing :wink:

With both the above cases, the only thing that could cause issues is then tying the key back to the developer, if you are using hashed keys, this could be very tricky - since you have the original representation and not the hashed one, which is stored in redis, and for security reasons it’s not possible to get the hashed representation so there is an impasse there. If you switch off hashed keys, then you can just replace the key generated by the key request with the raw key that is returned by the API in the developer record.

Or, obviously, we could just add support for Basic Auth.

Just saying there’s a way around it through orchestration :slight_smile:

The portal is very new, and it’s primary use case is for generating auth tokens, so HMAC and BA have just not been high on the priority list. It’s on our roadmap now, so should be finished soon enough.

Have a good weekend.

Cheers,
Martin

  • show quoted text -
3

Imported Google Group message.
Sender:Victor Franzonatto.
Date:Friday, 15 May 2015 23:27:38 UTC+1.

Hi,

Do you have hashed keys enabled in your tyk.conf and tyk_analytics.conf (this tends to be defaulted in docker configs)? If so, key lists won’t work since they are obfuscated. If you disable the option then new created keys are viewable and can be retrieved raw, but for security purposes they are hashed usually, which makes the key listing API irrelevant.

You can still retrieve and manipulate keys with the rest API- so long as you know the original key (this is why the dashboard had a key lookup instead of a list if this option is enabled)

Secondly the session object you are using to create the key doesn’t set the basic auth password for the key (see the docs here: https://tyk.io/v1.6/access-control/basic-auth/). You’ll need this for basic auth keys to work.

Thanks,
Martin

4

Imported Google Group message.
Sender:Martin Buhr.
Date:Saturday, 16 May 2015 01:34:58 UTC+1.

Hi,

Now I have tried with the same configuration used to httpbin, but with basic authentication.

I have requested an API Key as a registered Developer.

Then tried the httpbin endpoint.

The gateway logs:
time=“2015-05-16T00:30:26Z” level=warning msg=“Invalid key detected, not found in storage engine”
time=“2015-05-16T00:30:26Z” level=info msg=“Attempted access with non-existent user.” key=“55565e51f6b73b000100000155565e51f6b73b00010000017a44a9258fed4b534d684abee9c7aa58” origin=“172.17.0.62:57938” path="/41befe12702446836bfe181d58dab2de/get"

If I post: /tyk/keys/55565e51f6b73b00010000017a44a9258fed4b534d684abee9c7aa58 -d ‘{
“basic_auth_data”: {
“password”: “test”
}
}’

Gateway logs the same result after a new request on httpbin:
time=“2015-05-16T00:32:12Z” level=warning msg=“Invalid key detected, not found in storage engine”
time=“2015-05-16T00:32:12Z” level=info msg=“Attempted access with non-existent user.” key=“55565e51f6b73b000100000155565e51f6b73b00010000017a44a9258fed4b534d684abee9c7aa58” origin=“172.17.0.62:57992” path="/41befe12702446836bfe181d58dab2de/get"

  • show quoted text -
5

Imported Google Group message.
Sender:Victor Franzonatto.
Date:Saturday, 16 May 2015 09:28:38 UTC+1.

Hi,

Just realised this - the portal does not support HMAC or basic auth keys (yet) it only supports regular header-based access, the key templates it generates do not include the settings for those fields dynamically so they need to be added manually.

We’ll be adding this soon though.

If you create a key manually using the dashboard or the REST API all should work fine.

Should have seen this last night, but it was late… I’ll update the documentation to reflect this.

Cheers,
Martin

6

Imported Google Group message.
Sender:Martin Buhr.
Date:Saturday, 16 May 2015 17:28:59 UTC+1.

Hi Martin,

The basic auth worked \o/

Thanks again for all of your help!!!

Cheers,
Victor.

  • show quoted text -
7

Imported Google Group message.
Sender:Victor Franzonatto.
Date:Saturday, 16 May 2015 17:57:56 UTC+1.

Hi Victor,

Great to hear - one caveat is that if you want to edit that key, the key is stored like this in Tyk:

{org-id}{username}

so if I have cerated a basic auth user called ‘newtest’, to edit the key, you will need to go to the key lookup and search for something like this:

53ac07777cbb8c2d53000002newtest

Where the numbers that preceded the username are the ID of the organisation doing the requests.

This is because of how Tyk stores keys, they are all segmented by Org ID, this isn;t obvious with a hashed key set, but in non-hashed mode it makes it easy to segment keys by the organisation they belong to.

Thanks,
Martin

  • show quoted text -
8

Imported Google Group message.
Sender:Victor Franzonatto.
Date:Tuesday, 1 December 2015 10:49:07 UTC.

Is there going to be key generation with Basic Auth with the Dev Portal anytime soon?
Right now there is not much use for the portal site if you are using Basic Auth.

  • show quoted text -
9

Imported Google Group message.
Sender:Martin Buhr.
Date:Tuesday, 1 December 2015 11:02:45 UTC.

Hi Tarmo,

Q: Is there going to be key generation with Basic Auth with the Dev Portal anytime soon?
A: The portal generates BA usernames and passwords for policies that use Basic Auth as their primary access control method

Q: Right now there is not much use for the portal site if you are using Basic Auth.
A: The portal generates BA usernames and password for users if they enrol in an API that has BA enabled. The portal also works with standard access tokens, HMAC and OAuth (Basic Auth).

In the next version - Portal will also support HMAC and RSA pub/sub JWT validation.

Cheers,
Martin

10

Imported Google Group message.
Sender:Tarmo Janson.
Date:Tuesday, 1 December 2015 12:00:18 UTC.

Are the username and password sent to the developer and after that the password is inserted to redis?

I have an API with Basic Auth and after I approve the key request the password field in redis is empty.
When creating a policy there is only an option for HMAC but no way to set it as Basic Auth policy.

Will there be an option for the dev to insert his own username and password?

  • show quoted text -
11

Imported Google Group message.
Sender:Martin Buhr.
Date:Tuesday, 1 December 2015 12:16:26 UTC.

Hi Tarmo,

when creating your policy, you need the following:

To have an API that is configured to use Basic Auth as the access control method
Add this to a policy (all APis in the policy MUST se basic auth for access)
Create a catalog entry that links to this Policy

When a user enrolls for this policy, they should be given a username and password and the username should be placed in Tyk for them - they will not get an access token.

If they are getting an access token, then the API isn’t set to use Basic Auth.

I’d suggest to recreate these, not edit existing ones as there was a format change recently that made us abandon linking catalog entries to APIs directly, its all done via a policy now.

Thanks,
Martin

12

Imported Google Group message.
Sender:Tarmo Janson.
Date:Friday, 4 December 2015 09:37:58 UTC.

I have set a a new VM and went through the steps:
API that is configured to use Basic Auth as the access control method
Add this to a policy (all APis in the policy MUST se basic auth for access)
Create a catalog entry that links to this Policy
User requests a key
The key is approved
A key is generated with ID = orgID+sequence_of_numbers
We don’t have automatic emails set up so I don’t know what the user would recieve.
But for some reason the key doesn’t have a policy assigned to it nor a Basic Auth password.

Maybe it’s somehow connected with another issue:
When testing I noticed policy doesn’t overwrite the access settings. What happens:
Create key with or without policy
add policy if not set when creating
make a request with key
Policy is still set but the settings in the key have reverted to some defaults (Rate limits 1000 per 60 sec, Quota 100 every 1 month)
I can only make 100 requests no matter what is set in the policy

  • show quoted text -
13

Imported Google Group message.
Sender:Martin Buhr.
Date:Friday, 4 December 2015 10:06:06 UTC.

Hi Tarmo,

That’s quite odd. Because two things that seem a bit off here:

  1. When a Basic-Auth enabled policy-attached key request is approved, you get a string of numbers (this is the user name), not OrgID + string of numbers the string is the username (just tested this on Cloud, it is definitely the case)
  2. Selecting the username and going to key view and entering it (clicking “this is a username” results in a filled-in BA key
  3. If you have the full orgID + username (which is a bit weird, since that only happened in older versions), then to look it up you treat it like a regular key, not as a username

Also, when you look at the key (the way you last did), was there an error box on the right - if a key can’t be found, you still see the key view with defaults (you may have entered the long key and then clicked “this is a username” to find it, which would have failed)?

Can you tell me the version number of your dashboard (top right by the logo)?

As for the second issue - I’m not sure I follow, steps 1 and 2 are contradictory. I assume you create a key, then add a policy to a created key.

Is the policy live on the system?

Can you confirm how you’ve set up Tyk, and which version you are using?

Many thanks,
Martin

14

Imported Google Group message.
Sender:Tarmo Janson.
Date:Friday, 4 December 2015 11:01:57 UTC.

tyk - v1.8.3.2
dashboard - v0.9.6.5

We don’t have hashed keys enabled so the API key list shows the key which ID consists of orgID followed by a string of numbers. And I could view and edit it without any error. If I tick “This is a username…” (which is unticked at start) I can assign it a username and password (though the username doesn’t change anything since it uses the string of numbers as username).

  1. issue: in 2. step I mean’t “set policy (in the key)” instead of “add policy”
    The policy has already been created and is set active.

tyk.conf:
{
“listen_port”: 5000,
“secret”: “{secret}”,
“template_path”: “/etc/tyk/templates”,
“use_db_app_configs”: true,
“app_path”: “/etc/tyk/apps/”,
“tyk_js_path”: “/etc/tyk/js/tyk.js”,
“middleware_path”: “/etc/tyk/middleware”,
“storage”: {
“type”: “redis”,
“host”: “localhost”,
“port”: 6379,
“username”: “”,
“password”: “{redis_password}”
},
“enable_analytics”: true,
“analytics_config”: {
“type”: “mongo”,
“csv_dir”: “/tmp”,
“mongo_url”: “mongodb://127.0.0.1/tyk_analytics”,
“mongo_db_name”: “tyk_analytics”,
“mongo_collection”: “tyk_analytics”,
“purge_delay”: 10,
“ignored_ips”: []
},
“health_check”: {
“enable_health_checks”: true,
“health_check_value_timeouts”: 60
},
“optimisations_use_async_session_write”: true,
“allow_master_keys”: false,
“policies”: {
“policy_source”: “mongo”,
“policy_record_name”: “tyk_policies”
},
“hash_keys”: false,
“suppress_redis_signal_reload”: true
}

tyk_analytics.conf:
{
“listen_port”: 3000,
“tyk_api_config”: {
“Host”: “http://localhost”,
“Port”: “5000”,
“Secret”: “{secret}”
},
“mongo_url”: “mongodb://127.0.0.1/tyk_analytics”,
“page_size”: 10,
“redis_port”: 6379,
“redis_host”: “localhost”,
“redis_password”: “{redis_password}”,
“force_api_defaults”: true,
“notify_on_change”: true,
“hash_keys”: false
}

  • show quoted text -
15

Imported Google Group message.
Sender:Martin Buhr.
Date:Friday, 4 December 2015 11:19:07 UTC.

I have installed tyk through the tar files on github site.

On Friday, 4 December 2015 12:06:06 UTC+2, Martin Buhr wrote:

  • show quoted text -
16

Imported Google Group message.
Sender:Tarmo Janson.
Date:Friday, 4 December 2015 12:18:05 UTC.

Hi Tarmo,

I see, 0.9.6.5 had some problems with Basic Auth and the portal (I thought you were on the latest version), it didn’t work particularly well, in the version the basic auth was built in, but also introduced a change in how portal catalogue entries were set up.

This may be contributing to your issues.

I’d suggest updating to 1.9 and 0.9.7 as we’ve resolved BA in that version.

Though would suggest to recreate your portal entry and policy after the upgrade.

Cheers,
Martin

  • show quoted text -