Help - Adapt old Gatekeeper config to Louketo

[paoloantinori]

Title

Help - Adapt old Gatekeeper config to Louketo

Summary

I have a configuration that was valid in KC Gatekeeper but that seems not to be working with Louketo and I cannot see what should be done differently.

Environment

Expected Results

The last call of the provided scenario should return the content served by the protected server.

Actual Results

$ ./louketo-proxy --config ./gatekeeper.yaml 
2020-06-09T23:58:25.245+0200    info    starting the service    {"prog": "louketo-proxy", "author": "Louketo", "version": "1.0.0-alpha.1"}
2020-06-09T23:58:25.245+0200    info    attempting to retrieve configuration discovery url  {"url": "http://localhost:8080/auth/realms/sample_realm", "timeout": "30s"}
2020-06-09T23:58:25.419+0200    info    successfully retrieved openid configuration from the discovery
2020-06-09T23:58:25.424+0200    info    enabled reverse proxy mode, upstream url    {"url": "http://localhost:8081/api"}
2020-06-09T23:58:25.424+0200    info    using session cookies only for access and refresh tokens
2020-06-09T23:58:25.424+0200    info    protecting resource {"resource": "uri: /*, methods: GET, required: user"}
2020-06-09T23:58:25.424+0200    info    Louketo proxy service starting  {"interface": ":8083"}
2020-06-09T23:58:41.755+0200    error   no session found in request, redirecting for authorization  {"error": "authentication session not found"}
2020-06-09T23:58:46.935+0200    error   no session found in request, redirecting for authorization  {"error": "authentication session not found"}

Steps to reproduce

https://gist.github.com/paoloantinori/a6332243186aa9e8004cf1cf46335206

Additional Information

I'm using the released binary downloaded from GitHub I'm hoping this might be just a problem with different configuration or default values, so, hopefully, not too hard fix, but reading the docs, I couldn't find the reason for the error by myself.

[abstractj]

@paoloantinori Nothing has changed in the way you configured Louketo, but I will give your quickstart a try and see if I can reproduce the issue. I noticed some issues with Keycloak 10.0.0, but that's no longer the case for the 10.0.2 release.

The response time may be delayed due to public holidays, but I will make sure that you get a proper answer on this.

[abstractj]

@paoloantinori I just followed the steps you mentioned and this is what I get when I run curl:

❯ ./curl.sh
<a href="/oauth/authorize?state=41d3d10b-2c38-471f-8f5b-4f66dbc4cd2b">Temporary Redirect</a>.

<a href="/oauth/authorize?state=5dd11050-5f24-41dd-a242-db8c8d0443c7">Temporary Redirect</a>.

Which makes sense, if I go to http://localhost:8083 I'm prompted with the Keycloak login screen and right after login I can see Apicurio.

I will take a look at the bearer token usage next week, but please let me know if there's anything else I should try.

[abstractj]

@paoloantinori right after I added some comments here, I decided to investigate more and this is what I did:

1. Start Keycloak

   podman run --net=host --rm --name kc -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin -e KEYCLOAK_IMPORT="/home/abstractj/tmp/demorealm.json" quay.io/keycloak/keycloak -Djboss.bind.address.private=localhost -Djboss.bind.address=localhost

   • Please notice that I'm using quay.io

2. Start Apicurio exactly as described in the tutorial

3. Download the Louketo binary and start with the configuration you provided

curl

#!/bin/sh

# use direct access grant (password based) method to get a valid Bearer token
RESULT=$(curl --data "grant_type=password&client_id=public&username=alice&password=password" http://localhost:8080/auth/realms/sample_realm/protocol/openid-connect/token)
TOKEN=$(echo $RESULT | sed 's/.*access_token":"//g' | sed 's/".*//g')

# this will fail (shows a redirect to authentication link)
curl http://localhost:8083/api/artifacts

# this will work since it's using the token we got earlier
curl http://localhost:8083/api/artifacts -H "Accept: application/json" -H "Authorization: Bearer $TOKEN"

Output

❯ ./curl.sh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1976  100  1907  100    69  20073    726 --:--:-- --:--:-- --:--:-- 20800
<a href="/oauth/authorize?state=78a62109-9789-46aa-a568-058a1ffe50be">Temporary Redirect</a>.

["032ac2da-1e33-4655-814b-3376f0042e78"]% 

I hope it helps.

[paoloantinori]

Thank you!

So with your help I've managed to pinpoint the difference:

with the old Gatekeeper (docker.io/keycloak/keycloak-gatekeeper corresponding to SHA 443cda327f52), I didn't need to pass -H "Accept: application/json" header to curl.

That's the main difference.

It seems that quay.io/keycloak/keycloak vs. keycloak/keycloak-gatekeeper is not the differentiator, although I will start referring to the Quay.io image from now on.

I'm happy to close this, I'm just curious to check with you if this difference between old and new is expected, or if this a side effect.