Access granularity

Support Setting up Tyk
1

Imported Google Group message. Original thread at: Redirecting to Google Groups Import Date: 2016-01-19 21:07:03 +0000.
Sender:Thorsten Zenker.
Date:Sunday, 1 February 2015 11:56:35 UTC.

Hi Martin & the Tyk.io team & community,

it is my understanding that the API access management
does not differentiate the access type.

It would be great to have something like this:
(taken from https://tyk.io/v1.4/rest-api/api-key-management/ )
{
“allowance”: 999,
“rate”: 1000,
“per”: 60,
“expires”: 0,
“quota_max”: -1,
“quota_renews”: 1406121006,
“quota_remaining”: 0,
“quota_renewal_rate”: 60,
“access_rights”: {
“234a71b4c2274e5a57610fe48cdedf40”: {
“api_name”: “Versioned API”,
“api_id”: “234a71b4c2274e5a57610fe48cdedf40”,

        "api_access_type": [ "GET", "PUT", "POST" ]
        or
        "api_access_type": [ "GET" ]
        "versions": [
            "v1"
        ]
    }
},
"org_id": "53ac07777cbb8c2d53000002"

}

The api_access_type would list the allowed REST access types.
With this additional feature one can create an access key with limited or enhanced rights.

Do you think this is useful and doable? My “Go programming” kung fu is not good enough to propose a patch.

Cheers
Thorsten

2

Imported Google Group message.
Sender:Thorsten Zenker.
Date:Sunday, 1 February 2015 17:02:13 UTC.

Thanks for the feedback.
Added an issue at github.

The workaround is a good idea.

Thanks!

3

Imported Google Group message.
Sender:Martin Buhr.
Date:Monday, 9 February 2015 17:23:12 UTC.

Hi Thorsen and Martin.

Maybe is more powerful an endpoint granularity. It would be possible to make different parts of an API for different users/groups/whatever.

In the same API definition:
deprecated/beta/stable endpoints
public/private
free/premium
Is it a crazy idea?

  • show quoted text -
4

Imported Google Group message.
Sender:Rodrigo Alfaro.
Date:Sunday, 1 February 2015 13:22:18 UTC.

Copying in the group, apologies if you get this twice…

Hi Thorsten,

Sounds like an interesting idea - never really thought about adding granular permissions, this would mean that globally certain methods are disallowed for that key on an API, for a single endpoint that would make sense, but what about multiple end points? We would need to make it check paths too - I think we could re-use the existing path matching functionality for this, will consider it. Could you raise a ticket in our GitHub repo about this?

For now (until something is in place), an alternative would be to create a read only version definition for your API and use the White-listed extended path settings to only allow certain access methods. Then granting access to that version for a key instead.

This would mean a developer would need to add a version header or parameter though.

You could also just create another API definition with no versioning (but a separate listen-path) so that no header is needed, and only give access to that. Tyk doesn’t need exclusive upstream APIs

Cheers,
Martin

  • show quoted text -

  • show quoted text -

–
You received this message because you are subscribed to the Google Groups “Tyk Community Support” group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion on the web, visit https://groups.google.com/d/msgid/tyk-community-support/6a4cab9d-0903-40ab-8e69-7f9b1b22777b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

5

Imported Google Group message.
Sender:Thorsten Zenker.
Date:Monday, 9 February 2015 17:38:51 UTC.

Hi Rodrigo,

It isn’t crazy at all.

We’ve actually tried to do this with the versioning options, you can set endpoint-level black/white/ignore lists as well as mock responses. So you could grant access to users pbaed on remium/etc access to different versions with different permissions.

The only thing here is that throttling is API-wide for a single access key. However, there’s nothing to say that separate throttlers are used for different endpoints, it’s just a carefully managed redis counter, making the counter path-specific is an option, though the user session data object would grow quite large, since that’s where the varibales would need to live :slight_smile:

Will consider it though.

Cheers,
Martin

  • show quoted text -
6

Imported Google Group message.
Sender:Martin Buhr.
Date:Wednesday, 25 February 2015 19:25:23 UTC.

Thank you for adding this into master.

Looked at the documentation and: this looks great

Super!

  • Thorsten
  • show quoted text -
7