I’m currently configuring SSO using OIDC with Azure AD / Entra ID. I have successfully established the integration and can confirm that claims are being received and mapped correctly.
The issue I’m running into is with setting the .pyAccessGroup property.
For example, I receive a groups claim that contains an array value, for a single role we would have something such as:
[AD_Role_Name]
If I map this claim to .pyAccessGroupsAdditional, the value is populated successfully. However, I have not been able to successfully map a value to .pyAccessGroup. My goal is to derive the primary access group from the groups claim and populate .pyAccessGroup during operator provisioning.
Based on the documentation, it appears that the data page D_pzSSOAttributes should contain the OIDC claim values and can be used to process them during authentication. However, in my environment this data page is always empty, even though the claims are clearly available and can be referenced in the Authentication Service mappings.
My questions are:
Is there any additional configurations required for D_pzSSOAttributes to be populated?
Is there a recommended approach for deriving and setting .pyAccessGroup from an OIDC groups claim during the authentication execution?
Are there any special considerations for this functionality when running on Pega Cloud?
I also went through the mission on Pega Academy, but the configuration hardcodes the mapping of .pyAccessGroup, which is not ideal for organization implementations. Any guidance or examples would be greatly appreciated.
Because the claim returns an array value, it maps successfully to .pyAccessGroupsAdditional. However, since .pyAccessGroup is a single-value property, the standard mapping expects a single scalar string, which is why a direct mapping from the array claim is failing.
To resolve this, you create a requestor scope data page and reference it in the field in attached image. Inside that data page, keep the source as data transform or activity and inside it reference the D_pzSSOAttributes data page to get the values of incoming claims and map them to your requestor data page. Now, try mapping the pyAccessGroup field using this requestor data page in the mapping tab. If it is still not working, set it in the Post Authentication Activity.
Adding to @VVNagaSaiN , pyAccessGroup is a single-value property, while the groups claim from Entra ID is typically multi-valued. Because of that, the claim cannot be mapped directly to pyAccessGroup in most cases. Instead, the groups claim should first be processed to derive one primary group, and then that derived value can be assigned to pyAccessGroup.
A few points to consider:
If you can successfully map the claim to .pyAccessGroupsAdditional, that is expected because it supports multiple values.
For .pyAccessGroup, you need to reduce the incoming array to a single value based on your business rule.
A common approach is to use a requestor-scope data page, data transform, or post-authentication logic to read the incoming OIDC claim values and determine the primary access group.
If multiple groups are returned, you should define a clear precedence rule, for example:
first matching group from an allowed list,
highest-priority group,
or a lookup-based mapping from external group name to Pega access group.
Regarding D_pzSSOAttributes, in some environments it may not be populated as expected even though the claims are visible in the authentication mappings. In that case, I would not rely on it as the only source of truth. It is safer to derive the value from the claim data available during the authentication flow itself, or in a post-authentication activity if needed.
Also, please make sure Microsoft Entra ID is configured to actually emit the groups claim in the token. If the group claim is not present in the token, Pega can only map what it receives.
