Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi,
I will describe the situation shortly before asking the question:
- Qlik cloud environment + entra ID identity provider (OIDC)
- A mapped claim is configured in the Identity provider settings: claims mapping for 'groups' = 'extensionattribute2'
- https://CUSTOMER.eu.qlikcloud.com/api/v1/diagnose-claims does show this mapped claim correctly
- Changing EntraID to have the extensionattribute as a role is not possible, the attribute can have up to a thousand different values and this will clutter the EntraID environment.
- We use this extensionattribute value for Section Access in an app (email is not viable as this changes a lot). Section access therefore is based on GROUP
- In the settings 'Creation of groups' is disabled
Untill recently, this situation worked well. But a few weeks ago this stopped working.
However, section access based on group does work if we use a groupname from the default claim (a role in entraID).
A possible reason could be that default user roles in EntraID are now shown in the extra claims:
https://CUSTOMER.eu.qlikcloud.com/api/v1/groups shows multiple roles / grups from EntraID. Unfortunatly I do not recall if this was the case before.
My understanding however was that groups (roles in entraID) in the normal claims are overruled by mapped claims that you set up in Qlik cloud (in the Identity provider login).
Is this correct, or did this change recently?
Or are you forced to not send any roles in the OIDC claim if you want to use claimed mapping on 'Groups'?
I would like to know which way to move forward! Hopefully you can help me in this regard.
Thanks in advance!
There is a lot going on here!
1) Why would email for an identity change frequently?
2) Why are you concerned with "roles" if you are already trying to use "groups"?
2a) There are "roles" in Qlik Cloud that do not equate to "roles" in Entra ID.
3) If you are trying to limit the groups that are used by Qlik Cloud, have you looked at using SCIM and when working, turning off the groups/extensionattribute2 claim from the interactive login Entra ID app?
Thank you in advance for sharing your experience, I hope we can collaboratively clear everything up!
Hi @jprdonnelly
First of all thanks for your reply! I will try to give you a bit more information:
1. Emails can change because the customer has different employees login to the portal. The issue is about Section Access to an app. We do not want to reload the app before a new user can enter, and also we need the extensionattribute to reduce their data. Thats why we use GROUP in section access here.
2. We do not need the EntraID roles or Groups here. We just want to map 'extensionattribute2' to Groups, so we can use this for section access. Thats why I have the settings 'Creation of groups' off (see picture). The main issue at the moment is that the mapped claim groups do not work, while the original groups do work. The extensionattribute cannot be added as group in EntraID however, there are way too many distinct values on this field.
3. We could possibly work out something on the EntraID side yes. But we had a working environment for a year.
My main question therefore remains:
- If you use claim mapping for Groups, does it overrule the groups in the normal claim?
We did some further research.
Because the 'create groups' function has been enabled for an hour before, a lot of groups were created. Using Qlik CLI we removed all these groups.
However, I still cannot execute section access based on the group from mapped claims.
What does work, is to use the generic qlik group 'com.qlik.Everyone' that you can see with:
- https://CUSTOMER.eu.qlikcloud.com/api/v1/groups?systemGroups=true
- =GetUserAttr('userGroups') function in the front end also shows this group (and not the number from the mapped claim!)
Questions therefore are:
- Does Qlik have an issue with a numeric value in a text field as mapped claim? This has always been a text field.
- In what order does Qlik look at the following types of groups in cloud?
IDP groups - Qlik generic groups - mapped claims groups
It would make more sense that a mapped claims group overrules the other groups OR that it would add aditional groups to its array of memberships.
Has something changed in this regard?