There’s definetely something up at the config level AFAICT, because I’ve dug into the code at the release level, and can see that the thing returning the 404 code is that standard, built-in http proxy (as in we’re not doing anything fancy to the request).
Which means that TIB really does think it’s getting a 404 back, not a 200, even though the request is arriving.
Are these docker containers? Can you curl from within the TIB container to your IDP?
My TIB is not a docker container. I just follow the setup tutorial and start ./tib in my EC2 linux prompt.
My custom provider is running inside a container but as you say earlier, you succeed in calling it.
To Add: TIB is accessing the dashboard and getting a response (that 404 error is the returned body data), but if your install is bound to a specific domain/IP then localhost won’t trigger a response, you’ll need to target the hostname or the IP, whatever you’ve configured the dashboard for.
Ok, so I change the DashboardConfig section in /opt/tyk-identity-brocker-v0.1/tib.conf
I tried the public IP of the dashboard and also the private IP and I still have the 404.
If I make a curl to http://public_or_private_IP:3000 from the TIB I have the 404 not found error (but perhaps it’s an expeted error from a surl on that url?)
Is the admin secret important, because I did’nt change it. It still equal to 12345.
I can go on with the Tyk2.0 evaluation but I’d like to say that your reactivity and your help can have 6/5 stars
I wonder what could be the “enterprise” support of Tyk
Hope it’s ok to open up this old thread again. I understand that API client should call the TIB to obtain access_token but I’m not grokking how gateway verify the validity of the access_token. Does it go through TIB? Do we always call TIB? From your respond above, it seems like you have to call your gateway once you obtained the access token? Then how will it talk to the existing identity provider.
Depending on the setup, TIB will do a token exchange, it will trade the IDP token with a Tyk token using the gateway API, then give the end user the tyk token. The Tyk token is then checked for validity.
If this is OIDC, then you may want to leave TIB out altogether and just configure Tyk to use OIDC, then validity is checked against the IDP’s JWK set.
Thanks Martin. Basically what I’m trying to achieve is something described by this article:
I think what I’m confused is how in #1, the “External Party” pass can reach the “the Identity Providers”. It looks like the ‘Authenticate’ call will just be another API that is registered into tyk gateway of which request will be proxied to the Identity Providers. I do not believe when it is referring to TIB in particular, correct me if I’m wrong.
This article makes use of a pretty tight integration with Tyk, where the client will authorise against a third-party IDP (either via an open redirect through the gateway or a direct connection) but this intermediary actually generates a JWT and a token using the Tyk api, and the Tyk gateway then does header substitutions so the JWT doesn’t need to be sent but an api token.
TIB can donsomething similar, but you might need to modify it.