Tyk's architecture vision

Support Installation and Deployment
1

Imported Google Group message. Original thread at: Redirecting to Google Groups Import Date: 2016-01-19 21:16:06 +0000.
Sender:Jeff Martin.
Date:Wednesday, 17 June 2015 23:30:51 UTC+1.

We are still evaluating API Gateway’s

We are trying to implement a microservices architecture but the impression i am getting is that Tyk wants to make completely new URL’s for different API’s where our goal is to unify REST services on disparate servers into 1 base URL.

are there any suggestions around this?

2

Imported Google Group message.
Sender:Martin Buhr.
Date:Thursday, 18 June 2015 08:50:45 UTC+1.

Hi Jeff,

Tyk is really quite flexible when it comes to how you want to configure your gateway. In your case it sounds like you would like to use Tyk in the “API Gateway pattern” sense instead of as a network software appliance (which is how it norally deployed).

The way Tyk works is that it uses something called a listen_path to route requests to the appropriate upstream API, so if you had a microservice architecture with three api’s (api1.someserver.com, api2.anotherserver.com and api3.yetanotherserver.com lets call them), then Tyk could be set up to proxy those three apis in a few ways, here’s a few scenarios:

Option 1 - Raw Gateway
Tyk Gateway application on it’s own - this means not using the host manager, and just letting tyk act as a proxy, assume tyk is running on tyk.mygateway.com, now out of the box it will do the following when you add those APIs to it’s configuration, for conveniences sake, we are asuming you are seting the listen_path manually and not letting it be set by the dashboard (which would assign a UUID):

http://tyk.mygateway.com/api1/* → api1.someserver.com/*
http://tyk.mygateway.com/api2/* → api2.anotherserver.com/*
http://tyk.mygateway.com/api3/* → YetAnotherServer.com is for sale | HugeDomains

Not the upstream API URL’s can be arbitrary, so long as the base path is correct.

This scenario suits your miscroservice architecture well, since the listen paths are configurable you can set up a nice unified URL structure for your whole API group as a whole. Remember that API policies and keys can grant access to multiple upsream APIs with global rate limits, so one key can now be granted access to all three APIs.

Option 2 - Use the host manager
The host manager in 1.6 is pretty powerful, all it does is create and destroy nginx configuration (server) blocks and manage an nginx process, so now you can do domain routing - for example if you have many APIs and want to expose them seperately - the server blocks provide a way to map subdomains or directory locations to upstream, this is what Tyk does by default if you use the docker script, it would manage the above using api_slug values (the listen path here is set to a UUID to ensure there are no routing conflicts), the route now would look like:

http://api.domain.com/* → http://tyk.mygateway.com/api1/* → api1.someserver.com/*
http://api2.domain.com/* → http://tyk.mygateway.com/api2/* → api2.anotherserver.com/*
http://api3.domain.com/* → http://tyk.mygateway.com/api3/* → YetAnotherServer.com is for sale | HugeDomains

This may seem really arbitrary, but the thing is we do not want the Tyk gateway to be a web server, and think that routing, url rewrites, etc. should be left to bits of software that do it better than we would, hence the host manager being slaved to NginX.

This scenario is what you are describing, and is what the quickstart will set up as (it’s an all inclusive demo after all) but now there is a third way which is coming in 1.7 and is used by Tyk Cloud for it’s routing (mainly because wildcard SSL certificates for subdomains of subdomains are almost impossible):

Option 3 - (v1.7)
Here the host manager has been upgraded to allow per-organisation API server block manipulation, as in, instead of having one-server-block-per-api, we actually have one-server-block-per-organisation, and now you can have something like this:

http://api.organisation-name.domain.com/api1/* → http://tyk.mygateway.com/api1/* → api1.someserver.com/*
http://api.organisation-name.api.domain.com/api2/* → http://tyk.mygateway.com/api2/* → api2.anotherserver.com/*
http://api.organisation-name.api.domain.com/ais3/* → http://tyk.mygateway.com/api3/* → YetAnotherServer.com is for sale | HugeDomains

The real power here comes from being able to manage many organisations (and their respecitve APIs) with a single installation, and since the nginx blocks are actually just templates that use the go tempalte syntax, they are entirely configurable to whatever set up your company has.

We’ve tried to make sure that Tyk is as a whole really flexible, and with a bit of grit almost any kind of set up can be achieved, and with the upgrade to the host manager I just described, it becomes even more powerul.

I hoep that answers the question :slight_smile:

Thanks,
Martin

  • show quoted text -
3

Imported Google Group message.
Sender:Jeff Martin.
Date:Thursday, 18 June 2015 16:58:49 UTC+1.

wow- thanks for thorough description - would be great to see this in the documentation. (btw - on that topic do you know there are 4 different pages in your 1.6 docs under setup and configuration that have “QuickStart” in the name? )

4

Imported Google Group message.
Sender:Martin Buhr.
Date:Thursday, 18 June 2015 17:00:29 UTC+1.

Hi Jess,

Yeah - there’s the quickstart with Docker, quickstart with Vagrant and … another quickstart… Might clean that up in the next version release!

Thanks,
Martin

On Thursday, June 18, 2015 at 4:58:49 PM UTC+1, Jeff Martin wrote:
wow- thanks for thorough description - would be great to see this in the documentation. (btw - on that topic do you know there are 4 different pages in your 1.6 docs under setup and configuration that have “QuickStart” in the name? )

5

Imported Google Group message.
Sender:Jeff Martin.
Date:Thursday, 18 June 2015 18:53:44 UTC+1.

Does Tyk have a way of passing authentication information to a service?

  • show quoted text -
6

Imported Google Group message.
Sender:Martin Buhr.
Date:Thursday, 18 June 2015 18:59:27 UTC+1.

Hi Jeff,
I’m not sure I follow - do you mean to authenticate itself (validate origin)? Or from within the inbound request?
Thanks,
Martin

7

Imported Google Group message.
Sender:Jeff Martin.
Date:Thursday, 18 June 2015 21:48:28 UTC+1.

i guess i mean - that tyke could authenticate and then send information about the authenticated account in someway-

i’m sure there are some web-standards around this sort of thing. some of our services will need not just authorize the person but validate they are the right account - - so if there was an GET /account for instance - i’d want to know which account authenticated before providing that account information. (through a header or whatever)

even if the service was /account/{your-account-number} - i’d want to be sure the account requesting that number is the only ones that get access to that id.

since the gateway is controlling the keys and such - it has that authentication… is there a way to pass that information to my services?

  • show quoted text -
8

Imported Google Group message.
Sender:Jeff Martin.
Date:Thursday, 18 June 2015 22:09:02 UTC+1.

i guess i’m talking about Oauth…

  • show quoted text -
9

Imported Google Group message.
Sender:Martin Buhr.
Date:Thursday, 18 June 2015 22:16:29 UTC+1.

OAuth fits the bill :slight_smile:

Tyk authorises, it doesn’t authenticate. All Tyk will do is check if a key is authorised to access a listed resource (I.e the key exists, is active and has the correct permissions), it can’t validate that the key holder is the account holder.

Tyk can handle keys in two ways, you can either generate a key (recommended) or add a key (as in set the name of the key). So if you have your own key system - you can mirror them in Tyk using its API. This keeps the two key databases in sync and will cover off your authentication scenario as keys are managed and published to Tyk by a system you control.

If you generate a key, you may need a key map (Tyk key mapped to authorised account identifier). Tyk has pre- and post- processing custom middleware plugin capability (JavaScript) where you could check if the auth key returns an account ID and insert that as a header for your micro service to process and validate.

To get an idea of our middleware check it our blog - there’s an article on how to create an IP based rate limiter using our middleware capability.

So essentially you could pre-validate a key, but it could add latency.

ultimately for an authentication scenario you will need your own Tyk key to Internal key mapping, it’s unavoidable when externalising API key management to another source. You can either do it in your own app, or via another micro service that is queries across your infrastructure to map keys to accounts.

Either way, there is quite a lot of capability in place to help out with these requirements. If you’ve seen an alternative way of doing it elsewhere let us know, happy to put it in the roadmap as this is a common problem.

Obviously you could implement OAuth (as you just said), which takes care of authentication before a token is created. Tyk has support for full OAuth 2.0 flows, there’s docs on the site about it - tricky (OAuth always is) but totally possible.

There’s also SAML and JWT, but those aren’t supported by Tyk yet.

Many options :slight_smile: however I don’t think there’s a way to handle this kind of thing without some integration work :-/

Cheers,
Martin