ISC using a SCIM 2 Saas Source, but app has no groups endpoint?

Identity Security Cloud (ISC) ISC Discussion and Questions
, ,
1

We have ISC and have been asked to try and replace a SCIM setup that is currently setup with one using SailPoint ISC.

Currently, Entra is pushing accounts into an application. In that setup, a custom attribute is added that contains the role name (1 of three single possibilities).

This app does not support a groups endpoint, so everything is done via the user endpoint. (that additional attribute carries the user permission/role).

I have recreated the setup using the SCIM 2 Saas connector in ISC, and I am able to aggregate, and have even made that custom attribute an entitlement.

(I open the account page for an account off this source, and I see that separate entitlement section populated with the entitlement value).

I have checked the ‘skip groups’ option the source config.

I’ve made an access profile with that entitlement in it.

I’ve made a requestable role with that Access profile.

I’ve made a criteria based role with that access profile.

For the life of me though, I cannot get Sailpoint to push data for that attribute.

Do I need to include this custom attribute in the create account (provisioning policy?)

If so, where do I get the value from? (I.e. the entitlement name from the AP being assigned to the account would be the value)

At a loss here on how to do this via sailpoint.. Unfortunately, the entra documentation for setting up SCIM uses a simple/strightforward ‘expression checking groups’ to populate this attribute.

Recreating that mechanism in Sailpoint seems very difficult.

2

It seems you’d have more control over what happens if you use the web services connector instead of the OOB SCIM connector, would you not?

3

Hi,

Just because the custom attribute is aggregated as an entitlement doesn’t automatically mean ISC will provision it back to the target application.

A few things to check:

  • Is the custom attribute included in the account schema as a provisionable attribute?
  • Is it mapped in the Create/Update Account Provisioning Policy?
  • Does the SCIM endpoint support updating that attribute via POST/PATCH operations?

If the application uses a custom SCIM attribute to represent roles, you’ll typically need to explicitly populate that attribute during provisioning. ISC won’t automatically take the entitlement name from an Access Profile and write it into a custom account attribute unless you’ve configured that mapping.

I’d also verify the provisioning plan and connector logs to see whether the attribute is even being included in the outbound SCIM payload. If it’s missing from the payload, the issue is likely in the provisioning policy/schema configuration rather than the entitlement setup itself.

One question: when you request the Access Profile or Role, do you see a provisioning event generated for that entitlement, or is ISC only granting the governance access without producing any account update? That would help narrow down where the gap is.

4
  • It is in the account schema, and we have a custom entitlement type set to that name. ISC does show it in the entitlement section, when looking at an account on the source.
  • It is not in the create account provisioning policy
    • I can easily put it in the create account provisioning policy, but I don’t know how to give it a value. How do I get access to the incoming entitlement? (I have an Access Profile that has one of the entitlements in it, that AP is in both a requestable role, and a criteria-based role). how does the incoming new entitlement get valued in the create-account provisioning policy?
  • The custom attribute doesn’t seem to be in the outbound payload, but I believe that might be due to it not having a value, and it getting trimmed?

One question: when you request the Access Profile or Role, do you see a provisioning event generated for that entitlement, or is ISC only granting the governance access without producing any account update? That would help narrow down where the gap is.

Using Sail con logs, I only see the Op:Create instructions for the attributes that are in the create account provisioning policy. This app actually allows users to be created with no entitlements (a user is created downstream, just without that attribute, can’t do anything). If I need to add this custom attribute to the create account provisioning policy, I haven’t that makes sense its not in the log.

This is what the instructions say to do when setting SCIM up using entra.

On the Edit Attribute List page, create a new attribute for the role property using the following string:

urn:ietf:params:scim:schemas:extension:workspacePermission:2.0:User:role

On the Edit Attribute page, configure mapping for the attribute, then save the changes.

  1. In the Mapping type list, select Expression.

  2. In the Expression field, enter the following:

    IIF(Instr([appRoleAssignments], "ADMIN", "", "")>"0", "ADMIN", IIF(Instr([appRoleAssignments], "MEMBER", "", "")>"0", "MEMBER", II

To make this equivalent in ISC, I can’t figure out how to grab on to the incoming entitlement, and then put a value on that custom attribute. (what the expression is doing)

I really appreciate your help/guidance!

5

It seems you’d have more control over what happens if you use the web services connector instead of the OOB SCIM connector, would you not?

would I have the same issue with not knowing how to I populate the custom attribute? That’s the thing I’m not understanding.. how do I get a handle/paramter that has the planned entitlement?

It’s strange, I would have thought Groups as an attribute on the user would be fairly common.. There definitely other apps out there that have a User → Group reference, not just a Group → User one.

Is it not possible to provision a User with a groups attribute on it? (thats really all I’m trying to do.. just that my attribute is not called groups.. )