Redirect user registration to Keycloak?

Help / Discuss
#1

Hi,

I am testing the OpenID Connect Authenticator with XWiki and it works nicely. Clicking ‘Log-in’ redirects me to Keycloak for login, which then sends me back to XWiki.

When I click ‘Register’ I’d like the same flow: to Keycloak and back again. But currently I get the standard XWiki user registration form. This won’t work, as the whole point of OIDC auth is to keep users externally.

What I’d like is a registration / signup form that makes OIDC an option. For instance, how Discourse does it (screenshot from https://forum.xwiki.org):

image

or Zulip:

image

I assume this isn’t possible today. Is it tracked anywhere as a feature request? Should I raise a ticket on jira.xwiki.org/projects/OIDC/issues/OIDC?

Technically it seems feasible: Keycloak’s signup page supports redirects, so all that’s needed is some way for the OIDC plugin to hook into the ‘Register’ link, redirect to Keycloak, then redirect back to a page that does a ‘sign in’.

Thanks!

#2

Hi Jeff! I don’t have the answer. @tmortagne should know more about this since he wrote this OIDC feature.

What I know is that we had this contributed extension https://extensions.xwiki.org/xwiki/bin/view/Extension/Social%20Login%20Application. I don’t think it has an OIDC option though and I don’t know how well it works TBH (just noticed that the latest version of this extension uses socialauth 4.12 which is very old).

That should be a safe bet and at worse we’ll close it if it already exists (but I doubt it does).

#3

There indeed seem to exist the some work to include in the OIDC protocol the support for creating users, unfortunately it’s still a draft (see https://openid.net/specs/openid-connect-prompt-create-1_0.html) so I fear it’s not going to be implemented by any OIDC provider right now.

Another problem is that currently the XWiki registration is not really extendable so it would require some work on XWiki side to allow an extension to replace the registration process by its own.

What you can do in the meantime is to create and customize the XWiki.XWikiRegister page to put whatever you want in it but I guess it will require some knowledge to integrate the Keycloak registration form in it.

#4

Thanks for info, and pointer to XWikiRegister. I might have a go at a KeycloakXWikiRegister class. All it has to do is provide a link to Keycloak with a redirect URL back to XWiki - and then once redirected, use OIDC to log the user in.

There is also https://github.com/tdudgeon/xwiki_authenticator_keycloak which (I guess) could be configured to intercept bin/register/XWiki/XWikiRegister as well as bin/login/XWiki/XWikiLogin. I’d be interested to hear people’s opinions about the pros and cons of the integrated vs. servlet filter approaches.

For comparison, authentication is something wiki.js does brilliantly, through the use of Passport.js. It’s sad XWiki doesn’t(?) use an equivalent external auth library like Spring Security.

#5

I agree. I discussed briefly the idea of using Apache Shiro a while back in https://markmail.org/message/fvqkpkif4g3rpjht but nothing has been done. Using a well-known auth framework is a must in the future, and then deprecate XWiki’s proprietary solution in favor of it.

#6

There is various security frameworks in Java and we propose every year a GSOC project to implement support for PAC4J but it does not seems to interest many students so far :slight_smile:

#7

Indeed I had forgotten about this. TBH I don’t think it’s a GSOC job, sounds too complex and too important to leave it to GSOC (whoever implements it will likely go away after GSOC is over). It’s something the core devs should take the ownership of IMO. It’s just that we haven’t put this as a priority vs other things.

#8

At this point, everytime we’ve used OIDC it was to force authentication (whenever it is used) using OIDC. In this case the register page is not used at all and should be deactivated. When the login link is clicked the account is automatically created in XWiki based on OIDC taking for granted that an account already exists in the OIDC provider.

If I understand correctly your use case is one of a public wiki with a login form which would support both local login and OIDC login. Is this your use case ?

What is needed there is not necessarily that complex. It would be to add one button on the register page that would launch the login process for OIDC. If I’m correct in XWiki we can only configure one OIDC provider. Currently the XWiki register page lacks some UI Extensions point that would allow the OIDC extension to add the buttons there.

#9

Yes, actually - I’m setting up a public trial instance at https://xwiki.goodbyeserver.org, and wanted a “Sign up or log in with Github” page.

It seems architecturally daft for every webapp to implement login/signup/signout themselves (even wrapped in a library like Passport.js). Auth should be delegated to an external webapp like Keycloak, which can then enforce 2FA, and allow login via internal LDAP, external OAuth or whatever.

So I set up Keycloak and created a sign up or log in with Github" page, and then hit the problem of getting XWiki to redirect to that page when users click ‘Register’.

As you indicate, self-registration is rather a niche requirement, important mainly to public wikis. Everyone else doing OIDC just needs a way to disable the ‘Register’ link.

Perhaps all that’s needed is a registration_link setting in xwiki.properties:

registration_link = {baseurl}/bin/register/XWiki/XWikiRegister?xredirect={origin}
## To disable the 'Register' link, set a blank value:
# registration_link =
## To redirect to Keycloak for external auth
# registration_link = https://keycloak.goodbyeserver.org/auth/realms/goodbyeserver/protocol/openid-connect/auth?client_id=account&redirect_uri={origin}&response_type=code&scope=openid

Go down this path any distance and you’ll end up with a library like Atlassian’s Seraph, which is a Java API + servlet filter that webapps can use to make auth pluggable. Seraph is open source - adopting it would get XWiki instant compatibility most SSO systems (Okta, Onelogin, Ping, CAS, etc).

#10

Blockquote
Everyone else doing OIDC just needs a way to disable the ‘Register’ link.

This is actually much simpler ! You just need to uncheck the register right from the rights interface. Either “deny” it or add the right only to admins. The link to register will go away from the UI. It won’t stop the creation of new accounts when they are coming from the SSO authentication.

The real issue here is the need for a registration on the KeyCloak service. As mentionned by @tmortagne, there does not seem to be good APIs to register a user on OIDC, and no way to know where the user should be sent for a registration on KeyCloak. So in the end the only way is the send to the login screen and there the SSO server can present it’s own registration method.

What you could then do is rename the “login” link to show “Login/Register” instead… This can be done by a translation change in a translations page. It would have to be done in each language activated on the wiki though.

#11

Yes it’s probably what makes the most sense as an entry point (provided that the OIDC provider expose a way for the user to register and not just login but it’s often the case).

#12

I’m interested to hear where you’re thinking to go here.
Most security frameworks I heard about are “anchored” in some core technology and it’s difficult to take them outside; that’s because you want the UIs to be predictable.

  • OpenID works well because it just does user authentication; registration is not entirely planned (or will not be).
  • Spring Security or the like is very tight integrated into java… you’re left to think of all the UIs (so you become quickly proprietary).
  • Isn’t CAS at this level?
  • OAuth works well in a more abstract case and enables concepts to add other (web) systems’ functions. I believe that this is the direction an abstraction should go to. The systems that wiki.js described all base on OAuth apparently.

I guess the essence of this thread is, however, that any such auth framework should include a tuning for registration. I do not know of a better way than modify XWikiRegister (or do this in an equivalent manner using, say, a JS-extension).

paul