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

[Nick_Asilo]

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.

Environment

Qlik Sense Enterprise on Windows November 2021 and later releases

Cause

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.

 

Resolution

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.

{"contentHash":"2ae4a99c9f17ab76e1eeb27bc4211874","originalClassName":"FeatureToggle","flag":"SessionDataPersistanceEnabled","enabled":false}

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.

[joachimbwise]

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.