Skip to main content

Official Support Articles

Search or browse our knowledge base to find answers to your questions ranging from account questions to troubleshooting error messages. The content is curated and updated by our global Support team

NEW webinar Dec. 7th: 2023 Outlook, A Pivotal Year for Data Integration SIGN ME UP!

Access Issues and unusual behavior with SAML authentication after upgrade to November 21 or later

Showing results for 
Search instead for 
Did you mean: 

Access Issues and unusual behavior with SAML authentication after upgrade to November 21 or later

After upgrading to Qlik Sense Enterprise November 2021 or a later version, users accessing with SAML authentication may experience issues accessing Qlik Sense, lose their rights and permissions, or experience other unusual behavior.

However, performing a UDC sync and connecting with Windows Authentication works without issue.


Qlik Sense Enterprise on Windows November 2021 and later releases




Prior to the November 2021 version of Qlik Sense, the attributes from SAML authentication were not persisted in Qlik Sense and were only used and seen in the logs during session setup.

Starting with November 2021 a product enhancement was made to persist. This was done so that custom rules could be written to more easily take advantage of the SAML attributes.

The problem arises from the fact that many existing SAML virtual proxies map SAML attributes to existing attributes used by the UDC, such as the Group attribute.


This means that when a user accesses Qlik Sense using SAML the Group attribute from the UDC will be overwritten with the SAML attribute. So if these two attributes are not identical any custom security rules written based on the attributes from UDC will no longer apply to the user trying to access Qlik Sense.




There are several resolutions possible, but it is up to each customer to decide which is the best fit for them, primarily based on how much they are concerned with utilizing the attributes delivered by SAML.


1. Remove The Attribute Mapping From The Virtual Proxy


By simply removing the attribute mapping(s) from the virtual proxy settings you prevent Qlik Sense from overwriting the existing values pulled in by the UDC by not pulling in any values from the UDC.


2. Revert The Behavior And Disable Persistence


This is done by setting following flag to false in C:\Program Files\Qlik\Sense\CapabilityService\capabilities.json, followed by restart of services.



3. Modify Existing Custom Rules To Accept Both Formats


This option is fairly straightforward in concept, without modifying the virtual proxy or any configs this allows both formats to work if there is a discrepancy between what the UDC and SAML are providing.

For most organizations, this is the most convoluted and labor-intensive solution on this list, but it is a valid option and included in the interest of providing all the options possible.


4. Change The Naming Of The Attribute Mapping In The Virtual Proxy Settings


Instead of mapping to Group (to continue using the scenario from above), you can change the attribute name the values are mapped to, such as GroupSAML for example.


Since this now maps to a different attribute it will not overwrite the values brought in by UDC. This allows existing rules to work and can be used if you'd like to shift your custom rules to utilizing SAML attributes while maintaining a UDC synch to pull in users

Options 1 & 2 prevent SAML from persisting data and are perfectly fine if you do not plan to use the SAML attributes to determine access and rights.

However, if you want to utilize the SAML attributes in your custom rules and use them to dictate access and rights then options 3 & 4 are viable.

Labels (1)
Partner - Contributor II
Partner - Contributor II

Hi Nick! 

How would this work with Section Access, as the group-SAML attribute could be used both for security rules and Section Access. We are really struggling with making a custom SAML-attribute (that we map to group) to work with SA, it does however work fine with security rules (as an overwrite is exactly what we want).

Could you explain exactly where SA gets the GROUP and USERID-values from? We have tried many variants, and have not succeeded with either of them. The really confusing part is why USERID doesn't work as well. SA just fetches the ID from the Qlik user list, no? So it should not really care what source populated those users?

If you have access to support cases, our ID is 00053396.

Version history
Last update:
‎2022-06-13 02:38 AM
Updated by: