We’ve 2 types (group + permission) of entitlements for “Web Services SaaS Connector” based source.
We’ve set-up 2 Entitlement Types (group + permission) + 2 Group Aggregation Operations (one for group (Group Aggregation) and another for permission (Group Aggregation - permission)) in Source Configuration.
But Entitlement Aggregation is not bringing “permission” type entitlements in source while we can see them under “Admin > Access Model > Entitlements”.
Due to this issue, we are unable to add permission type entitlements in Roles/Access Profiles as we can’t see them listed while creating Roles/Access Profiles.
But for us, it’s already been 2 days, and it doesn’t seem to get fixed.
Another issue we’ve observed is that:
If we aggregate only “permission type” entitlement, nothing is listed under source entitlements, but we see these entitlements listed under Admin > Access Model > Entitlements.
If we aggregate all types of entitlements, only group entitlements are listed under source entitlements but if we download .csv export of source entitlements, we can see “permission” type entitlements listed along with “group” type entitlements. Also, we can see all these entitlements (“permission” + “group” type) under Admin > Access Model > Entitlements.
Hi @SailPoint_Learner Are you able to aggregate Permission type Entitlements using a REST tool such as Postman?
Also, it is curious that you can’t add Permission Entitlements derived from Account Aggregation into Access Profiles if you can see them under Admin > Access Model > Entitlements. That is standard functionality. Do you have multiple sources for the target system?
You mentioned Group Aggregation as your Operation Type. Are you using the standard Group Aggregation for both group and permission?
The standard Group Aggregation will only grab the default “group” entitlement type that is automatically created when you create the source. When you add another Entitlement Type, you will see a few new Operation Types in HTTP Operations. If you named your 2nd entitlement type “permission”, then you will see “Group Aggregation-permission” in the Operation Types.
Can you confirm that you are using that new Operation Type?
Yes, we can aggregate “permission” type entitlements using Postman.
We can derive “permission” type entitlements from “Account Aggregation” and/or from “Entitlement Aggregation” but they are being listed only under Admin > Access Model > Entitlements. We can’t see them in source entitlements, nor can they be listed while creating roles/access profiles.
We had one source for same target till yesterday, we’ve created one more today to verify if old source was causing issue but irrespective of source, issue remains same.
Have you checked what the entitlements look like from the ISC API? I’m afk at the moment so can’t list exact syntax, but check source to entitlement linking
We’ve checked Entitlements (group + permission) through ISC API {{baseUrl}}/beta/entitlements and we don’t see any difference (apart from attribute (defined in Account schema), name (actual name of entitlement from target), value (unique value for entitlement from target), id (SailPoint generated), attributes (actual name of entitlement from target)).
We’ve observed one more thing:
If we aggregate only “permission type” entitlement, nothing is listed under source entitlements, but we see these entitlements listed under Admin > Access Model > Entitlements.
If we aggregate all types of entitlements, only group entitlements are listed under source entitlements but if we download .csv export of source entitlements, we can see “permission” type entitlements listed along with “group” type entitlements. Also, we can see all these entitlements (“permission” + “group” type) under Admin > Access Model > Entitlements.
To aggregate “group” type entitlements: We are using standard “Group Aggregation”
To aggregate “permission” type entitlements: We are using “Group Aggregation - permission”
Is your “permission” attribute on the account schema marked as an entitlement? I noticed that marking a string as an entitlement brings up the following warning: