Issue with Group Aggregation via SCIM – Missing groups Attribute in User Object

IdentityIQ (IIQ) IIQ Discussion and Questions
, , ,
1

Which IIQ version are you inquiring about?

8.4p2

Please share any images or screenshots, if relevant.

[Please insert images here, otherwise delete this section]
image
image

Please share any other relevant files that may be required (for example, logs).

Share all details about your problem, including any error messages you may have received.

Dear Experts,

I’m encountering an issue with group aggregation in SailPoint IdentityIQ (IIQ) using a SCIM endpoint. In the current user schema returned from the SCIM /Users/{id} endpoint, the following attributes are available:

  • active
  • id
  • name.familyName
  • name.givenName
  • preferredLanguage
  • userName

However, there is no groups attribute returned for the user object.

Problem:

When I try to define groups as an entitlement by using the groups attribute in the User object and set it as a Managed Attribute, it doesn’t work because the groups attribute is not returned by the SCIM endpoint — it’s missing in the response.
also receive this error during group aggregation:

missing managed attribute: group null null

Additionally, in the Group object, I set id as the identityAttribute. But when I aggregate, the Group object Atrribute in the Entitlement Catalog appears empty. I

This seems to happen because the attribute used as the identityAttribute does not return any value.

The scim server is not 100% scim standard,as we habe only the two defined enpoints in scim server /Users and /Groups

My Question:

Does the customer need to update their SCIM /Users endpoint to include a groups attribute in the response (e.g., a list of group names or IDs the user belongs to) ?refering to SCIM RFC groups its not mandatory Attribute on User endpoint

My goal is to define a working identityAttribute for group object so that:

  • Entitlements appear in the Entitlement Catalog,
  • I can assign group entitlements to IT Roles,
  • And group membership is accurately mapped to users.

Any advice on the best solution or configuration approach would be greatly appreciated.

2

The issue was due to attribute group in the user schema of the scim 2 , so instead of groups should be group. without (s)

3

Hi @Tarek_ICC_AT

I’m currently working on connecting to the Persona application via the SCIM 2.0 connector, and I’ve run into something I’d like your input on.
I noticed that the /Users endpoint response does not include any groups attribute. I confirmed this by checking the SCIM response using Postman. However, when I call the /Groups endpoint, I do see member information listed under each group.
Was this the same behavior you observed during your integration? I tried updating the schema mapping by removing ‘s’ from ‘groups’, but it didn’t seem to have any effect.
In your case, was the groups information actually present in the /Users response but under a different attribute name like ‘group’, which prompted you to update the schema mapping? In contrast, in my situation, there’s no group-related data in the /Users response at all.

4

Hey @ratachari,

Have you found a solution for the Persona issue you were running into? We are facing the same problem. Thanks!

5

@abusse
We had to implement a workaround. We created a customization rule that checks whether the account is a member of any Persona groups. If so, it captures those groups and manually sets the “groups” attribute on the account.

To make this work, group aggregation must run before account aggregation. This ensures that updated group memberships are available, and then during account aggregation, the customization rule updates the accounts with the correct “groups” attribute.

6

Could you please help me with the code you used for Persona? We’ve been stuck on this issue for several days. You can remove or mask any company-specific details, just the code structure would be really helpful.

7

@prakash95

Below is what I’ve implemented. Hope this helps you resolve the issue.

  1. Update jsonPathMapping in the application xml to store user Ids under the groupMembers attribute for each group.

2. Include the groupMembers schema attribute under the Group object (not Account).

3. Run group aggregation to update all group objects with the new groupMembers attribute, which now contains all the user Ids belonging to each respective group.

4. Created below account customization rule for the Persona application

import sailpoint.object.QueryOptions;
import sailpoint.object.Filter;
import sailpoint.object.ManagedAttribute;
import java.util.List;
import java.util.ArrayList;
import sailpoint.api.IncrementalObjectIterator;

QueryOptions queryOptions = new QueryOptions();
Filter appNameFilter = Filter.eq(“application.name”, application.getName());
queryOptions.addFilter(appNameFilter);

List<String> addGroupsList = new ArrayList();

IncrementalObjectIterator<ManagedAttribute> iterator = new IncrementalObjectIterator(context, ManagedAttribute.class, queryOptions);

while(iterator.hasNext()){

ManagedAttribute mngdAttrObj = iterator.next();
List groupMembersAttrvalue = mngdAttrObj.getAttribute("groupMembers");

if(groupMembersAttrvalue!=null &amp;&amp; !groupMembersAttrvalue.isEmpty() &amp;&amp; groupMembersAttrvalue.contains(object.getStringAttribute("id"))){
  addGroupsList.add(mngdAttrObj.getValue());
}

}

if(addGroupsList!=null && !addGroupsList.isEmpty()){
object.setAttribute(“groups”, addGroupsList);
}

return object;

  1. Run account aggregation which triggers the above customization rule. The rule scans through the group members and manually updates the groups attribute on each account.

6. Configure a sequential task with group aggregation being first, followed by account aggregation. This sequence ensures that the latest group membership information is first updated in the groups, and then reflected correctly on the accounts when the account aggregation executes the customization rule.

Our user base is relatively small, so performance has not been an issue. However, if your environment has a larger user base, I’d suggest optimizing the logic for efficiency while keeping the same approach.