Mixed tokens with an upstream application (change request proposal)
by Rousseau Nikita
Hello everybody,
I'm contacting the dev community of Keycloak-Gatekeeper concerning the Keycloak access token lookup behavior.
A few links :
* The full story is here : https://issues.jboss.org/browse/KEYCLOAK-9885
* Associated PR : https://github.com/keycloak/keycloak-gatekeeper/pull/473
The long story made short :
I am deploying an application that has been configured to work behind a proxy. The proxy must set specific HTTP Headers (i.e. X-Auth-Username, X-Auth-Email) if the request is successfully authenticated and forwards the request to the upstream.
The application is working in "blind" mode : it looks only for HTTP headers sent by the proxy (the application does not have any Gatekeeper specific configuration).
However, in its authentication process, the application set a Bearer token. All queries that are targeting the application API are authenticated against this Bearer token.
For now, Keycloak Gatekeeper inspects the Authorization header first in order to verify the Keycloak access token. Since the Bearer token is not issued by Keycloak, but by the proxied application, the token is refused and the request redirected to the SSO. There are no fallback to the cookie if the Authorization header check fails.
I would like to propose more tuning about token inspection for an incoming request.
I see two approaches for this problem :
* Fallback to the cookie checkup if the authorization header is not valid/present
* Help the proxy by specifying where to look at the keycloak access token, for example force cookie lookup (my approach with this PR #473<https://github.com/keycloak/keycloak-gatekeeper/pull/473> )
I have chosen the second approach. The goal is to bring more behavior tuning to Keycloak-Gatekeeper :
* Being able to configure the Keycloak token lookup (for example force cookie lookup for the access token).
* Being able to forward Authorization header "as-is" to the upstream application (without altering it, transparent way).
What is your point of view ?
Let me know if this email is clear enough.
Thank you for your feedback and your kindness for new contributors,
Best Regards,
Gfi Informatique
Nikita Rousseau
Alternant DevOps
Infrastructures Services
nikita.rousseau(a)gfi.fr<mailto:>
Emerald Square, Bâtiment B, Avenue Evariste Galois
BP 199, 06904 Sophia Antipolis Cedex
Tél : +33 (0)6 25 44 01 37
5 years, 5 months
Re: [keycloak-dev] translate keycloak
by Eugen Stan
Bump.
Hello again. We managed to translate some languages already and we would
like to contribute the translations upstream and hopefully improve the
translation process.
We have some feedback from our process. We use this process internally
and the idea is to have it working for keycloak open source
Proposal for Keycloak
- We propose to move the community translations in a separate git
project - just with the translations
- That repository is going to be used by Weblate as a source of
translations ( use Free Hosted Weblate - https://hosted.weblate.org/ )
- The translations project can be added as a git sub module to the
keycloak project
- during build the translations can be copied to the final artifact
We do this allready and we can help with the code migrations. Having
this setup will improve the contributions to translations and also the
ability to change the translations easily.
WDYT?
Regards,
Eugen
La 01.12.2018 19:22, Eugen Stan a scris:
> Hello,
>
> Where can we find the translation files for Keycloak and what is the
> process for upstreaming them?
>
> We are planning to deploy Keycloak for authentication for our services.
> We have users all accross the globe and we have translators that we can
> ask to translate.
>
> I'm planning to push the translations upstream once they are done (need
> to get approbal on this).
>
>
> Regards,
>
> Eugen
>
>
>
5 years, 5 months