Add/Remove Entitlement operation $plan placeholder issues

[djerez (David Jerez)]

Hi,

We are now about to finish a web service connector that we will use as a generic/template connector for all our non-fully compliant SCIM apps (compare to the generic SCIM2 connector seems to give us more flexibility) or the ones that are not SCIM at all.

We have now, with some pain to be honest (it’s my 1st web services one), working all the operations with a nice amount of flexibility with the exception of the add/remove entitlement ones.

The problem is that in order to get the flexibility we need, we had to add some custom attribs to the some of our profiles to be able to adapt the HTTP request to the one the app expects to receive. We basically use a dummy attribute to get the user identifier the app uses to identify the users. In this case is the “email” but we have apps that expect other values. For instance this is the provisioning policy we have for out Disable and Enable profile.

{
    "name": "Enable User",
    "description": null,
    "usageType": "ENABLE",
    "fields": [
        {
            "name": "dummyAttrib1",
            "transform": {
                "type": "identityAttribute",
                "attributes": {
                    "name": "email"
                }
            },
            "attributes": {},
            "isRequired": false,
            "type": "string",
            "isMultiValued": false
        }
    ]
}

This right now (we are still testing) works pretty consistently and allow us to call these dummy attribs using the $plan placeholder in the way you can see below:

{
                "httpMethodType": "PATCH",
                "pagingInitialOffset": 0,
                "sequenceNumberForEndpoint": "7",
                "uniqueNameForEndPoint": "EnableAccount",
                "curlCommand": null,
                "rootPath": null,
                "body": {
                    "bodyFormData": null,
                    "jsonBody": "{\n  \"schemas\": [\"urn:ietf:params:scim:api:messages:2.0:PatchOp\"],\n  \"Operations\": [{\n    \"op\": \"Replace\",\n    \"path\": \"active\",\n    \"value\": true\n  }]\n}",
                    "bodyFormat": "raw"
                },
                "customAuthUrl": null,
                "paginationSteps": null,
                "responseCode": [
                    "2**"
                ],
                "resMappingObj": null,
                "contextUrl": "/Users/$plan.dummyAttrib1$",
                "pagingSize": 50,
                "curlEnabled": false,
                "header": {
                    "Content-Type": "application/scim+json"
                },
                "operationType": "Enable Account",
                "xpathNamespaces": null,
                "parentEndpointName": null
            }

That works pretty nice and despite I don’t like a lot the idea of creating those “dummy” attribs, it saves us from implementing rules (neither at the connector level nor at the cloud level) and it does the job.

The problem is we have tried implementing the exact same provisioning policy for our add/remove entitlement operations…as I said using the exact same provisioning policy but for UPDATE_GROUP usage and well, surprise, the value is sent as null when I inspect the http call…but the funny thing is that if I implement a before operation rule at the connector level and iterate over the attributes in the provisioning plan, the attribute is there:

"message":"Current attrReq: dummyAttrib1 - 1000001111"

I mean, with that info in the rule it’s probably fine…I can manipulate the jsonbody and make the call…but is it normal I see the attrib in the provisioning plan within the rule but I get null using the $plan placeholder to reference that same attribute?

At this point I just want to finish the setup so I guess using the rule will be that way to go but, in general, I prefer to go no-code whenever it’s possible and the $plan placeholder allows it and removes the need of any type of rule.

Thanks!

[patrickboston]

Hi David,

I think this was mentioned in the other topic. One way you could go is implementing chained calls or the add/remove entitlement operations. You can define multiple endpoints for the same operation where you could implement the following:

• The first Add/Remove Entitlement Operation would perform a GET of the account from the endpoint
• The second Add/Entitlement Operation would perform whatever HTTP Operation is necessary for remove the entitlement where you have access to the $response$ variable from the prior call which allows you to essentially access the JSON/XML object returned from the prior call where you could do something like $response.user.email$

[djerez (David Jerez)]

Hey @patrickboston,

Thanks. This chained pattern is something completely new to me and to be honest I’m curious. I know you can use multiple endpoints for aggregation but I’m not sure I quite understand how to do it for other operations…I quickly search on Google but if you have any doc I can review I’ll be happy to do it.

My main doubt…and what makes me feel a bit confused is…the parent call would be done to the target application? Because for that I also need the email which put is back to the original issue.

Thanks!

[patrickboston]

It’s essentially the same idea as the chained aggregation. You can define two endpoints for the same operation and they will be performed in that order.

Yes, the parent call would be done to the endpoint application since that is where we need to get the email from without using a programmatic approach. There is no endpoint for using the native identifier to get an account? Is there any reason you are NOT using email for the native identifier then if it needs to be plugged into all of your calls?

[djerez (David Jerez)]

Hey @patrickboston …we manage a very heterogeneous environment with a lot of apps relying on the email but a lot of others relying on more consistent IDs. That adds to the fact that most of our SP integrations are not greenfield ones but, on the contrary, we must adapt to what the owners decided to use when they started using the app…and most of the times this is a 1 way door decision that makes very difficult to change the attribute(s) they decided to use since the beginning and we just can adapt ourselves to the app or avoid the integration.

That’s why we need some degree of flexibility when it comes to what attributes to use for the provisioning operations.

Regards.