Add/Remove Entitlements in VA Web Services - What does $plan$ actually have?

[mdewallnc (Matt D)]

I’m trying to add/remove entitlements via the VA Web Services connector and I’m not finding the documentation helpful.

At this point I’m able to aggregate accounts and associate their entitlements. (This because of a blog article and the forums here. Docs for this specific connector have had zero positive effect on my success). My trouble now is Add/Remove operations (via HTTP PATCH).

Big questions I’m not finding in the docs:

• What objects are available to me without writing rule code? I see $plan mentioned but nothing I put in there seems to work other than the plan.nativeIdentity. There are also references to $getObject.nativeIdentity$. Those all work, but I’m interested in (I think?) the plan object.

• What operations would lead me to have to write a before/after rule? I’m trying to avoid this as this is a really simple operation.

My specific question:

I’m trying to remove an entitlement via a PATCH method with a body as so:

{ "op": "remove", "path": "/entitlements", "value": "$plan.?????.????.????$" }

Some parts of the documentation reference $plan.group_id, some $plan.role, some $plan.groups. All of those value are undefined by the time they make it to my Web Service. Is this supposed to be “$plan.my-attribute-name$”?

Here is an excerpt from the debug log on my VA, the plan is being executed but I just don’t know how to get to the “value” attribute in AttributeRequest.

I’ve tried $plan.getAccountRequests()[0].getAttributeRequests()[0].getValue()[0]$ because it seems to mimic some IdentityIQ docs I was able to track down. Hoping someone can shed some light on this process.

Thank you!

Matt

<?xml version='1.0' encoding='UTF-8'?>\n
<!DOCTYPE ProvisioningPlan PUBLIC \"sailpoint.dtd\" \"sailpoint.dtd\">\n
<ProvisioningPlan nativeIdentity=\"[email protected]\">\n
    <AccountRequest application=\"***** - XXXX [source]\" nativeIdentity=\"xxxxxxxxxxxxxxxxxxx\" op=\"Modify\">\n
        <AttributeRequest name=\"entitlements\" op=\"Remove\" value=\"NEED_THIS_VALUE\">\n
            <Attributes>\n
                <Map>\n
                    <entry key=\"IdnAccessRequestAttributes\">\n
                        <value>\n
                            <Map>\n
                                <entry key=\"accessRequestType\" value=\"REVOKE_ACCESS\"\/>\n
                                <entry key=\"clientMetadata\"\/>\n
                                <entry key=\"deniedCommentsRequired\">\n
                                    <value>\n
                                        <Boolean>
                                            <\/Boolean>\n
                                                <\/value>\n
                                                    <\/entry>\n
                                                        <entry key=\"requestedObjectDescription\" value=\"Provides chat access for application\"\/>\n
                                                        <entry key=\"requestedObjectId\" value=\"161d724b622140ba99a289ca35f0bf4a\"\/>\n
                                                        <entry key=\"requestedObjectName\" value=\"App Chat Acccess\"\/>\n
                                                        <entry key=\"requestedObjectType\" value=\"ENTITLEMENT\"\/>\n
                                                        <\/Map>\n
                                                            <\/value>\n
                                                                <\/entry>\n

[sauvee (Edwin Sauve)]

The value you provide after $plan… must be whatever you call the attribute in the account schema. So if I have an attribute on my account schema called ‘roles’, which from the source system contains my entitlements, I would provide in the body this:

$plan.roles$

So in your case for a remove roles it would be:

[
{ “op”: “remove”, “path”: “/entitlements”, “value”: “$plan.roles$” }
]

And for add roles:

[
{ “op”: “add”, “path”: “/entitlements”, “value”: “$plan.roles$” }
]

You will have to make a separate HTTP operation for each (add entitlement, remove entitlement) in the source config.

[mdewallnc (Matt D)]

Thank you so much Edwin! Yes, that was what I was missing!

The attribute on my Account Schema is called entitlements and once I updated that, I was able to make my changes. I hope the documentation can get a makeover, much of the attribute updating language isn’t clear, at least not to me.

Here’s my final payload:

[
  { "op": "remove", "path": "/entitlements", "value": "$plan.entitlements$" }
]

Thank you!!!

[ipobeidi (Ivan Obeidi)]

hey @mdewallnc , how are you?

First, your api require you to send all the users roles + the one he have requested? Or you can simply pass the requested role?

The plan is going to have the variables exiting in the Provisioning Policy ( for add entitlement is update/modify policy) and for the entitlement you’ll have the “entitlement holding attribute on the account” so if in the account the attribute that holds the entitlement is “roles” in the plan, the attribute carrrying the entitlement value will be roles.

If you need to have all the roles on the operation thats is a usecase for a before operation rule.

best.

[mdewallnc (Matt D)]

Got it, thank you Ivan. In my case, I’m the author of the API, so I’m able to be flexible and just handle the single value. You answered my question on the “when do I need a role”, thank you. If I run into a situation that requires all roles at once, I’ll keep that in mind. Appreciate your help!

Matt

[sauvee (Edwin Sauve)]

That is great to hear, happy to help.

I agree that the documentation is somewhat lacking at these detailed points, where it definitely helps to have an IIQ background as well. Perhaps it is good if you mark it, perhaps using the new comments section in the docs to mention what you are missing?