Key management

MrImport · January 19, 2016, 9:24pm

Imported Google Group message. Original thread at: Redirecting to Google Groups Import Date: 2016-01-19 21:24:29 +0000.
Sender:Ian Harris.
Date:Thursday, 17 September 2015 15:16:55 UTC+1.

Hi,

I’m trying to manage keys for an API using the advanced management API. I am unable to list keys using the API

GET /api/apis/my_api_id/keys/ HTTP/1.1
User-Agent: curl/7.41.0
Host: XXX.XXX.XXX.XXX:3000
Accept: /
authorization: access_key_for_organisation_user

I just get an empty list returned.

{“data”:{“keys”:},“pages”:0}

But if I request a particular key I can get it returned.

GET /api/apis/my_api_id/keys/my_key_id HTTP/1.1
User-Agent: curl/7.41.0
Host: XXX.XXX.XXX.XXX:3000
Accept: /
authorization: access_key_for_organisation_user

{
“api_model”:{

},  
"key_id":"my_key_id",
"data":{
    "last_check":0,
    "allowance":999,
    "rate":1000,
    "per":60,
    "expires":0,
    "quota_max":10000,
    "quota_renews":1445012996,
    "quota_remaining":9999,
    "quota_renewal_rate":2520000,
    "access_rights":{
        "my_api_id":{
            "api_name":"Test API",
            "api_id":"my_api_id",
            "versions":["Default"],
            "allowed_urls":null
        }   
    },  
    "org_id":"my_org_id",
    "oauth_client_id":"",
    "basic_auth_data":{
        "password":""
    },  
    "hmac_enabled":false,
    "hmac_string":"",
    "is_inactive":false,
    "apply_policy_id":"",
    "monitor":{
        "trigger_limits":null
    },  
    "meta_data":null,
    "tags":null
}

}

Also if I create a portal developer how do I add a key to it? The syntax seems to be:

“api_keys”: {
“my_key_id”:“90568dfa”
}

What is the value in the “my_key_id” name:value pair?

Thanks,
Ian.

MrImport · January 19, 2016, 9:24pm

Imported Google Group message.
Sender:Martin Buhr.
Date:Thursday, 17 September 2015 15:30:53 UTC+1.

Hi Ian,

If you want to list keys you will need to switch your configuration to not use hashed keys (they are encrypted by default so they can’t be easily compromised if your Redis DB is compromised).

You can turn this off in the Tyk.conf and tyk_analytics.conf files.

Existing keys won’t work if you switch.

To add keys to devs you need to use the key request api:

Generate a key request to map against a policy ID (https://tyk.io/advanced-api-v0-9/key-requests/)
Approve that request with the API

The key will then be generated and returned to the api caller and to the user via email if the mandrill integration is active.

The key will also be attached to the developer

In hashed mode, the raw key will be given to the caller and the user via email, and then encrypted forever. All references to the key from here on out are the hashed version.

You can manage keys by developer (including policy changes and key deletion) using the hashed representation using a limited API.

If you know the original key, you can use the key search to edit it in the Tyk cluster.

Let me know if none of that makes sense :-/

Cheers,
Martin

MrImport · January 19, 2016, 9:24pm

Imported Google Group message.
Sender:Martin Buhr.
Date:Thursday, 17 September 2015 15:44:05 UTC+1.

One last thing - in the developer record, the key idnis a map of the policy of this user is subscribed to, so:

policy_id:hashed_key

I wouldn’t recommend editing this, instead use the Apis provided to handle Dev keys instead…

Cheers,
Martin

MrImport · January 19, 2016, 9:24pm

Imported Google Group message.
Sender:Ian Harris.
Date:Thursday, 17 September 2015 15:54:26 UTC+1.

Hi Martin,

That all makes sense.

One more quick question. How do I configure a policy? Or in this case is the policy just the access control object passed with the create key request?

i.e. POST /api/keys/

is the for_plan attribute in a create key request a key id from this api?

Thanks,
Ian.

show quoted text -

MrImport · January 19, 2016, 9:24pm

Imported Google Group message.
Sender:Martin Buhr.
Date:Thursday, 17 September 2015 16:33:48 UTC+1.

Hi Ian,

Policies are configured using the dashboard GUI normally, there’s an API for it, but I just realised we didn’t document it in the advanced API Section (doh!), here’s the gist:

POST http://tyk.docker:3000/api/portal/policies
Content-Type:application/json
authorization:xxx-xxx-xxx-xxxx

{
“last_check”: 0,
“allowance”: 0,
“rate”: 100,
“per”: 1,
“expires”: 1442503175,
“quota_max”: 10000,
“quota_renews”: 1442549941,
“quota_remaining”: 0,
“quota_renewal_rate”: 46800,
“access_rights”: {
“b605a6f03cc14f8b74665452c263bf19”: {
“api_id”: “b605a6f03cc14f8b74665452c263bf19”,
“api_name”: “Tyk Test API”,
“versions”: [
“Default”
]
},
“ba46f3278e734f6863b4ae84bf460f06”: {
“api_id”: “ba46f3278e734f6863b4ae84bf460f06”,
“api_name”: “Stream”,
“versions”: [
“Default”
]
}
},
“name”: “Limited Policy”,
“is_inactive”: false,
“hmac_enabled”: false,
“tags”: [
“trial-users”
]
}

{“Status”:“OK”,“Message”:“55fada0830c55e27f7000002”,“Meta”:“”}

That value returned is the policy ID, you can embed that in a token or a key request (for_plan) object depending on if you are using the developer subsystem.

Policies are actually explained in the Core API here: https://tyk.io/v1.8/quotas-limits-security/policies/ (that’s where all the detail is to be honest)…

They are very very similar to regular key objects and act as an override for those keys. What happens here is:
A developer requests a key
This creates a key request (a key request is generated from the information in the portal catalogue entry, it basically combines some metadata and a policy ID)
The key request combines the developer ID and the policy ID they want access to
If approved, Tyk will generate a token with the policy values, AND link the policy to the token. It then puts the key record alongside the developer so that now the token has some kind of organisational and developer identity metadata.
Policies override the core token values when the key shows up in the traffic flow, so if you update a policy, ALL keys that are attached to it will adopt those new settings instantly, it’s a good way to manage swathes of keys and create tiered access (e.g. trial, pro, enterprise access etc.)
Policies don’t overwrite existing quota usage (so if a key has used 100 out of 110 requests, that 100 usage will still count, if you lower the policy value or increase it, the maimums will change, so it’s safe to change them.

If you make a policy inactive it no longer will be loaded by the Tyk cluster (they are held in memory to avoid having to call back to the DB)

If you wish to stop access to all keys using a policy (e.g. if you have company- or client- based policies) then if you set the deny_access parameter on the policy, all tokens that use that key will top having access to your systems and be blocked, great if they have an outstanding bill

I’m going to add a note to document this in our official docs…

Hope that helps…

Cheers,
Martin

MrImport · January 19, 2016, 9:24pm

Imported Google Group message.
Sender:Ian Harris.
Date:Friday, 18 September 2015 09:20:23 UTC+1.

Hi Martin,

Thanks for that. That does indeed help. I think I’ve everything I need to code up my key management now

Thanks again,
Ian.

On Thursday, September 17, 2015 at 3:16:55 PM UTC+1, Ian Harris wrote:

show quoted text -