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 <[email protected]>: > 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 <[email protected]> > Antwort an: [email protected] > An: Christian Beikov <[email protected]> > Kopie (CC): keycloak-dev <[email protected]> > > > > 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 <[email protected] > <mailto:[email protected]>> 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 > [email protected] <mailto:[email protected]> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > >
