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?
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?
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:
You send your authentication request to http://{your-tib-host}:{tib-port}/auth/{profile-id}/proxy/
TIB spits out an API token as a JSON object (no return URL)
You then use this token to access: http://{your-tyk-host}:{port}/{listen-path}/{resource} for the API 1a188fa6b20d47d078450b1f2be26ff3
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
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.
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
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)?
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 :