12:39 a.m.
We also have the following related request:
https://issues.jboss.org/browse/KEYCLOAK-11082
This emphasises my point that the SPA+REST same-domain scenario needs to be
properly designed, rather than done through random PRs.
On Fri, 11 Oct 2019 at 07:38, Stian Thorgersen <sthorger(a)redhat.com> wrote:
The hybrid SPA+REST secured with Gatekeeper is a scenario that we
would
like to cover with Gatekeeper. It's a pretty broad scenario though and
would need to be properly supported in Gatekeeper. So I would argue that
this is a perfect case for asking for a design proposal.
As a quick idea Gatekeeper would need to know what parts are the SPA and
what parts are the REST endpoints. For the SPA app it would need to drive
the authorization code flow on the Gatekeeper side, with a confidential
client. It would also need to expose some endpoints the SPA can use like
/login /userinfo /logout. After the SPA has logged-in a cookie should be
set that allows the SPA to invoke the REST endpoints (on the same domain).
This would have to have CSRF protection, but maybe not CSRF tokens as you
don't want to have to modify the SPA itself. SameSite and CORS will
probably be better options here. On the REST side Gatekeeper should be able
to use the cookie instead of the bearer token. Further, it should probably
work with one Gatekeeper instance securing both SPA+REST as well as
separate Gatekeeper for the SPA and REST.
On Thu, 10 Oct 2019 at 15:50, Bruno Oliveira <bruno(a)abstractj.org> wrote:
> Some time ago we got this PR for Gatekeeper:
> https://github.com/keycloak/keycloak-gatekeeper/pull/446. But I'm
> 50/50 on this. Even though I think it's great to add extra protection
> to Gatekeeper, we will end up with a new dependency and implementation
> of something that apps could handle. Plus, the inclusion of SameSite
> (https://github.com/keycloak/keycloak-gatekeeper/pull/482) helps to
> mitigate CSRF.
>
> If we take into consideration all the security threats that we have
> today, probably dependencies like https://github.com/unrolled/secure
> should also be included too.
>
> At the moment, I'm leaning toward to reject this change, as I don't
> see any real need for this, but if you have any thoughts, please let
> me know.
>
> --
> - abstractj
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>