You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@deltaspike.apache.org by Christian Beikov <ch...@gmail.com> on 2016/01/21 11:46:10 UTC
Fwd: Re: [keycloak-dev] Problem with Keycloak 1.8.0.CR1 and
Deltaspike
Hello,
I am cross posting this to make you aware of the problem too.
Currently I am looking at JsfModuleConfig to see if configuring
isInitialRedirectEnabled to false changes anything. Can you maybe tell
me what the implications of configuring it like that are? Unfortunately
I couldn't find any documentation on why you are doing the redirect on
the initial request to append the window id.
-------- Weitergeleitete Nachricht --------
Betreff: Re: [keycloak-dev] Problem with Keycloak 1.8.0.CR1 and Deltaspike
Datum: Wed, 20 Jan 2016 19:58:29 +0100
Von: Stian Thorgersen <st...@redhat.com>
Antwort an: stian@redhat.com
An: Christian Beikov <ch...@gmail.com>
Kopie (CC): keycloak-dev <ke...@lists.jboss.org>
The reason it's failing after upgrading from 1.1 is the check of the
redirect uri was added later. This is not a recent regression so we're
not going to fix it for 1.8. We can look into it for 1.9 though if you
create a JIRA.
My suspicion is that we may not be able to fix it. The problem could be
that DeltaSpike is invoked prior to Keycloak adapter, which results in
the following behavior:
1. DeltaSpike adds "dswid"
2. Keycloak adapter redirects to login page with redirect uri that
includes dswid
3. Keycloak server authenticates users and redirects back to the
application (including dswid)
4. DeltaSpike removes "dswid"
5. Keycloak adapter tries to obtain token using redirect_uri param
without dswid, which is rejected
Step 5 is a step that we can't remove as it's required by the OpenID
Connect specification. It's there to prevent potential attacks.
On 20 January 2016 at 18:17, Christian Beikov
<christian.beikov@gmail.com <ma...@gmail.com>> wrote:
Hello,
we have a problem since Keycloak 1.8.0.CR1 that we didn't have in
1.1.0.Final.
The problem appears when accessing a secured JSF page that uses
DeltaSpike. DeltaSpike redirects the initial request to append a query
param to the path called "dswid". When accesing a secured page, the
Keycloak adapter also does some redirects and adds the redirect uri,
this time the one already including the dswid, into the client session,
but redirects the browser to a URL that includes a redirect uri that
does not contain the dswid. The authentication process fails here:
https://github.com/keycloak/keycloak/blob/1.8.0.CR1/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L231
Since it worked earlier, I guess this is a bug. The actual problem is
the mismatch between the redirect uri stored in the session and the
redirect uri returned to the browser. Hope you can fix this for
1.8.0.Final
Regards,
Christian
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org <ma...@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
Re: [keycloak-dev] Problem with Keycloak 1.8.0.CR1 and Deltaspike
Posted by Thomas Andraschko <an...@gmail.com>.
good news! :)
2016-01-25 14:08 GMT+01:00 Christian Beikov <ch...@gmail.com>:
> Hello,
>
> I am using the Lazy mode, but it turned out to be a problem with the load
> balancing configuration.
> Apparently the Keycloak server adapters require sticky sessions to work
> properly, so there is nothing wrong with deltaspike.
>
> Thanks anyway for the quick answers!
>
> Regards,
> Christian
>
>
> Am 24.01.2016 um 01:20 schrieb Thomas Andraschko:
>
>> Hi,
>>
>> what mode are you using? Lazy or ClientWindow?
>>
>> In case of Lazy, we just remove the dswid on the clientside/js if the
>> window.name doesn't match the dswid parameter.
>>
>>
>> 2016-01-21 12:19 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
>>
>> hi christian,
>>>
>>> the initial redirect is needed to add the window-id to the url.
>>> otherwise a browser-refresh on the first page would lead to a new
>>> window-id.
>>>
>>> regards,
>>> gerhard
>>>
>>>
>>>
>>> 2016-01-21 11:46 GMT+01:00 Christian Beikov <christian.beikov@gmail.com
>>> >:
>>>
>>> Hello,
>>>>
>>>> I am cross posting this to make you aware of the problem too.
>>>>
>>>> Currently I am looking at JsfModuleConfig to see if configuring
>>>> isInitialRedirectEnabled to false changes anything. Can you maybe tell
>>>> me
>>>> what the implications of configuring it like that are? Unfortunately I
>>>> couldn't find any documentation on why you are doing the redirect on the
>>>> initial request to append the window id.
>>>>
>>>>
>>>> -------- Weitergeleitete Nachricht --------
>>>> Betreff: Re: [keycloak-dev] Problem with Keycloak 1.8.0.CR1 and
>>>> Deltaspike
>>>> Datum: Wed, 20 Jan 2016 19:58:29 +0100
>>>> Von: Stian Thorgersen <st...@redhat.com>
>>>> Antwort an: stian@redhat.com
>>>> An: Christian Beikov <ch...@gmail.com>
>>>> Kopie (CC): keycloak-dev <ke...@lists.jboss.org>
>>>>
>>>>
>>>>
>>>> The reason it's failing after upgrading from 1.1 is the check of the
>>>> redirect uri was added later. This is not a recent regression so we're
>>>>
>>> not
>>>
>>>> going to fix it for 1.8. We can look into it for 1.9 though if you
>>>>
>>> create a
>>>
>>>> JIRA.
>>>>
>>>> My suspicion is that we may not be able to fix it. The problem could be
>>>> that DeltaSpike is invoked prior to Keycloak adapter, which results in
>>>>
>>> the
>>>
>>>> following behavior:
>>>>
>>>> 1. DeltaSpike adds "dswid"
>>>> 2. Keycloak adapter redirects to login page with redirect uri that
>>>> includes dswid
>>>> 3. Keycloak server authenticates users and redirects back to the
>>>> application (including dswid)
>>>> 4. DeltaSpike removes "dswid"
>>>> 5. Keycloak adapter tries to obtain token using redirect_uri param
>>>>
>>> without
>>>
>>>> dswid, which is rejected
>>>>
>>>> Step 5 is a step that we can't remove as it's required by the OpenID
>>>> Connect specification. It's there to prevent potential attacks.
>>>>
>>>> On 20 January 2016 at 18:17, Christian Beikov <
>>>>
>>> christian.beikov@gmail.com
>>>
>>>> <ma...@gmail.com>> wrote:
>>>>
>>>> Hello,
>>>>
>>>> we have a problem since Keycloak 1.8.0.CR1 that we didn't have in
>>>> 1.1.0.Final.
>>>> The problem appears when accessing a secured JSF page that uses
>>>> DeltaSpike. DeltaSpike redirects the initial request to append a
>>>> query
>>>> param to the path called "dswid". When accesing a secured page, the
>>>> Keycloak adapter also does some redirects and adds the redirect uri,
>>>> this time the one already including the dswid, into the client
>>>>
>>> session,
>>>
>>>> but redirects the browser to a URL that includes a redirect uri that
>>>> does not contain the dswid. The authentication process fails here:
>>>>
>>>>
>>>>
>>> https://github.com/keycloak/keycloak/blob/1.8.0.CR1/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L231
>>>
>>>> Since it worked earlier, I guess this is a bug. The actual problem
>>>> is
>>>> the mismatch between the redirect uri stored in the session and the
>>>> redirect uri returned to the browser. Hope you can fix this for
>>>> 1.8.0.Final
>>>>
>>>> Regards,
>>>> Christian
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev@lists.jboss.org <ma...@lists.jboss.org>
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>
Re: [keycloak-dev] Problem with Keycloak 1.8.0.CR1 and Deltaspike
Posted by Christian Beikov <ch...@gmail.com>.
Hello,
I am using the Lazy mode, but it turned out to be a problem with the
load balancing configuration.
Apparently the Keycloak server adapters require sticky sessions to work
properly, so there is nothing wrong with deltaspike.
Thanks anyway for the quick answers!
Regards,
Christian
Am 24.01.2016 um 01:20 schrieb Thomas Andraschko:
> Hi,
>
> what mode are you using? Lazy or ClientWindow?
>
> In case of Lazy, we just remove the dswid on the clientside/js if the
> window.name doesn't match the dswid parameter.
>
>
> 2016-01-21 12:19 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
>
>> hi christian,
>>
>> the initial redirect is needed to add the window-id to the url.
>> otherwise a browser-refresh on the first page would lead to a new
>> window-id.
>>
>> regards,
>> gerhard
>>
>>
>>
>> 2016-01-21 11:46 GMT+01:00 Christian Beikov <ch...@gmail.com>:
>>
>>> Hello,
>>>
>>> I am cross posting this to make you aware of the problem too.
>>>
>>> Currently I am looking at JsfModuleConfig to see if configuring
>>> isInitialRedirectEnabled to false changes anything. Can you maybe tell me
>>> what the implications of configuring it like that are? Unfortunately I
>>> couldn't find any documentation on why you are doing the redirect on the
>>> initial request to append the window id.
>>>
>>>
>>> -------- Weitergeleitete Nachricht --------
>>> Betreff: Re: [keycloak-dev] Problem with Keycloak 1.8.0.CR1 and
>>> Deltaspike
>>> Datum: Wed, 20 Jan 2016 19:58:29 +0100
>>> Von: Stian Thorgersen <st...@redhat.com>
>>> Antwort an: stian@redhat.com
>>> An: Christian Beikov <ch...@gmail.com>
>>> Kopie (CC): keycloak-dev <ke...@lists.jboss.org>
>>>
>>>
>>>
>>> The reason it's failing after upgrading from 1.1 is the check of the
>>> redirect uri was added later. This is not a recent regression so we're
>> not
>>> going to fix it for 1.8. We can look into it for 1.9 though if you
>> create a
>>> JIRA.
>>>
>>> My suspicion is that we may not be able to fix it. The problem could be
>>> that DeltaSpike is invoked prior to Keycloak adapter, which results in
>> the
>>> following behavior:
>>>
>>> 1. DeltaSpike adds "dswid"
>>> 2. Keycloak adapter redirects to login page with redirect uri that
>>> includes dswid
>>> 3. Keycloak server authenticates users and redirects back to the
>>> application (including dswid)
>>> 4. DeltaSpike removes "dswid"
>>> 5. Keycloak adapter tries to obtain token using redirect_uri param
>> without
>>> dswid, which is rejected
>>>
>>> Step 5 is a step that we can't remove as it's required by the OpenID
>>> Connect specification. It's there to prevent potential attacks.
>>>
>>> On 20 January 2016 at 18:17, Christian Beikov <
>> christian.beikov@gmail.com
>>> <ma...@gmail.com>> wrote:
>>>
>>> Hello,
>>>
>>> we have a problem since Keycloak 1.8.0.CR1 that we didn't have in
>>> 1.1.0.Final.
>>> The problem appears when accessing a secured JSF page that uses
>>> DeltaSpike. DeltaSpike redirects the initial request to append a query
>>> param to the path called "dswid". When accesing a secured page, the
>>> Keycloak adapter also does some redirects and adds the redirect uri,
>>> this time the one already including the dswid, into the client
>> session,
>>> but redirects the browser to a URL that includes a redirect uri that
>>> does not contain the dswid. The authentication process fails here:
>>>
>>>
>> https://github.com/keycloak/keycloak/blob/1.8.0.CR1/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L231
>>> Since it worked earlier, I guess this is a bug. The actual problem is
>>> the mismatch between the redirect uri stored in the session and the
>>> redirect uri returned to the browser. Hope you can fix this for
>>> 1.8.0.Final
>>>
>>> Regards,
>>> Christian
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev@lists.jboss.org <ma...@lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>>
>>>
Re: Re: [keycloak-dev] Problem with Keycloak 1.8.0.CR1 and Deltaspike
Posted by Thomas Andraschko <an...@gmail.com>.
Hi,
what mode are you using? Lazy or ClientWindow?
In case of Lazy, we just remove the dswid on the clientside/js if the
window.name doesn't match the dswid parameter.
2016-01-21 12:19 GMT+01:00 Gerhard Petracek <ge...@gmail.com>:
> hi christian,
>
> the initial redirect is needed to add the window-id to the url.
> otherwise a browser-refresh on the first page would lead to a new
> window-id.
>
> regards,
> gerhard
>
>
>
> 2016-01-21 11:46 GMT+01:00 Christian Beikov <ch...@gmail.com>:
>
> > Hello,
> >
> > I am cross posting this to make you aware of the problem too.
> >
> > Currently I am looking at JsfModuleConfig to see if configuring
> > isInitialRedirectEnabled to false changes anything. Can you maybe tell me
> > what the implications of configuring it like that are? Unfortunately I
> > couldn't find any documentation on why you are doing the redirect on the
> > initial request to append the window id.
> >
> >
> > -------- Weitergeleitete Nachricht --------
> > Betreff: Re: [keycloak-dev] Problem with Keycloak 1.8.0.CR1 and
> > Deltaspike
> > Datum: Wed, 20 Jan 2016 19:58:29 +0100
> > Von: Stian Thorgersen <st...@redhat.com>
> > Antwort an: stian@redhat.com
> > An: Christian Beikov <ch...@gmail.com>
> > Kopie (CC): keycloak-dev <ke...@lists.jboss.org>
> >
> >
> >
> > The reason it's failing after upgrading from 1.1 is the check of the
> > redirect uri was added later. This is not a recent regression so we're
> not
> > going to fix it for 1.8. We can look into it for 1.9 though if you
> create a
> > JIRA.
> >
> > My suspicion is that we may not be able to fix it. The problem could be
> > that DeltaSpike is invoked prior to Keycloak adapter, which results in
> the
> > following behavior:
> >
> > 1. DeltaSpike adds "dswid"
> > 2. Keycloak adapter redirects to login page with redirect uri that
> > includes dswid
> > 3. Keycloak server authenticates users and redirects back to the
> > application (including dswid)
> > 4. DeltaSpike removes "dswid"
> > 5. Keycloak adapter tries to obtain token using redirect_uri param
> without
> > dswid, which is rejected
> >
> > Step 5 is a step that we can't remove as it's required by the OpenID
> > Connect specification. It's there to prevent potential attacks.
> >
> > On 20 January 2016 at 18:17, Christian Beikov <
> christian.beikov@gmail.com
> > <ma...@gmail.com>> wrote:
> >
> > Hello,
> >
> > we have a problem since Keycloak 1.8.0.CR1 that we didn't have in
> > 1.1.0.Final.
> > The problem appears when accessing a secured JSF page that uses
> > DeltaSpike. DeltaSpike redirects the initial request to append a query
> > param to the path called "dswid". When accesing a secured page, the
> > Keycloak adapter also does some redirects and adds the redirect uri,
> > this time the one already including the dswid, into the client
> session,
> > but redirects the browser to a URL that includes a redirect uri that
> > does not contain the dswid. The authentication process fails here:
> >
> >
> https://github.com/keycloak/keycloak/blob/1.8.0.CR1/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L231
> >
> > Since it worked earlier, I guess this is a bug. The actual problem is
> > the mismatch between the redirect uri stored in the session and the
> > redirect uri returned to the browser. Hope you can fix this for
> > 1.8.0.Final
> >
> > Regards,
> > Christian
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev@lists.jboss.org <ma...@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >
> >
> >
> >
> >
>
Re: Re: [keycloak-dev] Problem with Keycloak 1.8.0.CR1 and Deltaspike
Posted by Gerhard Petracek <ge...@gmail.com>.
hi christian,
the initial redirect is needed to add the window-id to the url.
otherwise a browser-refresh on the first page would lead to a new window-id.
regards,
gerhard
2016-01-21 11:46 GMT+01:00 Christian Beikov <ch...@gmail.com>:
> Hello,
>
> I am cross posting this to make you aware of the problem too.
>
> Currently I am looking at JsfModuleConfig to see if configuring
> isInitialRedirectEnabled to false changes anything. Can you maybe tell me
> what the implications of configuring it like that are? Unfortunately I
> couldn't find any documentation on why you are doing the redirect on the
> initial request to append the window id.
>
>
> -------- Weitergeleitete Nachricht --------
> Betreff: Re: [keycloak-dev] Problem with Keycloak 1.8.0.CR1 and
> Deltaspike
> Datum: Wed, 20 Jan 2016 19:58:29 +0100
> Von: Stian Thorgersen <st...@redhat.com>
> Antwort an: stian@redhat.com
> An: Christian Beikov <ch...@gmail.com>
> Kopie (CC): keycloak-dev <ke...@lists.jboss.org>
>
>
>
> The reason it's failing after upgrading from 1.1 is the check of the
> redirect uri was added later. This is not a recent regression so we're not
> going to fix it for 1.8. We can look into it for 1.9 though if you create a
> JIRA.
>
> My suspicion is that we may not be able to fix it. The problem could be
> that DeltaSpike is invoked prior to Keycloak adapter, which results in the
> following behavior:
>
> 1. DeltaSpike adds "dswid"
> 2. Keycloak adapter redirects to login page with redirect uri that
> includes dswid
> 3. Keycloak server authenticates users and redirects back to the
> application (including dswid)
> 4. DeltaSpike removes "dswid"
> 5. Keycloak adapter tries to obtain token using redirect_uri param without
> dswid, which is rejected
>
> Step 5 is a step that we can't remove as it's required by the OpenID
> Connect specification. It's there to prevent potential attacks.
>
> On 20 January 2016 at 18:17, Christian Beikov <christian.beikov@gmail.com
> <ma...@gmail.com>> wrote:
>
> Hello,
>
> we have a problem since Keycloak 1.8.0.CR1 that we didn't have in
> 1.1.0.Final.
> The problem appears when accessing a secured JSF page that uses
> DeltaSpike. DeltaSpike redirects the initial request to append a query
> param to the path called "dswid". When accesing a secured page, the
> Keycloak adapter also does some redirects and adds the redirect uri,
> this time the one already including the dswid, into the client session,
> but redirects the browser to a URL that includes a redirect uri that
> does not contain the dswid. The authentication process fails here:
>
> https://github.com/keycloak/keycloak/blob/1.8.0.CR1/services/src/main/java/org/keycloak/protocol/oidc/endpoints/TokenEndpoint.java#L231
>
> Since it worked earlier, I guess this is a bug. The actual problem is
> the mismatch between the redirect uri stored in the session and the
> redirect uri returned to the browser. Hope you can fix this for
> 1.8.0.Final
>
> Regards,
> Christian
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev@lists.jboss.org <ma...@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
>
>