Attribute Sync using Update Operation for Web Services application

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

Hi All,

I was trying to enable attribute sync for some of the attributes. I have defined Update Operation for the same with PUT operation. Below is the body for this operation. Issue with this is, provisioning plan will only have attributes for which values are getting changed. E.g If first and last name gets changed, plan will have only first and last name but not email.

We need email value as its the mandatory attribute (as per downstream application) that we need to pass in the body. As the email attribute didn’t get changed, it’s not in the plan and we are receiving error: User could not be updated because mandatory field in EZOffice (User Name) was not found during provisioning.

So how to get the details for the attributes that are not getting changed? and how to update the body only for the attributes that are getting changed?

{
  "schemas": [
    "urn:ietf:params:scim:schemas:core:2.0:User"
  ],
  "userName": "$plan.email$",
  "name": {
    "familyName": "$plan.LastName$",
    "givenName": "$plan.FirstName$"
  },
  "active": true,
  "meta": {
    "resourceType": "User"
  },
  "roles": [
    {
      "primary": true,
      "value": "$plan.RoleName$"
    }
  ],
  "emails": [
    {
      "primary": true,
      "value": "$plan.email$",
      "type": "work"
    }
  ]
}
2

Hello @JackSparrow,

If your account identifier is the username then it has to be set as the account ID in your schema. If that’s already done, you can just call it using $plan.nativeIdentity$ and that’s the easy way.

If that’s not possible, you have a couple of options:

  1. Inject the email in your Provisioning Policy Update (using API)
  2. Add a new “Update account” Operation that would load the account by ID using $plan.nativeIdentity$, make sure to map the “email” attribute in the response mapping and then use your update account as an HTTP Operation below it and get the email using $response.email$

I hope that works,
Good luck!

3

Thanks for your response @WhiteBat . ID (random number) is the accountIdentifier.

Email attribute is mandatory that I need to pass in the request body. In some way I need to add the email to the provisioning plan. Can we add it using before provisioning rule? Also, even if email changes (in AD) that also needs to be synced.

Appreciate if you can give more info on this.

4

Hello back @JackSparrow

I’d go with the first appoach to add the email in the provisioning policies using the SailPoint API list-provisioning-policies | SailPoint Developer Community, then create a new provisioning policy UPDATE and inside just add the email and load it from the account attribute.

You can indeed use a before provisioning rule to add the email in there if you don’t want to play with the prov policies.

5

@WhiteBat If we go for UPDATE type provisioning policy, will the email be pushed to provisioning plan??

6

@JackSparrow I have done something similar in the past, and it worked for me, you can try it and force a sync and see what happens.

7

Let me give a try and update you!

8

Hi Theja,
If you suffix all the attributes that you want forced through with an ‘x’, then they will update:

"In VSC, open the ‘CREATE’ provisioning plan and copy everything inside the of the “fields” variable and paste it into the ‘UPDATE’ plan.
Then suffix an ‘x’ to the name value of each element in the array apart from ‘messageID’ & ‘timestamp’. The logic behind this is that natively, only the attributes that have changed will be sent from the provisioning plan. As the ‘name.x’ values don’t exist on the source, they therefore must need updating.

image
image823×149 4.98 KB

"

9

Take a look at this blog post. It outlines this specific use case for a WebServices connector

10

Hi @dopstrick , Thanks for the blog. It was really helpful. Will go with BP rule if UPDATE transform doesn’t work

11

Thanks @PhilRawlings1 Let me try and update you

12

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.