TIB Custom provider configuration - help

Hi,
I need to adapt this example of profile in Tyk Identity Brocker :
{ "ActionType": "GenerateTemporaryAuthToken", "ID": "8", "IdentityHandlerConfig": { "DashboardCredential": "{DASHBOARD-API-ID}", "DisableOneTokenPerAPI": false, "TokenAuth": { "BaseAPIID": "{API-ID}" } }, "MatchedPolicyID": "5654566b30c55e3904000003", "OrgID": "53ac07777cbb8c2d53000002", "ProviderConfig": { "AccessTokenField": "access_token", "ExrtactUserNameFromBasicAuthHeader": false, "OKCode": 200, "OKRegex": "", "OKResponse": "", "ResponseIsJson": true, "TargetHost": "http://{TARGET-HOSTNAME}:{PORT}/", "UsernameField": "user_name" }, "ProviderName": "ProxyProvider", "ReturnURL": "", "Type": "passthrough" }

I need a custom provider to handle my legacy basic auth (against SQL Server user database).
1-Where do I find my {DASHBOARD-API-ID} ?
2-Can I remove MatchedPolicyID (I don’t need it for the moment)
3-Where do I find my OrgID ?
4-What’s the meaning of “AccessTokenField”: “access_token” ?
5-What’s the meaning of “UsernameField”: “user_name” ?

I have request headers like this :
Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Do I need to modify something in the ProviderConfig section to handle this?

Thank you for your precious help

Fred

Go to your dashboard, select APIs, in the list of APIs, there are five columns: API Name, API ID, Target, Status and Manage - it’s the column named API ID.

Not recommended as it will form the basis of the auth rights your temporary token will have, suggest you create a policy and it’s ID here. You get the Policy ID when it gets created.

Users → Select your user it’s the one marked RPC Credentials

You are using the proxy provider, it is clever enough to try and extract data out of a JSON response about the identity of the user, if ResponseIsJson is true, and you are providing an access token (like OAuth) in your response, then you can set the JSON field to extract it rom here.

Same as 4 - if you want to retain some semblance of the identity that has been proxied / handled by TIB, then this field will tell TIB, if the response is JSON, where to get a user name from - these values are embedded as meta data into the session object attached to the temporary that gets spat out the other end.

No, the proxy handler acts as a MITM, so it just validates the response from your auth provider and then bridges to Tyk

Ok for the “API ID” field so I don’t understand what is the difference between DASHBOARD-API-ID and API-ID in the above snippet. It is the same ID?

Ah, my bad, that’s your dashboard API token (also under your username), looks like a typo in the docs.

I have similar issue as defined by fmeriot.

However, I get an error when I try to configure similar proxy. In my dashboard I get error:

Error
TIB: Request failed.

And the tib console output is:

ERRO[0165] [API] Authorization failed: Header mismatch

@arana3 :
Do you have modified your dashboard tyk_analytics.conf (in /opt/tyk-dashboard/) ?

"identity_broker": { "enabled": true, "host": { "connection_string": "http://127.0.0.1:3010", "secret": "test-secret" } }

I had the same error message in my dashboard, and this solved it.

1 Like

@Martin : I have modified my profiles.json, everything seems ok in it :

{ "ActionType": "GenerateTemporaryAuthToken", "ID": "2", "OrgID": "570b59228352270ae5000001", "IdentityHandlerConfig": { "DashboardCredential": "3d5a367eb9064eed4455c9fbf1075100", "DisableOneTokenPerAPI": false, "TokenAuth": { "BaseAPIID": "1a188fa6b20d47d078450b1f2be26ff3" } }, "MatchedPolicyID":"570d0c97835227162c000001", "ProviderConfig": { "AccessTokenField": "access_token", "ExrtactUserNameFromBasicAuthHeader": false, "OKCode": 200, "OKRegex": "", "OKResponse": "", "ResponseIsJson": true, "TargetHost": "http://54.194.61.205:8888", "UsernameField": "user_name" }, "ProviderName": "ProxyProvider", "ReturnURL": "", "Type": "passthrough" }

But when I try to call my API (the one with the ID 1a188fa6b20d47d078450b1f2be26ff3), I have a 401 or 403 (depending on the authentication mode I choosed in my API configuration). My TargetHost does not seem to be called (it is just a nodejs endpoint which reply http 200 ok).

I was wondering which authentication mode I need to apply in my API. I tried Basic Auth au Auth Token but it has no effect : My third party nodejs endpoint does not seem to be called.

Thank you for your help (sorry for all these boring questions ^^)

Tyk won’t call your target host if the key is invalid, it will block the traffic before it gets there.

The way you use TIB with Tyk is:

  • TIB handles some kind of authentication transaction for you, so lets say your targetHost here: http://54.194.61.205:8888 is a login form that takes a POST request with a username and password url-encoded form and authenticates against some legacy Lotus DB
  • In this case, TIB proxies this POST request to your target and captures the response (essentially it mimics someone logging into the html form on targethost)
  • If TIB detects a 200OK response, in this case, it will call Tyk API Gateway, and generate an auth token
  • Since there’s no return URL, it will just output a JSON object with a token
  • You can now use this token to access the API with ID 1a188fa6b20d47d078450b1f2be26ff3, if the token is valid and the policy allows access to this API ID, then your upstream host will be called

The API with ID 1a188fa6b20d47d078450b1f2be26ff3 and TargetHost are two different systems, all TIB is doing is offering an entrypoint to get a token somehow and tries to do this transparently.

So, just to confirm your usage flow:

  1. You send your authentication request to http://{your-tib-host}:{tib-port}/auth/{profile-id}/proxy/
  2. TIB spits out an API token as a JSON object (no return URL)
  3. You then use this token to access: http://{your-tyk-host}:{port}/{listen-path}/{resource} for the API 1a188fa6b20d47d078450b1f2be26ff3
  4. Tyk replies with an access denied message and status code 401 or 403

If the above is true, then there’s a problem with the policy being applied (the gateway will be spitting out an error about the token) - if you go into Tyk Dashboard and view the token (Keys → enter token → Lookup key), then you will see the access permissions that have been copied into the token by the policy on access.

If your flow isn’t as described above, then I think you’re using TIB wrongly :slight_smile:

For your actual API Definition and this TIB mode, you will want standard access tokens

Ok, I was totally mistaken. I thought that TIB would work like the Amazon Custom Authorizer of the API Gateway.

I thought this flow :

  • I call my API through the Tyk gateway with Authorization: Basic xxxxx header
  • Tyk gateway detect that for this API there is a TIB Profile associated and call the Target Host
  • Target host treats the Basic Header and return a 200 or 401 response to the tyk gateway.

This is a behavior that we can find in the Custom Authorizer of API Gateway : the header values are sent to a Lambda expression which return a Policy (grant or deny).

Ok, so if I understand what you explain, I need to call my TIB endpoint first (to ask an access token). Then, TIB call my custom provider, wait for an OK response and generate an access token that I can use to call my API. The lifetime of this token is determined by the policy I specified in the MatchedPolicyID property.

It a bit clearer now ^^

Yup that should work - though to expire the token, you need to add an Expires field into your profile with an epoch value, so:

{
	...
	"IdentityHandlerConfig": {
		...
		"TokenAuth": {
			"BaseAPIID": "1a188fa6b20d47d078450b1f2be26ff3",
                        "Expires": 1460549190
		}
	},
	...
}

I think that the trial expiry policy feature only applies to tokens generated via our portal.

Hi,
It’s almost fine.

Now I’am calling http://{your-tib-host}:{tib-port}/auth/{profile-id}/proxy/ posting some json data. TIB foward this json payload to my custom provider which reply a dummy json response like this

{
“user_name”: “toto”,
“access_token”: “123456789”
}

But my tib response is always :

HTTP 200 OK
Content-Length: 12
Content-Type: text/plain; charset=utf-8
Date: Thu, 14 Apr 2016 09:00:31 GMT

Login failed

I feel I’am not far from succeed, but I can’t see what’s wrong :)))

Right, TIB is sending the response and you’re getting something back - now TIB needs to evaluate your response - lets take a look at your profile again?

Also what response code does the dummy handler respond to TIB with (if any)?

Here is my profile :

=======================================================
{
“ActionType”: “GenerateTemporaryAuthToken”,
“ID”: “2”,
“OrgID”: “570b59228352270ae5000001”,
“IdentityHandlerConfig”: {
“DashboardCredential”: “3d5a367eb9064eed4455c9fbf1075100”,
“DisableOneTokenPerAPI”: false,
“TokenAuth”: {
“BaseAPIID”: “1a188fa6b20d47d078450b1f2be26ff3”
}
},
“MatchedPolicyID”:“570d0c97835227162c000001”,
“ProviderConfig”: {
“AccessTokenField”: “access_token”,
“ExrtactUserNameFromBasicAuthHeader”: false,
“OKCode”: 200,
“OKRegex”: “”,
“OKResponse”: “”,
“ResponseIsJson”: true,
“TargetHost”: “http:/my_custom_idp:port/auth”,
“UsernameField”: “user_name”
},
“ProviderName”: “ProxyProvider”,
“ReturnURL”: “”,
“Type”: “passthrough”
}

=======================================================

My custom IDP is running in a Docker container and I can see what requests are coming in live. So I can see requests that are forwarded from my Tyk Identity Broker.

This custom IDP always replies the same JSON response :

{“user_name”:“toto”, “access_token”:“123456789”}

I also tried to just respond a HTTP 200 without any payload, but my TIB server always send me back a :

HTTP 200 OK
Content-Length: 12
Content-Type: text/plain; charset=utf-8
Date: Thu, 14 Apr 2016 09:00:31 GMT

Login failed

Thank you again ^^

It looks ok, but since you don;t provisde an access token, you might want to clear this bit:

Is TIB outputting anything to stderr / log?

I have this in TIB log :

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[0005] [TYK ID HANDLER] No expiry found - defaulting to 3600 seconds
INFO[0005] [TYK ID HANDLER] Starting Token Flow…
WARN[0005] Response code was: 404
WARN[0005] GOT:404 page not found

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

I do not understand the “404” because I see the request coming from TIB in my provider, and my provider reply a 200.

There it is… TIB is getting a 404 when calling your endpoint, not a 200

Id your URL absolutely correct?

Yes, I think.
You can try it :

http://54.194.61.205:8888/auth

You can call it in GET or POST

Ok, so I just tried this out locally (replacing values in my handler) and I got a key back. So your configuration works ok.

Can you try removing the slash from your call (it 404’ed on mine), so instead of

http://{your-tib-host}:{tib-port}/auth/{profile-id}/proxy/ 

do:

http://{your-tib-host}:{tib-port}/auth/{profile-id}/proxy 

M.

It seems I have another problem because I already call

http://{your-tib-host}:{tib-port}/auth/{profile-id}/proxy (without the tailing /)

And I still have the Login fail.

you can try it here : http://54.194.109.37:3010/auth/2/proxy (GET or POST)

Can I see your whole profile (you can PM it to me if you don;t want to make it public)?