TIB Custom provider configuration - help

It’s a test so I don’t care if it’s public :slight_smile:

[{
“ActionType”: “GenerateOrLoginUserProfile”,
“ID”: “1”,
“OrgID”: “570b59228352270ae5000001”,
“ProviderConfig”: {
“CallbackBaseURL”: “http://127.0.0.1:3010”,
“FailureRedirect”: “http://127.0.0.1:3000/?fail=true”,
“UseProviders”: [{
“Key”: “YOUR-API-KEY”,
“Name”: “gplus”,
“Secret”: “YOUR-OAUTH-SECRET”
}]
},
“ProviderName”: “SocialProvider”,
“ReturnURL”: “http://127.0.0.1:3000/tap”,
“Type”: “redirect”
},
{
“ActionType”: “GenerateTemporaryAuthToken”,
“ID”: “2”,
“OrgID”: “570b59228352270ae5000001”,
“IdentityHandlerConfig”: {
“DashboardCredential”: “3d5a367eb9064eed4455c9fbf1075100”,
“DisableOneTokenPerAPI”: false,
“TokenAuth”: {
“BaseAPIID”: “1a188fa6b20d47d078450b1f2be26ff3”
}
},
“MatchedPolicyID”:“570d0c97835227162c000001”,
“ProviderConfig”: {
“ExrtactUserNameFromBasicAuthHeader”: false,
“OKCode”: 200,
“OKRegex”: “”,
“OKResponse”: “”,
“ResponseIsJson”: true,
“TargetHost”: “http://54.194.61.205:8888/auth”,
“UsernameField”: “user_name”
},
“ProviderName”: “ProxyProvider”,
“ReturnURL”: “”,
“Type”: “passthrough”
}]

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.

Here the content of my tib.conf (just in case) :

"Secret": "test-secret",
"HttpServerOptions": {
    "UseSSL": false,
    "CertFile": "./certs/server.pem",
    "KeyFile": "./certs/server.key"
},
    "BackEnd": {
            "Name": "in_memory",
    "ProfileBackendSettings": {},
            "IdentityBackendSettings": {
        "Hosts" : {
            "localhost": "6379"
        },
        "Password": "",
        "Database": 0,
        "EnableCluster": false,
        "MaxIdle": 1000,
        "MaxActive": 2000
    }
    },
    "TykAPISettings": {
    "GatewayConfig": {
        "Endpoint": "http://localhost",
        "Port": "8080",
        "AdminSecret": "54321"
    },
    "DashboardConfig": {
        "Endpoint": "http://localhost",
        "Port": "3000",
        "AdminSecret": "12345"
    }
}

}

And I also tried to curl my custom provider from the TIB EC2 VM

curl -X POST http://54.194.61.205:8888/auth

And it works fine relying : {“user_name”:“toto”} (http 200)

And you can curl the provider from the TIB box?

We need to track down this 404 basically.

If I curl my custom provider from the TIB EC2 VM

curl -X POST http://54.194.61.205:8888/auth

It works fine replying : {“user_name”:“toto”} (http 200)

Can you restart TIB?

I restart it. Always the :

INFO[0000] Tyk Identity Broker v0.1
INFO[0000] Copyright Martin Buhr 2016

INFO[0000] [MAIN] Initialising Profile Configuration Store
INFO[0000] [IN-MEMORY STORE] Initialised
INFO[0000] [MAIN] Initialising Identity Cache
INFO[0000] [REDIS STORE] Initialised
INFO[0000] [FILE LOADER] Loaded: 2 profiles from profiles.json
INFO[0000] [MAIN] Broker Listening on :3010
WARN[0015] [TYK ID HANDLER] No expiry found - defaulting to 3600 seconds
INFO[0015] [TYK ID HANDLER] Starting Token Flow…
WARN[0015] Response code was: 404
WARN[0015] GOT:404 page not found

ERRO[0015] [TYK ID HANDLER] --> Login failure. Request not allowed

Dammit. Figured it out - it’s not your handler, it’s the Tyk Dashboard URL:

(the error is defined i the tyk API Handler:

TIB can’t access that URL, I would suggest you use the same URL that you use to browse to the dash in the configuration file.

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.

Ok, It’s working!!!

I also modified the admin secret (with the RPC credential), and I have a response !!

{“key_id”:“570b59228352270ae5000001cb526aabffaa482e7509a7e39186f34e”}

HOURRA!!!

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 :slight_smile:
I wonder what could be the “enterprise” support of Tyk :slight_smile:

Thank you for your support and your time.

Fred

2 Likes

Just a little question : Where can I find the GatewayConfig.AdminSecret ? I need it here :

"TykAPISettings": { "GatewayConfig": { "Endpoint": "http://xxxxxx", "Port": "8080", "AdminSecret": "?????????" }

Thank you

This is the secret set in your tyk.conf:

(not the node secret, that’s specific to the node/dashboard heartbeat relationship)

Hi Martin,

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.

Thank you!

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.

M.

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.