OOTB Webservice Connector Does not able to pass all fields

IdentityNow (IDN) Discussion and Questions
1

Hi All,

We are configuring a web service connector .During create operation we are able to pass all field from the create profile.
However during update operation or enable operation all fields are not populating in the body due to which the api call is failing.
We have also tried to add the fields in the Account Profile for all the operation but still the data does not pass.

Let us know if any suggestion.

Thanks
Shantanu

1 Like
2

Hi @shantanu_ne ,

Welcome to the community.
In your update profile, for required attributes set “isRequired”: true & try.

Regards,
Anamica

3

Thanks Anamica,

But when we try to update it via API it never gets updated to isRequired as true even after successful response
Is there any API which can help to update this.

image
image849×586 33.6 KB

Thanks
Shantanu

4

I don’t think there is anyway to circumvent this behaviour of connector. The new api to set provisioning policy is also not updating the field. I also tried another field from old doc and it’s also not working.

 {
            "name": "departmentNumber",
            "transform": {
                "attributes": {
                    "value": "G&A"
                },
                "type": "static"
            },
            "attributes": {
                "cloudRequired": "true"
            },
            "isRequired": false,
            "type": "string",
            "isMultiValued": false
        }

The only way forward here is to put the attributes inside arguments of plan which connector does not strip.

5

is the only way to fix this is what Chirag mentioned?

Web Services connectors suddenly stopped working from several clients, and new connectors doesnt pass the values too.

6

The options we used was using a before provision rule to pass the mandatory attributes before every operation.
This way we could resolve our issue.

Thanks
Shantanu

7

https://ideas.sailpoint.com/ideas/CONN-I-66 Created idea to make plan arguments available in connector end point.
Also created this: https://ideas.sailpoint.com/ideas/PLAT-I-68
BTW, you do not need to write before provisioning rule to add arguments. You can use “services standard before provisioning rule” and configure your source json based on your requirement.

8

Hi @AnamicaShroti ,

I’m experiencing a similar issue in which, when executing an Update operation, the only attributes I’m able to retrieve using “$plan.xxx$” are nativeIdentity and group. Since the Create operation is never executed, the Provisioning Policy (create account) is never executed either. Doesn’t really matter if I change the attributes to “isRequired” or not.

Is there a way to pass account attributes in the body/parameter without the need of using the create account? Something that’d look something like: “$account.xxx$” (xxx in this case is an attribute only available in the account).

Looking forwrard to your comments!

Thanks,
Gregorio

9

Hey all - looking at everyone struggling on this thread, I would like to clarify some incorrect information. I’m a SailPoint employee that is familiar with this, and have been around since this configurations inception.

The parameter isRequired is used to validate if a particular field in a provisioning policy / profile should have a value or not. It’s used by the UI and API to make sure fields are filled out. If isRequired is true then it should have a value for transform (i.e. be configured in the UI), otherwise you’ll get an error. If isRequired is false then it essentially is optional field to configure. These fields are set on out-of-box provisioning policies / profiles so admins know they have to configure this or not.

If you are trying to force attributes into provisioning downstream, you will not be able to do that in provisioning policy / profiles; you’ll need to use a Before Provisioning rule. Whatever you put in a provisioning policy / profile is subject to provisioning engine filtering, and will get filtered and removed if you already have that value. Before Provisioning rules execute after provisioning plan expansion and filtering and thus whatever you put in there will get sent to your connector.

We have a bunch of explanations of this behavior in internal, partner, and training materials - hopefully everyone has seen it.

Anyways, hope this helps.

10

Hi @neil_mcglennon,

Based on your reaction I have two questions:

1: Does the isRequired parameter only enforce that the transform attribute has been set, or does it also enforce that the output of this configured transform is not empty in order for the provisioning plan to be send to the next phase?

2: You said ‘If you are trying to force attributes into provisioning downstream, you will not be able to do that in provisioning policy / profiles; you’ll need to use a Before Provisioning rule.’
Regarding this. We had to onboard a web services source, where in order to disable the account, the API body did not need the nativeIdentity (Like NL.AMekenkamp01), but instead needed the domain (NL) and name (AMekenkamp01) separately like domain=$plan.domain$, plan=$plan.name$. When I first added these two values name and domain (as account attribute transforms) to the DISABLE profile, disabling the account was not successful because these $plan.domain$ and $plan.name$ values were not appearing. Probably because of the provisioning engine filtering as you mentioned. But using the same account attribute transforms, but then assigning them to $plan.domainToDisable$ and $plan.nameToDisable$ was working and the account got disabled properly. Probably because these variable names are not used elsewhere and will therefore not be removed by the provisioning engine filtering. Based on this I would say that the statement ‘If you are trying to force attributes into provisioning downstream, you will not be able to do that in provisioning policy / profiles’ is wrong. You just need to make sure that you are using variables that are different than the account attributes.
Could this be correct, or am I missing something?

Kind regards,
Angelo

2 Likes
11