How to migrate existing Qlik users to IDP-Based users using Keycloak?

[FarshadNour]

Hello everyone,

We're in the midst of transitioning from a ticket-based solution to an Identity Provider (IDP)-based solution in our Qlik Sense environment, leveraging Keycloak for authentication. As of now, our process involves users being redirected to and authenticated by the IDP.

Post successful authentication, they are redirected back to Qlik Sense, leading to the creation of a new user profile in the Qlik Management Console (QMC) under the 'users' section.

Our current challenge is identifying a method to transfer or synchronize user-specific data, such as apps and bookmarks, from the original user directory to these newly created ones. Note: 
I've included a screenshot below to give a clearer picture of our current setup.

 
Do you have any suggestions or best practices on how to achieve this? Your guidance would be greatly appreciated.

Thank you in advance.

Qlik Sense Business

F.N

[Levi_Turner · Accepted solution]

Broadly you need to make sure the user is identified the same. You mention Keycloak and not the method (SAML, JWT, OIDC, etc), but in any case the IDP (Keycloak) will need to send at least a User ID claim to match the Ticketing User ID pattern.

• SAML --> SAML Attribute for user ID
• OIDC --> sub

That ought not be too hard. For the User Directory element, this can be handled on the Virtual Proxy config:

• SAML --> SAML Attribute for user directory
• OIDC --> realm

These two can be hard coded. For example in this config, we are parsing the samAccountName claim from a SAML Identity Provider to identify the user's ID but are hard-coding the domain to be QLIK-POC:

[FarshadNour]

Hello Levi,

I appreciate your response!

Just to clarify, we are implementing OIDC and using Keycloak as our IDP, I apologize for not specifying this earlier.

In accordance with your advice, I've modified the realm (user directory) to match that of our pre-existing users. However, this has led to the new user (who logged in via SSO) becoming inactive. Interestingly, this issue doesn't occur when I use a different realm.

Could utilizing a script to match users in the Qlik Sense Repository Service Database (QRS) be a viable option?

I am open to hearing from anyone who might have a different perspective or alternative implementation ideas. Please feel free to contribute.

[Levi_Turner]

My assumption is that the user is marked as inactive because the sub claim that you're using is still sending the old user id (b913...) and that you're using a User Directory Connector to fetch attributes for users from that domain (HP). The net effect is that the OIDC Virtual Proxy is sending a user id which is not found on the User Directory and thus is marked as inactive. You'll want to ensure that either the sub claim from Keycloak matches the old style user ID (benA) or send another claim which has this old style user ID and change the sub claim in Qlik to match this new claim's name.

[FarshadNour]

Interesting perspective, Levi!

I don't currently have the ability to interact with the SSO Team to generate a different claim or modify the sub. However, I aim to establish contact with them later in the week and I will share my findings.

There appears to be a lack of information readily available on the internet relating to this specific issue and SSO in general. The distribution of this knowledge could greatly assist the entire community.

I will get back to you as soon as I have updates about new implementations related to these issues.

[FarshadNour · Accepted solution]

Hi Levi,

I've made significant progress in migrating users to our new OIDC-based authentication system with Keycloak. Your idea of mapping the 'sub' to the new claim (benA) in the virtual proxy was spot on.

However, upon consulting with our IT department, I learned that "benA" is no longer the preferred username format and it wouldn't be possible to pass it as a claim.
Additionally, I observed that the realm in the Qlik Virtual Proxy aligns with the "UserDirectory" column in the Qlik Sense Repository Database.

To migrate existing Qlik users, we had two options:

1. Start afresh: Create new user accounts with no historical data, including apps, licenses, bookmarks, etc. Given our users' extensive history with Qlik, this wasn't a popular choice.
2. Manually modify the "UserId" using a SQL command in the Qlik Sense Repository Database

I chose the second approach and it proved successful! After reviewing the QRS database, I found that each user's unique identifier in the "Users" table was the primary key, and the "UserId" wasn't tied to any other columns.
I executed a simple SQL statement to modify the UserId, UserDirectory, and UserDirectoryConnectorName fields:

UPDATE public."Users" SET "UserId" = 'b9134e3-ke1545-ercd98', "UserDirectory" = 'KC', "UserDirectoryConnectorName" = NULL() WHERE "UserId" = 'BenA'

For context, this Qlik community guide  provided some insights, even if it wasn't directly related to my issue.

By applying this method to all user accounts, everything transitioned smoothly. All user data like bookmarks, apps, roles, and privileges remained intact. This solution has been operational for about two weeks now, and everything is running smoothly.

Thank you, Levi, for your guidance. I hope sharing my experience will aid others in the future.

F.N.