My case is: All API KEY under an organization with same api access rights
Wanna create a new API KEY which inherit ALL access rights of its organization dynamically, so that no need to duplicate access_rights on every api key creation. Any hints ?
POST: 127.0.0.1:8080/tyk/keys/create
{
"allowance": 1000,
"rate": 1000,
"per": 60,
"expires": -1,
"quota_max": -1,
"quota_renews": 1406121006,
"quota_remaining": 0,
"quota_renewal_rate": 60,
"access_rights": {
// I don't want to put all API access rights of an Org on every key creation.
},
"org_id": "53ac07777cbb8c2d53000002",
"meta_data": {},
"oauth_client_id": "",
"oauth_keys": {},
"basic_auth_data": {
"password": "",
"hash_type": ""
},
"jwt_data": {
"secret": ""
},
"hmac_enabled": false,
"hmac_string": "",
"is_inactive": false,
"apply_policy_id": "",
"monitor": {
"trigger_limits": []
},
"tags": []
}
BTW, there are few typo on this Sample Request. e.g. oauth_keysoauth_client_id, apply_policy_id
If you have multiple Orgs, I’d say use a policy, and put a dummy / disabled API as the baseline into keys your are creating. Then you only need to manage the policy.
Yes, we strongly recommend that org_id’s are set on APIs, policies and keys, org ID’s basically group ownership of these obejcts, leaving them out could cause things to stop working (we’ve seen this with policies), not recommended
See above.
Tyk hashes keys, unless you have this switched off, listing keys will not work (by design). Also, the api_id param is not a filter, it is merely a specifier to identify the back-end to use (search the forum, this has been asked many times).
Yes, if you make the list keys GET request to the advanced API on an unhashed installation with a user that belongs to the org
No.
Orgs:
Lastly, orgs are there to organise API / Resource ownership domains, not clients, so you can have one org, owning Evernote and LinkedIn APIs and supply keys for both. Then use policies to determine paid or free access to either.
You would only use multiple orgs if you actually want to segregate APIs, keys and ownership from one another, i.e. you have multiple tenants. And ultimately, this only matters in the dashboard, not in the gateway, as the dash/advanced API is the only thing that really cares and filters based on these criteria, and those filters only work if org_ids are used.