Open/unrestricted subset of API

Support Installation and Deployment
4

Sorry I have misread your message. Will check and get back to you.
Thanks

5

Hi,
Let me verify my understanding - you want that certain paths will be ignored?
If so - on the API setup under the ‘Endpoint Designer’ tab you need to add the path you want and select ‘Ignore’ from the list.
For example I had created an api for http://petstore.swagger.io and added the following specific endpoint to be ignored:
/v2/pet/(.*)
The API itself needs to have authentication enabled under ‘Core Setting’.
For my little test I chose ‘Auth Token’ and when I request http://petstore.swagger.io I get -

{
“error”: “Authorization field missing”
}

but when I request _https://MY-COMPANY.cloud.tyk.io/sometimes-ignore-auth/v2/pet/9205436248879988764 I manage to get through.

Hope I understood you correctly this time.

1 Like
6

Thank you so much! I realize my original question was perhaps a little difficult to understand.

What you’ve described seems to do exactly what I’m looking to do. I did not realize the “ignore” filter/middleware meant authorization would be ignored. Now that I do, that’s an incredibly simple solution. Thank you very much!

7

Yep that’s a bypass.
If more questions arise, we are here.

8

I’ve been able to integrate Tyk into our platform, and achieve what I wanted using the “ignore” feature as far as authorization goes. But I have a follow-up question:

As far as I can tell, “ignore” will completely bypass all Tyk logic. This seems to mean that caching, rate limiting etc are also bypassed. Ideally I would like to keep caching active for the “ignored” paths. Is there any way to achieve this?

9

Basically, what I want to do is allow anonymous access to some methods/paths only, without bypassing all other Tyk logic, such as caching and rate limiting.

Any ideas?

10

Looking at the code if the endpoint is ignored then the middlewares won’t be able to be called so this is a bit of an all or nothing solutionat the moment i’m afraid.

11

Thank you @Josh,

Does that mean that there is no way to achieve what I’m looking for? I recognize that “ignoring” a path will bypass all logic, and that therefore it’s not a viable solution. However maybe thare are other features that could let me achieve anonymous (but cached) endpoints in an otherwise restricted API?

Here are some vague ideas based on my limited understanding of Tyk so far, that maybe could serve as some inspiration for you to suggest solutions. :slight_smile:

  • “Overlay” two separate API configurations, so that one only contains the anonymous endpoints, although I reckon there might be an issue with conflicting paths?
  • Create two separate API configurations at different base paths, but pointing to the same source service
  • Some sort of custom authentication middleware/plug-in to mark a request to certain paths as authorized even if it’s not? I’m struggling to understand the (very limited?) documentation on plug-ins.
  • Changes to the core code of Tyk, but where would I start?

I’m grateful for any suggestions! :slight_smile:

12

Hi,
Sorry, I guess we missed your reply.
To implement your flow I did the following:

  1. created closed api with a key (auth token for instance),
  2. Created a key for with access right to this api
  3. Test it. all good. move on
  4. Create another api with the api from step 1 as the upstream target and keyless!
  5. On the designer endpoint I with whitelist the endpoint path I would like to expose and add header Authorization and set the key as the value.

Does this help?

13

Thanks for getting back to me and sorry that I haven’t replied in a while. That’s an amazing workaround! I will try it as soon as I get a chance. :slight_smile:

1 Like
14

Hi,

I encounter exactly the same problem as @richardolsson. An API with some secure paths and some not.

With “Auth authoken” authentication, setting up the workaround is quite simple. On the other hand, when the API is secured through OIDC it requires a lot of effort:

  • create and sign a JWT token with a long life so that it doesn’t expire. Position a custom issuer into the token. This token is added in the Authorization header (point 5 of your workaround)
  • create a mock API to expose .well-known / openid-configuration urls and JWKS information
  • configure the workaround you described above

It works, but it’s very expensive.

Is it planned in the roadmap to support out of the box API with secure paths and some not ?

15

Hi,

Do you have some answers to provide?

I’m stuck in using Tyk because of that :frowning:

16

Hi,
Sorry we haven’t reply. I will find out.
Please feel free to open an issue about this on our GH repo and add link to this thread. This way you can track any updates on this issue.

17

Do you need custom middleware? Because if you don’t then you can set the insecure paths to be ignored and they will bypath auth altogether?

18

Hello!

So if summarize, what can be done to simplify this logic?

If we make “ignore” plugin respect cache, will it be enough?

In other words I really would love to see the way how you think it should work. Thank you!

19

@leon: Really what I’d like to do is have a sibling of ignore that doesn’t actually ignore the request fully, just ignores the auth. It should let the request pass unauthorized.

This way, an authenticated user 1 requesting /users/1 will get detailed information, and an unauthenticated user requesting /users/1 will just get the public information.

Right now, I have to choose between only allowing authenticated calls to /users/1, or making all requests to /users/1 anonymous (using the ignore filter). The fact that caching etc is disabled is a negative side-effect, but not the main issue for me.

Does this make sense?

20

It definitely make sense, but not sure what is the best way to achieve this.

You can try to configure 2 Tyk APIs, one open and second with auth. Public endpoint will point to your open API, and inside you will define URL rewrite rule which when authorization header is passed it will internally route to second protected api, and if no header, it will continue working with public API.

Or using small nginx layer which route traffic to different Tyk APIs depending on the header.

Does it makes sense?

21

It makes sense, but seems unnecessarily complicated for something I would expect to be fairly common.

Surely there must be many APIs that have endpoints that return public data when accessed anonymously, and private data when accessed while authenticated. So it would make even more sense to me for Tyk to support something like this.

But as long as it doesn’t, I understand the workarounds you are suggesting. Thanks!

22

Possible breakthrough! I just realized Tyk can have “multiple auth methods” for a single API. Using this feature, I seem to be able to configure my API to use two auth methods:

  1. OAuth 2.0
  2. Open (key-less)

This way, Tyk allows both the key-less and the key-bearing requests through to my API, while still providing the OAuth 2.0 management features. The issue however, is that even if the Authorization header is present, Tyk does not validate it or do anything else that require keys, e.g. rate limiting. It treats all requests as anonymous, and any logging will be tied to the 00000000 pseudy-key.

So it’s little better than using the ignore filter on all URLs.

Ideally, if the Authorization header is available, Tyk would validate it and extract the key from it before proxying, and if it’s not available it would just proxy it the way it does a keyless API. Maybe this is a more useful suggestion for development than the previously suggested per-path solution?

1 Like
23

Hey, I’m looking for the same solution.

I have optional authentication support in my API, which means, user may query API being authenticated and not.
Would be great if Tyk could validate the Authorization header if it exists, and proxy the call if not.

Any updates since the last post?