Attribute Sync Provisioning Policy

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

Hi all, I’m working with a customer to set up attribute synchronization on a WebService source. We have defined a call that looks like the following:

{
	"department": "$request.department$",
	"phoneNumbers": [
		{
			"number":"$request.phoneNumber$",
			"type":"work"
		}
	]
	"address": {
		"addressLine1":"$request.addressLine1$",
		"city":"$request.city$",
		"state":"$request.state$",
		"zipcode":"$request.zipcode$",
		}
}

The problem is that if the phoneNumber and address attributes are not all included, then those attributes get cleared out. I understand the mechanism for how IdentityNow cleans the JSON in these requests and why that is happening, so I started writing a before operation rule to just strip out the “phoneNumber” and “address” attributes from the call if those values are not included in a change.

This all triggered a thought though - I should be able to just add these attributes to the “Update” provisioning policy and they’ll always be included in every attribute synchronization call whether they’re needed or not. This would eliminate the need for a rule altogether. For some reason, this doesn’t seem to be working. I added the following to test it out:

{
    "name": "Update Account",
    "description": null,
    "usageType": "UPDATE",
    "fields": [
        {
            "name": "phoneNumber",
            "transform": {
                "type": "identityAttribute",
                "attributes": {
                    "name": "workPhone"
                }
            },
            "attributes": {},
            "isRequired": false,
            "type": "string",
            "isMultiValued": false
        }
    ]
}

But the phoneNumber is not included in the call when the department updates.

Am I stuck using a rule or is there something I’m just missing?

2

When an API only supports PUT operations in your scenario as opposed to a PATCH, the web services connector does not handle it well unfortunately.

Adding attributes to your update policy to pass them to the HTTP request does not work because if the value for an attribute calculated in your update policy already matches what is currently on the account on the cube, the provisioning compilation process filters that attribute out of the resulting provisioning plan and you end up with only what actually changed triggered from attribute sync.

I just ran into a similar situation and here is how I solved it:

  1. For the Update Account operation, define two separate HTTP requests that will be called sequentially
  2. The first one will perform a GET of the current account state from your application and have the proper response mappings
  3. The second request will perform the actual PUT request to update the account. In the request body, you will provide all of the current attribute values returned from the previous GET request via the $response.attribute$ keyword
  4. You then need to write a Web Services Before Operation Rule and attach it to this second operation. The rule needs to parse your request body in a proper JSON object where you can iterate each key in the request body and compare those keys to your provisioning plan’s account request that gets passed into the rule to see if the there is an attribute request with a matching name. If found, you would replace the value of the entry in the JSON object with the new value coming from attribute sync. Once you update the JSON, update the request end point in the rule with the new JSON body in a string format. This also assumes your response/schema mappings are 1:1 so this is easily done

Doing this will allow you to send the whole account back to the endpoint with what has not changed and with what has been updated via attribute sync.

3

Thanks. That’s pretty close to the approach I was taking. Just hoped there was a shortcut I had missed.