Extending Tyk to pull users / api mappings from an alternate source

Support Installation and Deployment
1

Imported Google Group message. Original thread at: Redirecting to Google Groups Import Date: 2016-01-19 21:01:49 +0000.
Sender:Jonathan Court.
Date:Monday, 1 September 2014 23:43:36 UTC+1.

Hi,

I find myself excited by the potential of Tyk so I’m watching it closely - so far it looks excellent.

I have a couple of questions but it is entirely possible I’ve missed this in the documentation - or that I’ve missed the point entirely - so let me know if this is the case.

It seems to me that each user would map to a key in Tyk, then each API configuration would apply appropriate access control etc… via the access_rights section by listing the keys as necessary.

Is there a way to:
extract these access rights from an alternate datasource that - e.g. some db, or file (i.e. an extension point or similar…)?
roll-up these access rights into groups and roles - perhaps by generating a key for the role and propagating multiple keys for a user (being their own key, and a key for each role/group they’re in)?
extract and use information from an identity provider to adjust the target uri (e.g. append a userId to the target URI or add a query param after extracting the user id from the identity provider using the access token)?
alternatively, is there a way to write an extension that adds this functionality?
It feels remarkably like the role of an ESB or similar to provide these features and I don’t expect that’s the purpose of Tyk at all - so perhaps I am missing the point.

Regards,
Jon

2

Imported Google Group message.
Sender:Martin Buhr.
Date:Tuesday, 2 September 2014 09:17:59 UTC+1.

Hi Jonathan,

Thanks for the interest :slight_smile:

You’re partially right in how Tyk assigns access rights, access rights (permissions) are essentially provided at the key level, so when a key comes into Tyk via a request, Tyk will route the request to the appropriate API depending on the request path, then once it has identified the API, will check if the key (if it exists) has an access_rights entry for that particular API version.

With regards to your question though, with the current version of Tyk (1.1), there is no third-party identity provider support, however in the current master branch development version, there is the capability of adding new identity providers and session providers. In other words, the code is extensible enough now to allow varying providers to be provided so long as they can provide the data that Tyk needs to track the appropriate key.

With regards to role and group management, it was considered to put this in, in order to mass-assign access-rights to keys (and it should be trivial to do), however we opted instead to leave group and roll assignment to the integrator as we didn’t want to depend too much on external data sources to provide these rules. There is an argument for using a configuration file to do this (for stand-alone installs) and then extrapolate that to MongoDB (the same way that API Definitions are set up).

I’ll put it on the roadmap so we don’t lose track of the request.

Finally, with regards to modifying the outbound request, at the moment there is no post-processor for the outbound request, though it is very easy to build middleware for Tyk (simply implement the TykMiddlewareProvider interface), and since the request is passed through each layer of the midleware it would just be a matter of creating it and adding to the request chain. Currently this would need to be hard-coded into the chain in loadApps(), though we are looking into ways to make this more dynamic (as in have pre-built modules that can then be add into the chain as configuration parameters - shouldn’t be hard). However it is more than possible if you fancy building from source :slight_smile:

I would agree that an ESB would serve this purpose better as the various mime type handlers could inject data more effectively than just appending to a request paramater list (e.g. XML bodies or JSON bodies, transforming the object i well beyond the scope of something like Tyk).

Either way, two interesting things that need to be considered for the roadmap:
The ability to runtime-load middleware into the chain
Some kind of roll and group management via configuration file, this could override atomic values store in the key session data itself.
Hope that answers your question :slight_smile:

Cheers,
Martin

3

Imported Google Group message.
Sender:Jonathan Court.
Date:Tuesday, 2 September 2014 03:25:45 UTC+1.

partially covered in another question on this board https://groups.google.com/d/msg/tyk-community-support/jJslIrq4Iqs/DaqAXBeoCdQJ.

4

Imported Google Group message.
Sender:Jonathan Court.
Date:Tuesday, 2 September 2014 09:17:59 UTC+1.

Hi Jonathan,

Thanks for the interest :slight_smile:

You’re partially right in how Tyk assigns access rights, access rights (permissions) are essentially provided at the key level, so when a key comes into Tyk via a request, Tyk will route the request to the appropriate API depending on the request path, then once it has identified the API, will check if the key (if it exists) has an access_rights entry for that particular API version.

With regards to your question though, with the current version of Tyk (1.1), there is no third-party identity provider support, however in the current master branch development version, there is the capability of adding new identity providers and session providers. In other words, the code is extensible enough now to allow varying providers to be provided so long as they can provide the data that Tyk needs to track the appropriate key.

With regards to role and group management, it was considered to put this in, in order to mass-assign access-rights to keys (and it should be trivial to do), however we opted instead to leave group and roll assignment to the integrator as we didn’t want to depend too much on external data sources to provide these rules. There is an argument for using a configuration file to do this (for stand-alone installs) and then extrapolate that to MongoDB (the same way that API Definitions are set up).

I’ll put it on the roadmap so we don’t lose track of the request.

Finally, with regards to modifying the outbound request, at the moment there is no post-processor for the outbound request, though it is very easy to build middleware for Tyk (simply implement the TykMiddlewareProvider interface), and since the request is passed through each layer of the midleware it would just be a matter of creating it and adding to the request chain. Currently this would need to be hard-coded into the chain in loadApps(), though we are looking into ways to make this more dynamic (as in have pre-built modules that can then be add into the chain as configuration parameters - shouldn’t be hard). However it is more than possible if you fancy building from source :slight_smile:

I would agree that an ESB would serve this purpose better as the various mime type handlers could inject data more effectively than just appending to a request paramater list (e.g. XML bodies or JSON bodies, transforming the object i well beyond the scope of something like Tyk).

Either way, two interesting things that need to be considered for the roadmap:
The ability to runtime-load middleware into the chain
Some kind of roll and group management via configuration file, this could override atomic values store in the key session data itself.
Hope that answers your question :slight_smile:

Cheers,
Martin

5

Imported Google Group message.
Sender:Martin Buhr.
Date:Tuesday, 2 September 2014 23:32:42 UTC+1.

Thanks for taking the time Martin. It’s greatly appreciated.

It given me some things to think about for a bit.

Regards,
Jon