too many redirections

[raif]

Hi there,

I'm trying to use keycloak (KC) for the first time for what i thought was a

basic use-case, but so far have been unsuccessful.

The issue is that when attempting to access a web app, after getting the login

screen and entering the user's credentials, i get a browser error stating that

it encountered too many redirections. Tried w/ both Firefox (72.0.2) and Chrome

(80.0.3987.106) w/ the same result.

The browser's debugger indeed shows after an initial POST to

http://localhost:8080/auth/realms/forge/login-actions/authenticate?\

session_code=SmcND-1YihFErInE3KkGb3U31Ebi7e9crQMsHgjZ-lo&\

execution=791afcdb-1093-4ddf-b85b-7401b7dace4c&\

client_id=YYY&\

tab_id=tPHfmCOQSWc

repeated sequences of the following 3 GET calls each ending w/ a 302 status...

* http://localhost:8080/auth/realms/XXX/protocol/openid-connect/auth?\

response_type=code&\

client_id=YYY&\

redirect_uri=http%3A%2F%2Flocalhost%3A9090%2FYYY%2F&\

state=f69b3e68-6646-48bd-a077-ea38319a08ba&\

login=true&\

scope=openid

* http://localhost:9090/YYY/?\

state=f69b3e68-6646-48bd-a077-ea38319a08ba&\

session_state=9288565f-b977-4865-8069-180154992995&\

code=f958667b-670e-4d0b-88a3-555a71b3e211.9288565f-b977-4865-8069-180154992995.055e1300-16c6-4ad9-b8bd-bf58b533c692

* http://localhost:9090/YYY/

While the 'session_state' parameter's value remain the same, those of 'state'

and 'code' change w/ every triplet instance.

The setup i'm using is as follows:

* Java (Oracle) - java version "1.8.0_202"

Java(TM) SE Runtime Environment (build 1.8.0_202-b08)

Java HotSpot(TM) 64-Bit Server VM (build 25.202-b08, mixed mode),

* Keycloak - Version 8.0.2, and following getting started instructions [1] for

creating a new realm, client and user,

* Tomcat - version 9.0.30, w/ the added adapter JARs from [2],

* Java web-app - version 3.1, with the following added to its web.xml as per [3]

...

<security-constraint>

<web-resource-collection>

<web-resource-name>Customers</web-resource-name>

<url-pattern>/*</url-pattern>

</web-resource-collection>

<auth-constraint>

<role-name>user</role-name>

</auth-constraint>

</security-constraint>

<security-role>

<role-name>user</role-name>

</security-role>

...

* keycloak.json:

{

"realm": "demo",

"auth-server-url": "http://localhost:8080/auth/",

"ssl-required": "external",

"resource": "YYY",

"public-client": true,

"confidential-port": 0

}

* created a 'user' role in KC --tried both a realm role as well as a client one

but result remained the same.

any thoughts or feedback about sorting out this issue is much appreciated. TIA.

[1] https://www.keycloak.org/docs/latest/getting_started/index.html

[2] https://downloads.jboss.org/keycloak/8.0.2/adapters/keycloak-oidc/keycloak-tomcat-adapter-dist-8.0.2.zip

[3] https://www.keycloak.org/docs/latest/securing_apps/index.html#_tomcat_adapter

cheers;

rsn

[Sergey]

you should implement callback method, that stores the session and makes user authenticated at app level.

also, dont filter login callback url.

[raif]

hi Sergey,

thanks for the feedback.  comments in-line...

On Monday, February 17, 2020 at 9:42:25 PM UTC+11, Sergey wrote:

you should implement callback method, that stores the session and makes user authenticated at app level.

while this sounds logical, the KC 'Getting Started Guide' [1] as well as the 'Quarkus - Protecting Web Applications Using OpenID Connect' [4] --which uses KC in a similar use-case-- do not mention anything about the webapp developer implementing additional code/logic to make use of KC.

in addition, i would've thought that such logic is already, or should be, part of the Tomcat's KC Valve implementation (i.e. o.k.a.t.KeycloakAuthenticatorValve class that is added to the 'context.xml' of the to-be-secured webapp).  after all, this class intercepts every call coming to the webapp.  indeed, the 'Securing Applications and Services Guide - Jetty 9.x Adapters' [5] too has no mention of additional logic; only configuration tweaks of how to setup the (KC) adapter and configure it.  the only noticeable difference being the use of SSL w/ Jetty's adapter.

if indeed the solution is not some configuration parameter(s) that need to, or can, be set, but adding logic you suggested, then this sounds more to me like a Tomcat adapter bug.

[4] https://quarkus.io/guides/security-openid-connect-web-authentication

[5] https://www.keycloak.org/docs/latest/securing_apps/index.html#_jetty9_adapter