So in summary we have an agreement that we should close that PR for
now and have a proper design document to cover scenarios like SPA+REST
with Gatekeeper. Does it make sense?
On Fri, Oct 11, 2019 at 2:40 AM Stian Thorgersen <sthorger(a)redhat.com> wrote:
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