Enable Account Operation on Web Services Connector Seemingly Broken

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

Hello,

I am having the exact issue that was seemingly unresolved in this topic: Problem with disable operation in web service connector

I have configured an Enable Account operation in my web services connector that I know is configured correctly. It is identical to my Disable Account operation, the only difference being the body containing a JSON body of {“user_status” : “active”} rather than the {“user_status” : “inactive”} configured for the Disable Account operation.

The Disable Account operation works with no issue, and the exact request works in Postman, so there seems to be no reason this should give an error. The error displayed also does not show an API response like it did when I was first configuring the Disable Account operation and had misconfigured it. When that happened, I would see the HTTP response and it would show the error code of 400 along with the error message. Instead, I just see:

image
image510×209 3.52 KB

It’s as if SailPoint is producing the above error before even attempting to send the API request configured in the Enable Account operation.

I have also tried deleting and re-creating the Enable Account operation and the source itself, to no avail. Any help would be greatly appreciated.

2

Hey @benjaminoriold

I’m sure you already tried this, but wanted to throw it out there just in case. Have you enabled logging on the connector and checked the CCG for any error details?

3

Hi @benjaminoriold ,

Can you please share the enable operation body by masking sensitive info also account schema screenshot ?

Thank you.

4

Account Schema:

image
image1637×660 27.7 KB

image
image1639×642 27.6 KB

Enable JSON:

{
“id”: “$plan.uniqueId$”,
“user_fname”: “$plan.firstname$”,
“user_lname”: “$plan.lastname$”,
“user_email”: “$plan.mail$”,
“user_status”: “active”
}

I do have the provisioning policy configured for all the above attributes being passed in with the $plan syntax. This goes for both Enable and Disable, I have the provisioning policies configured for both. I have also tried replacing $plan.uniqueId$ with $plan.nativeIdentity$ since that would be the same attribute. Either way, this JSON body works for the Disable Account operation with the only difference being active vs inactive being passed in that last entry.

5

Yes, I cannot seem to find an error that would be causing this in the ccg logs. It’s almost like this is happening before an API request is even being attempted.

6

Pinging this again in case anyone has any insight here, I’m kind of hitting a wall and don’t understand why this isn’t working

7

Hey @benjaminoriold

Here are a few more things to check:

  1. Ensure your Account Enable Status Attribute is populated correctly. I would assume looking at your screenshots, it should be status=active

    image

  2. Check for any white spaces in the URL/Headers/JSON Body. Just to be safe, copy/paste the exact values you put in your Postman.

  3. Double check ENABLE is in your sources features:

    image
    image221×230 3.79 KB

  4. Lastly, ensure there are no rules set in the before or after operations in your source for the enable operation.

  5. If none of these work, I would open a support case with SailPoint to see if they can pin point the issue on their end. They have more logging than we have in the CCG, so they can likely tell you the issue or let you know if it’s truly a bug.

Hope this helps and keep us updated!

8

Hi,
I always assumed that the JSON body was case sensitive.

Your schema has ‘firstName’,‘lastName’, ‘email’ & ‘id’
Your body has: ‘firstname’, ‘lastname’, ‘mail’ & uniqueId’

i am very surprised that it works for the disable function, seeing as the 3 of those values should be null.
What does the app expect in the body for an Enable function? Perhaps it needs some different attributes

9

So the provisioning plan and the attributes in the account schema each can have different names, which is what you’re seeing there. Those variables in the request body are being pulled from the provisioning plan, not the account schema, and the provisioning plan has them as firstname, lastname, mail, and uniqueId.

10

Interestingly enough, after not touching it for a few days, I’ve come back and it just seems to be working? It’s returning a 405 error now (which is actually getting displayed to me) which doesn’t really make sense, but the operation actually succeeds and re-enables the account just fine. I have to assume the 405 is some bug on the API side since it’s working.

I guess this was maybe a SailPoint bug that fixed itself? Frustrating to not know what was actually going wrong though.

11

Thanks for updating us.

Definitely sounds like an issue on the SP side. Do you have a support case open? I’m curious if they have any logs on their end that confirms what the issue is.

12

I did not have a ticket open, plan was to open one if I couldn’t get it working that day but it just kind of started working :person_shrugging: wish I had more info too because I don’t want it to randomly stop working

13

Maybe it was because it sent too many errors at a given time and started rejecting them all. I’ve seen this happen with a SaaS based Web Services connector before, but this is a VA based web services connector, right?

14

Yeah this is VA based