How to add extra attributes to the provisioning plan of the Disable account operation of a web services connector?

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

Hi,

I’m building a web services connector and, for the disable operation, I need to use the user email as part of the URL to make http call to the target system. The URL would be something like:

https://appXYZZ.com/Users/[email protected]

We don’t use the email as the NativeIdentity attribute so can’t use the “$plan.nativeIdentity$” placeholder as part of the URL in the HTTP Disable operation. We must find a way to add the email.

For that, I tried adding the following Disable provisioning policy:

{
    "name": "Disable User",
    "description": null,
    "usageType": "DISABLE",
    "fields": [
        {
            "name": "userName",
            "transform": {
                "type": "identityAttribute",
                "attributes": {
                    "name": "email"
                }
            },
            "attributes": {},
            "isRequired": false,
            "type": "string",
            "isMultiValued": false
        }
    ]
}

And configured the Disable operation context URL to be “/Users/$plan.userName$”, but it doesn’t work. I have enabled debugging on the VA and I can see that the userName is not being added to the http call.

How can I add that attribute to the provisioning plan? What is the point of the Disable provisioning policy if it’s not to add attributes to it?

Thanks.

David.

2

Your current method does not work because the Provisioner will end up filtering out the email attribute because it already exists with that value on the associated account.

You will have to use a WebServiceBeforeOperationRule where you can modify the request URL before it’s sent. The tough part is that you are not given the identity and cannot access it through the ProvisioningPlan passed in since it’s an integration plan at that point.

To achieve what you want in IDN, you will probably also need a BeforeProvisioning rule on that source which would add the account’s email as an argument to the ProvisioningPlan object (using plan.put()). You should be able to access the Account object via idn.getAccountByNativeIdentity(java.lang.String applicationName, java.lang.String nativeIdentity) method. You could then access that plan argument in the WebServiceBeforeOperationRule once it runs.

Lastly, in your WebServiceBeforeOperationRule, you could update the endpoint URL with the setFullUrl() method where you could append the account’s email that you get from the plan argument and return the updated Endpoint object from the rule to be executed.

I have not done this in IDN so this is all speculation. In IIQ, SailPointContext is available to you in a WebServiceBeforeOperationRule, so you could just look up the account directly there and grab the email to append to the Endpoint URL. IDN doesn’t give you this capability in connector/VA executed rules, hence my proposal of the two rules working together,

3

This would work but if your end system can provide email for account by making single account call then you can use chaining. Chaining is preferred in idn against rule because of less complexity of it.

You have nativeIdentity which is not email so I am assuming email should be part of response when you make call to end system using that id and use email in next chained call.

1 Like
4

Hey Patrikck,

Thnaks. I’m a bit confused. We have the same approach working for the Create Account operation. Here are the steps we followed for the create account one and it works flawlessly:

I created a Create Account provisioning policy like this:

{
    "name": "Account",
    "description": null,
    "usageType": "CREATE",
    "fields": [
        {
            "name": "userName",
            "transform": {
                "type": "identityAttribute",
                "attributes": {
                    "name": "username"
                }
            },
            "attributes": {},
            "isRequired": false,
            "type": "string",
            "isMultiValued": false
        },
        {
            "name": "active",
            "transform": {
                "type": "static",
                "attributes": {
                    "value": "true"
                }
            },
            "attributes": {},
            "isRequired": false,
            "type": "boolean",
            "isMultiValued": false
        }
    ]
}

I created a Create Account web services operation like this:

{
                "httpMethodType": "POST",
                "pagingInitialOffset": 0,
                "sequenceNumberForEndpoint": "6",
                "uniqueNameForEndPoint": "CreateAccount",
                "curlCommand": null,
                "rootPath": null,
                "body": {
                    "bodyFormData": null,
                    "jsonBody": "{\n  \"schemas\": [\n    \"urn:ietf:params:scim:schemas:core:2.0:User\"\n  ],\n  \"userName\": \"$plan.userName$\",\n  \"active\": $plan.active$,\n\n \"groups\":  [\n        \":REPLACE:\"\n ]\n}",
                    "bodyFormat": "raw"
                },
                "customAuthUrl": null,
                "paginationSteps": null,
                "responseCode": [
                    "2**"
                ],
                "resMappingObj": null,
                "contextUrl": "/Users/$plan.userName$",
                "pagingSize": 50,
                "curlEnabled": false,
                "header": {
                    "Content-Type": "application/scim+json"
                },
                "operationType": "Create Account",
                "beforeRule": "Vista JFrog Before Create Op WebServiceBeforeOperationRule",
                "xpathNamespaces": null,
                "parentEndpointName": null
            }

As you can see we are making several references to the “$plan” placeholder ($plan.userName$, $plan.active$)…we even use it in the context URL (“contextUrl”: “/Users/$plan.userName$”)…and it works with no issue.

Why this approach works for the Create account operation but the exact same it doesn’t work for the Disable account one? Is this expected?

Thanks.

5

Hi Chirag,

Thanks. could you check my last response to Patrick? This is a bit confusing. We have used this exact same approach for the create operation and it works perfectly.

Why it doesn’t for the Disable account?

Regards.

6

This is expected because that’s how product is designed.

When you are creating account there is no existing account so plan has nothing to check against.
In case of disable there is already existing account and it has same email which you are trying to pass in plan so processing removes that attribute from plan making whole process more efficient.
You cannot avoid this in idn and you will have to implement work around either of above mentioned through rule or chaining.

7

Hi Chirag,

Thanks. What is the point of having a Disable account provisioning policy then? I’m struggling to understand what can we then do using it…looks like pointless then.

Can you clarify what is chaining? Is that calling a parent endpoint to get the user details and then getting the email from the response?..if it’s that, I’m not sure how can we do that, to make a call to the get the user details we also need the email.

Regards.

8

Okay…got this working:

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

Chirag made me think twice about it and well…if the problem is the “email” being an already existing attribute…we don’t care at all about the name…what we need is the email value. I tested creating a dummyAttribute as a placeholder for the email value and now it works.

Now we call the context URL in this way:

/Users/$plan.dummyAttrib1$

Jesus!..this entire integration had a huuuuge number of lessons learned!:tired_face:

1 Like
9

Good point @chirag_patel, chaining also could of worked in this situation where you have two operations for disable account defined where the first gets the current object from the endpoint application and the second uses the info in the response object to run the actual disable.

@djerez the point of a disable policy (or any provisioning policy on a source) is to set certain attributes during that account operation. For example, while disabling an AD account, if you also wanted to set the description on the account to indicate when the account was disabled.
worked.

Unfortunately there are a lot of weird workarounds like this throughout the tool. Looks like you figured something out though.

10

Hey @patrickboston and @chirag_patel …thanks again!

Unfortunately the story is not completely over :smiling_face_with_tear:… I’m going to create another post because despite we have fixed the Disable operation by doing what I posted above, the same approach doesn’t work for the Remove Entitlement one (I want to cry) which also needs the email.

Having your input in the new post would be great!

Regards.

1 Like
11

Hi David,
Did you create another post for the remove entitlement?

Thanks

12

Hi @jrossicare

Yes I opened this one

Regards.

David J.

1 Like
13

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