Hi Team!
Over the last two months, we have discovered multiple bugs in the SCIM 2.0 SaaS connector.
(CS0231895, CS0236955, CS0236448, CS0231593, CS0228618)
One of them, CS0231895, is related to provisioning multiple groups.
When we create a role with an access profile with multiple groups belonging to a SCIM 2.0 SaaS source and then request this role, we get an error depending on the specific application that we have connected to.
Example application 1:
Example application 2:
It turns out then when we request this role, during provisioning, IdentityNow tries to call the following URL: {{base_url}}/rest/scim/v2/Groups/eaf42466-b87b-49fd-9fa0-4e6c89822a28,878e0a4b-e32a-456c-a1f5-f956bd732334,cc48ba21-2a4f-40f2-930b-e979c6ed87cb
Notice how the group UUIDs are separated by commas. This will not work in a SCIM 2.0 URL.
Based on this it seems to me that the code that SailPoint has something like ..../scim/v2/Groups/$plan.groups
When there is only one group, there is no issue, but when multiple groups are given, it fails.
The fact that the two applications give different errors is because of they have a slightly different (order of) input validation. One application will directly check if the given value (which is actually multiple values connected with commas) does exists as group ID. The other one will first check if the given value matches a UUID-length criteria before checking if the group exists.
Given that we have noticed this issue on different SCIM 2.0 SaaS source applications, we think that others might have this issue as well.
All in all I strongly suggest to perform some more functional testing on the SCIM 2.0 SaaS connector.