Hi there,
I am trying to setup a POC using Docker and Tyk Gateway 4.1, involving one protected API, integrating with Tyk API Gateway, and a 3rd party OIDC service Keycloak. Basically what I am trying to achieve here is quite a common setup, after going a login flow with Keycloak, the client tries to access a protected api by sending a JWT token via HTTP headers and the Tyk API Gateway will verify the legitimacy of this JWT token using the JWKS retrieved from the Keycloak server, and subsequently accepts or rejects the request.
However, I am having some trouble getting the verification part to work, and have tried the following approaches.
Somehow the system thinks I am trying to embed links and new users can’t have more than 2 so you will notice that the http and https protocols are missing colons… And also, I can’t upload images because of some issue in the system as well, so please pardon me.
Approach 1: Verify directly with Keycloak server using Docker service name
Note: JWT Token contains “iss” claims which is the proxied URL (xxx.xxx.xxx.xxx:8080/keycloak/realms/…)
Relevant configuration:
"openid_options": {
"providers": [
{
"issuer": "http//keycloak/realms/master",
"client_ids": {
"YWNjb3VudA==": "default"
}
}
]
}
- Client attempts to access protected API and sends JWT in headers to Tyk Gateway (which is exposed on the host PC, xxx.xxx.xxx.xxx:8080/protected/).
- Tyk Gateway attempts to verify token using http//keycloak/realms/…
This fails because of the following:
tyk-gateway_1 | time=“Nov 11 05:50:39” level=warning msg=“JWT Invalid” api_id=protected-api api_name=“Protected API” error=“Validation error. Validation error. No provider was registered with issuer: https//xxx.xxx.xxx.xxx/keycloak/realms/master” mw=OpenIDMW org_id=default origin=172.25.0.1 path=“/protected/”
tyk-gateway_1 | time=“Nov 11 05:50:39” level=warning msg=“Attempted access with invalid key.” api_id=protected-api api_name=“Protected API” key=“****JWT]” mw=OpenIDMW org_id=default origin=172.25.0.1 path=“/protected/”
I guess it’s because there’s a mismatch in the “iss” claim and the provider object in openid_options:
Possible solution: Have an option that can ignore issuer matching?
Approach 2: Verify with Keycloak server using going through Tyk Gateway API (going through itself)
Relevant configuration:
"openid_options": {
"providers": [
{
"issuer": "https//xxx.xxx.xxx.xxx/keycloak/realms/master",
"client_ids": {
"YWNjb3VudA==": "default"
}
}
]
}
- Client attempts to access protected API and sends JWT in headers to Tyk Gateway (which is exposed on the host PC, xxx.xxx.xxx.xxx:8080/protected/).
- Since the “iss” claim and provider object issuer matches (https//xxx.xxx.xxx.xxx/keycloak/realms/master), the previous approach’s issue is no longer there.
When using SSL/TLS, in a production or staging environment, I think there will be no issue as we will be using legitimate domain names with signed certificates. However, in development, because we’re unable to use localhost in a Docker environment (localhost in host PC and localhost in Tyk Gateway is different), we are forced to used IP addresses, and Tyk Gateway will throw the following error:
tyk-gateway_1 | time=“Nov 11 06:16:05” level=warning msg=“JWT Invalid” api_id=protected-api api_name=“Protected API” error=“Validation error. Validation error. Failure while contacting the configuration endpoint https//xxx.xxx.xxx.xxx/keycloak/realms/master/.well-known/openid-configuration.” mw=OpenIDMW org_id=default origin=172.25.0.1 path=“/protected/”
tyk-gateway_1 | time=“Nov 11 06:16:05” level=warning msg=“Attempted access with invalid key.” api_id=protected-api api_name=“Protected API” key=“****JWT]” mw=OpenIDMW org_id=default origin=172.25.0.1 path=“/protected/”
tyk-gateway_1 | 2022/11/11 06:16:05 http TLS handshake error from 172.25.0.1:56400: remote error: tls: bad certificate
I believe this is due to the mismatch of the CN in the self-signed certificate:
`
curl: (60) SSL: certificate subject name ‘example.com’ does not match target host name ‘xxx.xxx.xxx.xxx’
More details here: https//curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
`
I have tried the following to no avail:
- Add the certificate to the /etc/ssl/certs.
- Under the /protected/ api, add proxy.transport.ssl_insecure_skip_verify = true
- Under the /protected/ api, add proxy.transport.ssl_force_common_name_check= false
- Under the tyk gateway configuration, add proxy_ssl_insecure_skip_verify = true
- Under the tyk gateway configuration, add jwt_ssl_insecure_skip_verify = true
- Under the tyk gateway configuration, add ssl_force_common_name_check = false
We probably need some way to either: 1. Ignore the issuer value mismatch, 2. Ignore any SSL/TLS related errors if Tyk Gateway needs to make a request that passes through itself.
Any suggestions?
Thank you.
Prakoso
. The logs could have been more specific.