Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
andy-d
Partner - Contributor
Partner - Contributor

OIDC authentication - mapping JWT claims to user attributes

I have got basic OIDC based authentication up and running on Qlik Sense on Windows by following this guide: https://help.qlik.com/en-US/sense-admin/May2021/Subsystems/DeployAdministerQSE/Content/Sense_DeployA...

Users are able to log in and are created in the Qlik user directory but I now want to populate user attributes (preferably custom properties) based on specific JWT claims in order to use them in security rules.

My assumption is that this is done via the "OIDC attribute mapping" section, where "OIDC attribute" = JWT claim and "Qlik Sense attribute" = user attribute name, but nothing is added to the user record. I have tried setting both standard user attributes and custom properties (both with and without "@" at the front) with no luck.

Is there a specific syntax to be aware of? Does anyone have a working example?

9 Replies
Damien_Villaret
Support
Support

Hello @andy-d 

That would be the same principle as for SAML attributes, you can't visualize them in the QMC but they are available as session attributes for the time of the session

https://community.qlik.com/t5/Knowledge/Security-Rules-Fail-For-SSO-SAML-Users-and-The-Group-or-Othe...

 

However, in Qlik Sense August 2021, you have a checkbox in the virtual proxy settings to persist those attributes in the Qlik Sense repository and by doing so, you will be able to visualize them in the QMC in the "Users" section

If the issue is solved please mark the answer with Accept as Solution.
andy-d
Partner - Contributor
Partner - Contributor
Author

Thanks @Damien_Villaret - I hadn't got as far as testing them with security rules as I assumed they weren't being set.

I'm running August 2021 patch 1, but can't seem to see the checkbox you mention - would you mind pointing out where I can find it?

Damien_Villaret
Support
Support

Hello @andy-d 

I just double-checked, the feature to persist attributes is still in beta in August 2021. It's supposed to be publicly released in November 2021.

It can be enabled in C:\Program Files\Qlik\Sense\CapabilityService\capabilities.json if you want to test it.

add "SessionDataPersistanceEnabled" set to "true":

[
	{
		"contentHash": "2ae4a99c9f17ab76e1eeb27bc4211874",
		"originalClassName": "FeatureToggle",
		"flag": "CAO",
		"enabled": true
	},
....,
	{
		"contentHash": "2ae4a99c9f17ab76e1eeb27bc4211874",
		"originalClassName": "FeatureToggle",
		"flag": "SessionDataPersistanceEnabled",
		"enabled": true
	}
]

 

Otherwise, without attribute persisted, you can still create security rules

user.environment.attributename=...

but you won't be able to visualize which user has which attribute in the QMC.

If the issue is solved please mark the answer with Accept as Solution.
andy-d
Partner - Contributor
Partner - Contributor
Author

Hi @Damien_Villaret, I tried adding the line you suggested to capabilities.json and restarting all Qlik services, but I still do not see an obvious checkbox to persist the attributes - I wanted to enable this to make it obvious whether they are being set correctly or not.

Based on our discussion on the support ticket, you would not expect the QS attribute to be logged, only the original JWT claim, however since the log is simply printing the value of the X-Qlik-Security header, if the QS attribute is not included there, how is it signalled?

As suggested, I created a security rule of the form ((user.environment.<attributename>="<value of JWT claim>")) to give access to a particular stream and do not have access when logging in via OIDC. As a test, I changed the rule to be ((user.name="<Username>")) and it worked.

How can I conclusively check whether the QS attribute is being set?

Damien_Villaret
Support
Support

Hello @andy-d 

Could it be that you forgot to restart the Qlik Service Dispatcher service as it's not dependent on the others ?
I just tested in my environment and the option appears

Damien_Villaret_0-1633080858826.png

It needs to be left UNCHECKED so that the attributes get persisted.

Then when you go to "Users" and click on the (i) (information) button, it should be listed there.

 

X-Qlik-Security header lists the incoming attributes and we can only assume it was converted to the correct Qlik Sense attribute name without attribute persisted.

((user.environment.tenantid="1234")) should definitely work in your work. 

and it would be ((user.tenantid="1234")) if the attribute has been persisted.

Please also make sure that attribute names and values are in the correct case, as they are both case-sensitive., as far I remember.

 

If the issue is solved please mark the answer with Accept as Solution.
andy-d
Partner - Contributor
Partner - Contributor
Author

Thanks @Damien_Villaret, I can confirm that I have that option - I didn't notice that it was new and was expecting a different  name.

Looking at the persisted user properties I now see a lot more attributes, however only the JWT claim used to map to the attribute is present, not the mapped attribute (essentially I see exactly what is in the X-Qlik-Security header in the logs).

Since the JWT claim is now persisted as part of the user data, I wondered if I could use that directly in the security rule, however since we are using Auth0 as our IDP which enforces a URL structure for custom claims (https://auth0.com/docs/security/tokens/json-web-tokens/create-namespaced-custom-claims) this doesn't seem to be possible (the rule editor complains about invalid characters).

As a side point, I don't think the custom claim format should be an issue? The guide in your original link shows an example which maps from a URL-format SAML attribute, and I am also unable to map standard claims (e.g. email) to a custom QS attribute.

It seems we have confirmed that the JWT claim is recognised by Qlik so it appears that the mapping to QS attribute is simply not working for whatever reason?

Damien_Villaret
Support
Support

Hello @andy-d 

Indeed, I can see the same problem, which is not optimal, especially for your use case where you have characters not allowed in security rules in the claim name.
Let me check with our R&D if that's something that is going to change with the feature going public.

If the issue is solved please mark the answer with Accept as Solution.
andy-d
Partner - Contributor
Partner - Contributor
Author

Thanks @Damien_Villaret, appreciate you following up with them - please let me know once you have any news. 

Damien_Villaret
Support
Support

Hello @andy-d 

Our R&D is currently investigating this issue as a potential defect (QB-7413)

We'll update you as soon as possible.

Best regards,

If the issue is solved please mark the answer with Accept as Solution.