Skip to main content
Announcements
Introducing Qlik Answers: A plug-and-play, Generative AI powered RAG solution. READ ALL ABOUT IT!
cancel
Showing results for 
Search instead for 
Did you mean: 
FarshadNour
Partner - Contributor II
Partner - Contributor II

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

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.

qlikcome.PNG

 
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

 
Labels (4)
2 Solutions

Accepted Solutions
Levi_Turner
Employee
Employee

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:

Levi_Turner_0-1690295003838.png

 

View solution in original post

FarshadNour
Partner - Contributor II
Partner - Contributor II
Author

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. 

View solution in original post

8 Replies
Levi_Turner
Employee
Employee

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:

Levi_Turner_0-1690295003838.png

 

FarshadNour
Partner - Contributor II
Partner - Contributor II
Author

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.
qlichange.PNG

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
Employee
Employee

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
Partner - Contributor II
Partner - Contributor II
Author

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
Partner - Contributor II
Partner - Contributor II
Author

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. 

SBartschat
Partner - Contributor II
Partner - Contributor II

Hi there, i have a similar Problem migrating from Windows Authentication to Auth0 on Qliksense Server. 

The existing Username and UserID Structure is [Test].[User] .

 

I was able to create  a Database in auth0 for the existing Users and to Place the Username / Username into the  Auth0  username field.

 

I was able to configure a virtual Proxy for Auth0 which references to the existing user Directory.

Now i am a little bit lost how to reference in the virtual proxy to the Auth0 username for Name and User ID in Qlik. In the standard Auth0 transfers the Mailadress of the user for the name and the Auth0 User ID ( auth0|[ID] ) for the qlik user ID.

Naturally Qlik creates a new user when i login via the Auth0 login in the existing user directory. How do i reference to the existing users in the directory?

These are my current settings:

Auth0 SettingsAuth0 Settings

 

Thanks in Advance for the help!

 

 

 

Levi_Turner
Employee
Employee

Ensure that the existing user id is in the claim and reference the claim in the sub field. You may need to collaborate with your Auth0 folks to ensure that this value is sent. For example, with ADFS, you can send the userid as winaccountname rather than using the default user@domain.tld subject.

SBartschat
Partner - Contributor II
Partner - Contributor II

Thnak you very much! This got me in the right direction.

 

This is the Virtual Proxy configuration which works for me:VProxy SettingsVProxy Settings

"nickname" transfers the Auth0 Username to Qlik.