deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Beikov <>
Subject Fwd: Re: [keycloak-dev] Problem with Keycloak 1.8.0.CR1 and Deltaspike
Date Thu, 21 Jan 2016 10:46:10 GMT

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 <>
Antwort an:
An: 	Christian Beikov <>
Kopie (CC): 	keycloak-dev <>

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 
< <>> wrote:


    we have a problem since Keycloak 1.8.0.CR1 that we didn't have in
    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:

    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

    keycloak-dev mailing list <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message