Traefik + EAS + KeyCloak

[CanisHelix]

Traefik + EAS + KeyCloak

[travisghansen]

Welcome! Sorry it’s been such a struggle :( I’m sure we can get you going though.

So generally the process you followed looks sane. The structure of your json is off a little bit and what you sent seems like invalid json as well. But that may not be your issue currently anyway. Can you send the output/config token data from running the docker run command?

[travisghansen]

And send over the logs previous to the 503 line/error as well.

[travisghansen]

While waiting for further details, here are some notes:

1. the structure of the json is off, use something like the following (you can use yaml vs json):

aud: someaudience
eas:
  plugins:
    - type: oidc
      issuer:
        discover_url: >-
          https://identity.mydomain.com/realms/test/.well-known/openid-configuration
      client:
        client_id: eas
        client_secret: supersecretkey
      scopes:
        - openid
        - email
        - profile
      pkce:
        enabled: false
        code_challenge_method: S256
      nonce:
        enabled: false
        ttl: 600
      custom_authorization_parameters: {}
      custom_authorization_code_parameters: {}
      custom_refresh_parameters: {}
      custom_revoke_parameters: {}
      redirect_uri: 'https://eas.mydomain.com/oauth/callback'
      features:
        cookie_expiry: false
        userinfo_expiry: true
        session_expiry: true
        session_expiry_refresh_window: 86400
        session_retain_id: true
        refresh_access_token: true
        fetch_userinfo: true
        introspect_access_token: false
        introspect_expiry: 0
        authorization_token: access_token
        filtered_service_headers: []
        logout:
          revoke_tokens_on_logout: []
          end_provider_session:
            enabled: false
            post_logout_redirect_uri: 'https://eas.mydomain.com/oauth/end-session-redirect'
          backchannel:
            enabled: false
      assertions:
        aud: true
        exp: true
        nbf: true
        iss: true
        sig:
          enabled: false
      xhr: {}
      csrf_cookie: {}
      cookie: {}
      custom_error_headers: {}
      custom_service_headers: {}

2. if your keycloak env supports it I would suggest enabling nonce and pkce, they provide the best security
3. (this is likely your primary issue) the config_token as returned using the command above is not url encoded. Run the token through your encoder of choice or something like https://www.urlencoder.org/ to get the values as it should be in your traefik config (ie: address = "https://eas.mydomain.com/verify?config_token=<THE ENCODED STRING HERE>"
4. ensure that the eas is not protected by the eas middleware configuration...that will not end well :)

[CanisHelix]

Thanks for the quick feedback.

I ripped the config_token straight from an example in HOWTO.md (https://github.com/travisghansen/external-auth-server/blob/master/HOWTO.md#generage-config_token) but at a late hour I clearly mistook Javascript for JSON. But then I expected the generate-config-token command to detect that and produce an error instead of providing a token back.

I've corrected that now, and used https://www.urlencoder.org/ and now it is working as expected.

Regarding PKCE/Nonce, I'm still new to Keycloak (latest version) and not even sure how to enable these yet on the realm? client? server?

[CanisHelix]

With the advice given I've almost got this working. The end service is expecting the email address in a single header containing only an email address. But X-Auth-Email and X-Auth-Username are empty, X-Userinfo (I added this as a forwarded header to Traefik) is passed along, but the end service needs just the email.

So the only challenge is figuring out how to get just the Email into a header via Traefik/Keycloak/EAS. Still new to SSO so learning lot's here.

[travisghansen]

Yup! This project is super powerful but also takes a minute to grok all the config. I can send you exact syntax but I'll need you to send over samples of the id_token/userinfo data so I know exactly where in the data the relevant datapoints reside. The mechanism for doing this is the custom_service_headers feature.

[CanisHelix]

This is super powerful, but definitely takes some time to understand the configuration. Just found custom_service_headers and reading some examples.

The X-Userinfo being passed looks something like this:

{"sub":"991fed2d-f5ed-490e-88b5-268100b63ebe","email_verified":true,"name":"FirstName LastName","preferred_username":"firstname","given_name":"FirstName","family_name":"LastName","email":"[email protected]"}

So I'm thinking something like this might work:

     "custom_service_headers": {
        "X-Auth-Email": {
            "source": "userinfo",
            "encoding": "plain",
            "query_engine": "jq",
            "query": "[ .emails[].email ] | first",
        },
        "X-Auth-Username": {
            "source": "userinfo",
            "encoding": "plain",
            "query_engine": "jq",
            "query": "[ .preferred_username ]",
        }
    } 

[travisghansen]

For best performance use jp query_engine:

Something like this should make it all work:

     "custom_service_headers": {
        "X-Auth-Email": {
            "source": "userinfo",
            "encoding": "plain",
            "query_engine": "jp",
            "query": "$.email",
            "query_opts": {
                "single_value": true
            }
        },
        "X-Auth-Username": {
            "source": "userinfo",
            "encoding": "plain",
            "query_engine": "jp",
            "query": "$.preferred_username",
            "query_opts": {
                "single_value": true
            }
        }
    }

[CanisHelix]

That works perfectly too. Thanks ever so much with the help in getting this up and running.

[travisghansen]

No problem! Enjoy!

Another possibility is to include email in your scopes and use the data from the id_token instead of userinfo as userinfo requires an api call to the provider to get the extra data. eas can/will cache userinfo data to keep the overhead down but if the needs are very slim it may make sense to go that route.