We are try to migrate from LDAP based accounts to OpenID ones.
For this I have configured, that the oidc.user.nameFormater result in the same user name as the ldap one.
But when user foo logs in via OIDC an new user foo-0 is created, instant of using foo.
When an new user bar comes, that was never logged in via ldap it will works.
So what must I configure, to prevent this? From my site it looks like, xwiki see that foo exits and create an new user instant of mapping.
Thanks
The OIDC extension uses the Issuer
and Subject
returned by the IdP (Keycloak) to identify a user object. I can’t tell you exactly why it does not link the OIDC and LDAP accounts automatically, but I have had to merge OIDC accounts before so I might be able to help you link accounts manually. Create a backup before you do this so you won’t lose data.
- Open the account page of an OIDC user and open the object editor on that page (you have to be in advanced mode, activated by typing “x+x+x+a”).
- You should have an entry for Objects of type XWiki.OIDC.UserClass on that page. Expand the entry and copy the
Issuer
and Subject
for later use.
- Delete the OIDC user.
- Open the account page for the same LDAP user and open the object editor.
- If an
XWiki.OIDC.UserClass
object already exists, skip this step. Otherwise, create a new class by entering XWiki.OIDC.UserClass
in the New Object
-Field at the top and clicking the Add
button.
- Enter the issuer and subject copied from the OIDC user and save the page.
- The user should now be logged in to the previous LDAP user when authenticating via OIDC.
You can also preemptively set this up for LDAP users that have not authenticated via OIDC yet. Create an XWiki.OIDC.UserClass
object for the user. Your IdP should priovide you a way to find the issuer and subject. For (modern) Keycloak the issuer is https://your.keycloak.tld/realms/REALM_NAME
. The subject can be found by opening the user details for the realm user in the Keycloak admin web interface and looking at the ID
field.
Hi @Vertganti ,
I can’t do this by hand, because we have so many users in the production wiki. At the test instance it will works.
So I need an automatic solution for it. Because I can’t tell all users to login into now wait for get doubled. And then wait for the fix.
You could use oidc.user.subjectFormater
to set the subject to a specific value - it uses the same syntax as the oidc.user.nameFormater
property you have already used. You might then be able to use a script to create the OIDC objects for all users using the information already present in the LDAP users. Unfortunately I don’t have a script for this that I can provide to you, but it should be possible to do it with a Groovy script or maybe even a Velocity script. See the Scripting Guide for some basic scripting info.
Changing the oidc.user.subjectFormater
make the problem only much worse.
Because now the user exits 3 times. 
You could create a script to batch-edit all existing user profiles, either a script that is executed inside XWiki using XWiki’s scripting API or a script that uses the REST API.
As Michael said (and I tried to express in my post above) you will have to additionally use a script to edit all users so they are linked - e.g. by adding an OIDC object to the users.
Unfortunately, the idea with the script is not practical for us. We would need a solution where this happens automatically as soon as the former LDAP user logs in via OpenIDC. I will submit a functional request. I have seen, that for this an ticket was already created.
Why does this need to happen the moment they log in? What’s the problem with adding the necessary information in a script?
The problem is that the user must not be logged in. But this cannot be guaranteed. As the ‘new’ OpenID user no longer exists after running the script change but is still logged in. And thus loses the changes he is currently working on.
Couldn’t you schedule the script to run at a time when you expect nobody to be using the wiki, like in the middle of the night?
Also, the WYSIWYG editor deals relatively well with users suddenly not being logged in anymore. You might have a problem with temporary uploads but apart from that, the user should simply get a prompt to re-login in another window and then saving should work again.