SSO with SavaPage OAuth Plugins

OAuth Client Plugins can be used to activate Single Sign-on (SSO) for the User Web App. The savapage-ext-oauth repository gives all the details.

Please let us know if you have questions or if you need an additional OAuth provider.

1 Like

Hi,

Thanks for adding the KeyCloak OAuth plugin. I’ve managed to configure it and it does indeed add the login method.

Unfortunately, I can’t comment on whether the authentication flow works yet. When I try to login it fails and the server log contains this: ERROR WebAppUser:362 - OAuth [keycloak]: no userinfo. [jetty-threadpool-33]

However, I suspect this is a configuration issue on my side. I’m pretty new to KeyCloak and I’d be very surprised if the OAuth Client I created was set up correctly!

I should be able to do some more testing in the next couple of days. I’ll post my finds/results here

Cheers.

I finally had a chance to look at this again. I’m not sure the issue is on KeyCloak’s side anymore.

When I try to login with the KeyCloak button (and authenticate on the KeyCloak site) SavaPage shows:
image

Looking at the HTTP traffic reveals KeyCloak responded with a 302 with the following header:

location: http://<mySavapage>:8631/user?sp-oauth=keycloak&session_state=<uuid-1>&code=<uuid-2>.<uuid-1 again>.<uuid-3>

(I have replaced the real UUIDs with <uuid-#>)
…which leads me to believe the authentication succeeded.

When the above location loads in the browser, Savapage responds with this 302 redirect:

Location: http://<mySavapage>:8631/wicket/bookmarkable/org.savapage.server.webapp.WebAppOAuthMsg?sp-app=USER&sp-login-oauth=KEYCLOAK&sp-p1=w

which is the page that shows the login error.

Any thoughts?

I can create an account for you on my KeyCloak instance and set up a redirect_url for you if you’d like to test things out.

It looks like the KeyCloak OAuth authenticated user is not found in SavaPage. Are there any error or warning messages in /opt/savapage/server/logs/server.log ?

You can enable debug logging for just KeyCloak OAuth by adding this line to /opt/savapage/server/lib/log4j.properties (this will log the OAuth JSON response):

log4j.logger.org.savapage.ext.oauth.KeycloakOAuthPlugin=DEBUG

A SavaPage restart is required for this change to take effect.

If you like you can send test account credentials of your KeyCloak instance to support@savapage.org (I will reply with a redirect_url).

I changed my logger config as you suggested, however nothing all that interesting gets logged. All I see after a failed attempt is this:

2020-10-14 17:04:24,312 ERROR KeycloakOAuthPlugin:264 - Error 404 [jetty-threadpool-75]
2020-10-14 17:04:24,313 ERROR WebAppUser:362 - OAuth [keycloak]: no userinfo. [jetty-threadpool-75]

I think I may know what’s going on, though. I checked my reverse proxy logs and saw this:

... "GET //auth/realms/<my-realm>/protocol/openid-connect/userinfo HTTP/1.1" 404 1602 "-" "Java/1.8.0_265" "-"

Note the double leading / in //auth/... and the 404. I think Savapage may be constructing a URL incorrectly when trying to query the OAuth source for user info.

Unfortunately I haven’t given myself much time to work on this this week so that’s as far as my investigation goes right now. I’ll try to make some time tomorrow to send you some KeyCloak credentials so we can continue testing.

Cheers!

Update: I was just about to post this but I decided to do a quick test first. In my savapage-ext-oauth-keycloak.properties I modified the keycloak.oauth.base-url field so that it didn’t contain any trailing slashes. The KeyCloak-based login now works!

So, in the end it was a mistake on my part. It would be nice, though, if the plugin did some validation on the fields and logged a warning or error message if a trailing slash is present. Or perhaps the URL construction logic could coallesce adjacent slashes? I don’t know, that might be too presumptiuous and break otherwise legal URLs. Input validation is hard!

@MetaFight Thanks for testing and reporting back. Great that Keycloak OAuth is now working okay. I followed your suggestion and added a simple URL path validation on double slashes. Any errors are reported in /opt/savapage/server/logs/server.log and Application Log. The fix is present in SavaPage Release Candidate 2020-10-15 or later.

1 Like

sorry for reviving this thread. I couldn’t figure out how to make a new one.

The Keycloak plugin uses a (now) oboslete url path. Newer Keycloak instance don’t need the /auth/realms/{REALM} base anymore, now it’s /realms/{REALM}/

Hi @seb, welcome to SavaPage! Thanks for pointing out this issue. It’s resolved in the latest release candidate. You can set keycloak.oauth.realm.path=realms in your savapage-ext-oauth-keycloak.properties file. Can you have a try?

@rijkr I tried. Thank you! Unfortunately, it seems to not work for me. Seems the plugin still loads the default realm config. I tried to find it in the log, but might have looked at the wrong place

2023-01-19 14:47:42,858  INFO SpInfo:119 - Loaded plugins [1]
+------------------------------------------------------------------------+
| [org.savapage.ext.oauth.KeycloakOAuthPlugin]
| Authorization: https://<keycloak_url>/auth/realms/<REALM.NAME>/protocol/openid-connect/auth?response_type=code&client_id=savapage&redirect_uri=https%3A%2F%2F<url>%2Fuser%3Fsp-oauth%3Dkeycloak&scope=openid
+------------------------------------------------------------------------+ [main]

Let me know if I can look for something or if I did the installation wrong (I downloaded the new installer and ran it, that’s what I remember worked for previous installations)

The config I changed (triple checked ^^) to:

/opt/savapage/server/ext/savapage-ext-oauth-keycloak.properties:

keycloak.oauth.realm.path=realms

@seb Please contact us at support@savapage.org so we can discuss details there and report the conclusions here.