Web Service Connector: Is It Possible to Access Identity Attributes During Entitlement Removal?

Identity Security Cloud (ISC) ISC Discussion and Questions
1

Hello Experts,

I have a fundamental question regarding Web Service Connector provisioning in Identity Security Cloud.

When processing entitlement removal (revoke) in a Web Service Connector,
is it possible to access identity attributes (for example, lifecycleState or a custom attribute like deptCode) and include them in the outbound provisioning request?

This question is specifically about remove entitlement operations, not account creation or update.

I would like to understand whether identity attributes are accessible at all during entitlement removal in a Web Service Connector, or if this is fundamentally not supported.

Thanks in advance.

2

HI @jwshin

I’ve encountered this issue a few times before and have the same frustration. The only attribute that is passed into the provisioning plan is the native identity, which typically isn’t enough to do logic on certain users.

My workaround for this has been to pass in a PAT Client & Secret into the headers of the operation and make a query back to the ISC API in a before provisioning rule. This can give you all the identity attributes you need, but comes with the cost of execution time and complexity.

If the details you need are on the end source, I would recommend querying that user using the api credentials you already have stored in the header and doing a single user get call to grab the details in a before provisioning rule. This is still adding execution time, but is less complex than passing in a PAT and making queries back to ISC.

2 Likes
3

Hi @trettkowski , thank you for sharing your insight.

It was reassuring to hear that you’ve encountered the same limitation and had similar concerns — I definitely relate to that frustration. Including a PAT client/secret in the connector rule and calling back to the ISC APIs seems like a realistic workaround, as it would allow retrieving all required identity attributes based on the native identity provided in the provisioning plan.

That said, as you mentioned, maintaining PAT credentials within connector logic can be a burden from both a security and operational standpoint.

I also agree that querying the target system directly using the existing API credentials stored in the headers is often a cleaner and more practical alternative when the required data already exists on the end source. In this particular case, however, the end source does not appear to have visibility into the two identity attributes maintained by the authoritative source.

Your response was very helpful in clarifying the current platform limitations.
Thanks again for taking the time to share your experience.

4

if you are using rule, why not get the attributes direct from the identity object and add it to the plan if the operation is modify (or what ever suits you)?

something like this:

sailpoint.object.Identity identity = plan.getIdentity();
String deptCode= identity.getAttribute("deptCode");

I am sure you know already, not a good practice to pass creds in the rule.

1 Like
5

Hi @lampard08 ,

You may want to take a look at the following discussion:

Based on the discussion above, it is described that Web Service Connectors do not automatically map or populate identity attributes into the provisioningPlan object by default.

Because of this behavior, identity attributes are generally not available in the Before Operation Rule, and it is typically not possible to retrieve detailed identity information directly from the provisioning plan during entitlement removal.

I wanted to check whether this behavior is a known and intended platform limitation, or if there is another supported or recommended approach to access identity attributes in this context.

Regards,

6

@jwshin, I thought @trettkowski was using cloud before prov rule not connectors before op rule.

as you have already understood from the other post, your best (maybe only )option is to use the cloud rule and manipulate the operation or plan accordingly which is what i was try to refer to.

1 Like
7

Apologies for the confusion. I was referring to the before operation connector rule, not the cloud rule.

Generally speaking, I try to avoid cloud rules unless there are no other options available.

1 Like
8

Hello @jwshin , Yes, there is a way to pass Identity attributes to the plan. You can get Identity attributes in web services connector rule by adding them to the plan using before provisioning rule. This may look tedious process as we need to write both cloud and connector rules, but this is the only way to access non provisioned attributes. You can refer this blog.

1 Like
9

Just curious. Is there a reason to avoid. Sometimes you cannot avoid like in thise use case.

10

There’s nothing inherently wrong with them. My clients don’t want to rely on SailPoint support to update/deploy rules for them, which could take 1-2 business days. They say the SLA is 24 hours, but I’ve experienced it go past that more than a couple times. If we have a production issue in that cloud rule, we can’t fix it right away like we would be able to with a connector rule. Also, there is a rule review cost that would need to be discussed with the client before submitting tickets.

11

Hi @JackSparrow, thanks for sharing the blog.

I’ve reviewed it and it’s relevant to my use case.
This will be helpful as a reference.

Regards,

12

Hi @trettkowski ,

I agree to all the points but if client has business plus and above suites no need have extra rule review costs right it was already included in suite

Im just clarifying to myself here

13

Hello everyone,

Thanks for the explanations.
Based on the discussion, I’ll use a Before Provisioning cloud rule and a Before Operation connector rule to pass the required identity attributes when necessary.

Thank you.