ISC Web Service Connector - Create Account / Get Object

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

Hi!

I’ve got a few questions regarding the Web Service Connector. I’ve read quite a few posts describing the same issue but it is still unclear to me how this connector works OOTB without any rule modifications. There seems to be some implicit assumptions of how the source should behave in order to be able to use the connector without modifying it with rules.

It is namely this issue when successfully creating an account (Native Identity showing ??? and Account ID attribute not populated):

sp1
sp11187×534 13.9 KB

Schema is as follows:

{
    "nativeObjectType": "user",
    **"identityAttribute": "sourceId",**
    "displayAttribute": "displayname",
    "hierarchyAttribute": null,
    "includePermissions": false,
    "features": [],
    "configuration": {},
    "attributes": [
        {
            **"name": "sourceId",**
            "type": "STRING",
            "schema": null,
            "description": "",
            "isMulti": false,
            "isEntitlement": false,
            "isGroup": false
        },
        {
            "name": "displayname",
            "type": "STRING",
            "schema": null,
            "description": "",
            "isMulti": false,
            "isEntitlement": false,
            "isGroup": false
        }
    ],
    "id": "removed",
    "name": "account",
    "created": "2024-10-16T07:57:48.804Z",
    "modified": "2024-10-31T07:53:07.644Z"
}

Create Account Provisioning Policy

        {
            "name": "sourceId",
            "transform": {
                "type": "identityAttribute",
                "attributes": {
                    "name": "iscGeneratedID"
                }
            },
            "attributes": {},
            "isRequired": false,
            "type": "string",
            "isMultiValued": false
        }

Create Account POST Body

{
  "sourceId": "$plan.getNativeIdentity$",
  "address": "dummy",
  "zip": "dummy"
}

In our case sourceId is marked as Account ID in the schema, ISC owns this attribute, generates it and sets it on the Identity itself, and we want to set it as Native Identity on our source accounts upon account creation.

Question: Does the connector OOTB expect a value to be returned from the source and that that value is mapped to the Account ID? We already have this value in ISC, why can’t we set that instead in response mapping?

Question 2: I understand the connector does a Get Object operation after and that you have to define this operation for it to work. How do I pass some other value than $getobject.nativeIdentity$ to search with? We would like to use something like $getobject.sourceInternalID$ mentioned above, this differs from the Account ID.

Any links as to how it works “under the hood”, what are some assumptions/expectations for it to work OOTB?

Thanks!

2

hi @ninosp ,
Interesting questions.

I think NativeIdentity is different from Account ID. In my case, both have different values.

However, I have not seen a native Identity in any response mapping. So, it could be that the connector expects the source to return the value which is set to the nativeidentity

1 Like
3

I see you have already made sourceId as Account ID/identityAttribute this will make as native identity for any of the account. But in your create account post body you are doing it wrong. Can you change it to $plan.nativeIdentity$ as try once.
Also put the response mapping I hope you are getting some response when you hit this create API.

You need to map schema attribute with the response what you get inorder to show other attributes.

If you are doing the response mapping I believe this is not required.

1 Like
4

Hi @ninosp

You need to map the output of your api call for create account if that apis return the object created, you can map all the attributes from the api response and that should fix the issue.

if you create account api does not return the entire object. You can can create create account operaation , one will do the provisioning and second will get the object from the apis using getobject. This way you can get the entire account and map all the required attirbutes with your api response to schema attributes, lemme know if you have any questions

1 Like
5

Hi again all and thanks for the replies!

We made it work but I just wanted to understand the underlying logic of the connector with this post.

For the smoothest experience these seem to be the expectations of the connector OOTB:

  1. Source must respond with, at least, an ID of the newly created account.
  2. This ID must be mapped to the attribute that is marked as Account ID in the schema in order for the native identity value to be populated properly.
  3. If other attributes need to be populated and are not returned in the create response (e.g. street, zip) then you need to implement HTTP Get Object which will override the Get Object that Create Account does post creation. This also enables single account aggregation.
  4. Unsure about this one but: If you send the attribute marked as Account ID in your provisioning policy it seems to be set to “null” by the connector when trying to fetch it with $plan.attributename$ and it will thus be wiped from the payload.

Thanks!

6

For native identity you should try $plan.nativeIdentity$ or $account.nativeidentity$
Depending on what is your native identity