4:57 a.m.
Hello all
I am working on a hybrid use-case in which the API gateway (keycloak-gatekeeper) checks
trafficfrom (i) trusted server-side apps (e.g. serving server-based UIs) and (ii) browser
apps (e.g. react JS apps).
With case (i), traffic is authenticated against a bearer token in header, which is never
exposed to the end user-agent.With case (ii), authentication is carried out with
encrypted, httpOnly, Secure cookies.
I am fine with this setup, but for the classical cookie replay attack (however, this is
already strongly mitigated by the httpOnly flag, but not entirely satisfactory).
So I have been experimenting a bit with introducing an automatic CSRF mechanism in
gatekeeper, based on gorilla/csrf package.
With CSRF enabled on a per protected resource basis, another encrypted cookie is carried
back and forth to store the CSRF state and a header returned to the client. Obviously,
CSRF check is disabled when a bearer token is present.
This forces the browser app to add a volatile CSRF token every time it calls a mutable
resource (e.g. with POST, PUT, DELETE) relayed by the gateway.
I am currently polishing my POC with this feature and would be happy to contribute it as a
PR.
Pieces of advice, feedback and opinions are welcome.
Cheers,
Frederic
5:39 a.m.
New subject: [keycloak-gatekeeper] Rationale behind merged PR#440
TL;DR: PR#440 did break the way the redirection/state handling use to work. Need at least
some explanation to get to work again with this.
I had implemented the final landing page using encoded state, and accomodate the way
leycloak-gatekeeper used to work.
I understand that now, setting the state for further checks by the client at the end of
the sequence of redirection is no more possible.
Further, to control the final landing page, we must now use a special
"request_uri" cookie...
Am I assuming correctly?
Another remark: I cannot find the associated JIRA 8984 so it is difficult to grasp the
background of this change.
The closest I could find is KEYCLOAK-8856, but no mention there of the strategy adopted
with this PR.
Could someone shed some light on this change?
Frédéric
7:02 a.m.
This sounds interesting, but I wouldn't expect much feedback until
January. A lot of the Keycloak team is already on holiday.
On 12/15/2018 5:57 AM, BIDON Frederic wrote:
Hello all
I am working on a hybrid use-case in which the API gateway (keycloak-gatekeeper) checks
trafficfrom (i) trusted server-side apps (e.g. serving server-based UIs) and (ii) browser
apps (e.g. react JS apps).
With case (i), traffic is authenticated against a bearer token in header, which is never
exposed to the end user-agent.With case (ii), authentication is carried out with
encrypted, httpOnly, Secure cookies.
I am fine with this setup, but for the classical cookie replay attack (however, this is
already strongly mitigated by the httpOnly flag, but not entirely satisfactory).
So I have been experimenting a bit with introducing an automatic CSRF mechanism in
gatekeeper, based on gorilla/csrf package.
With CSRF enabled on a per protected resource basis, another encrypted cookie is carried
back and forth to store the CSRF state and a header returned to the client. Obviously,
CSRF check is disabled when a bearer token is present.
This forces the browser app to add a volatile CSRF token every time it calls a mutable
resource (e.g. with POST, PUT, DELETE) relayed by the gateway.
I am currently polishing my POC with this feature and would be happy to contribute it as
a PR.
Pieces of advice, feedback and opinions are welcome.
Cheers,
Frederic
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
5:50 a.m.
Please, file a Jira as a feature request, providing all the details.
In this way, we don't miss it.
On Sat, Dec 15, 2018 at 11:02 AM Stan Silvert <ssilvert(a)redhat.com> wrote:
This sounds interesting, but I wouldn't expect much feedback until
January. A lot of the Keycloak team is already on holiday.
On 12/15/2018 5:57 AM, BIDON Frederic wrote:
> Hello all
> I am working on a hybrid use-case in which the API gateway (keycloak-gatekeeper)
checks trafficfrom (i) trusted server-side apps (e.g. serving server-based UIs) and (ii)
browser apps (e.g. react JS apps).
> With case (i), traffic is authenticated against a bearer token in header, which is
never exposed to the end user-agent.With case (ii), authentication is carried out with
encrypted, httpOnly, Secure cookies.
> I am fine with this setup, but for the classical cookie replay attack (however, this
is already strongly mitigated by the httpOnly flag, but not entirely satisfactory).
> So I have been experimenting a bit with introducing an automatic CSRF mechanism in
gatekeeper, based on gorilla/csrf package.
> With CSRF enabled on a per protected resource basis, another encrypted cookie is
carried back and forth to store the CSRF state and a header returned to the client.
Obviously, CSRF check is disabled when a bearer token is present.
>
> This forces the browser app to add a volatile CSRF token every time it calls a
mutable resource (e.g. with POST, PUT, DELETE) relayed by the gateway.
> I am currently polishing my POC with this feature and would be happy to contribute
it as a PR.
>
> Pieces of advice, feedback and opinions are welcome.
> Cheers,
> Frederic
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
- abstractj
2201
days inactive
2203
days old
3 comments
3 participants
participants (3)
-
BIDON Frederic -
Bruno Oliveira -
Stan Silvert