I am trying to implement a web services connector. All the configurations are complete but I am facing an issue with the “Account Enable Status Attribute” in the source config page.
Issue Faced:
In my existing configuration, the “Account Enable Status” attribute is left as blank. I have a lifecycle state called “Terminated” and when an identity is terminated, its provisioning tab is configured to disable the account on my web service source. This works just as expected and account status shows “Disabled” when terminated. But when I perform a full aggregation on the web service source, the account status which was disabled earlier due to the change in lifecycle state is changed to “Enabled” again. Since I haven’t configured anything in the “Account Enable Status Attribute”, I’m trying to understand why my accounts are getting “Enabled”? Is this the default behavior?
For my use case, I have a schema attribute called “Interface” which can contain 3 values. Those are “Power”, “Basic” and “Disabled”. During aggregation, If the value is received as “Disabled”, it means that the accounts are disabled on the target source. And If the value is either “Power” or “Basic”, it means that the account is active on the target application. After a bit more exploration, I found that this attribute does not support conditional statements where I can put a multiple “| |” statement such as “Interface=Power | | Interface=Basic” which is exactly what I need. Also, Can’t I use “Interface!=Disabled” in my “Account Enable Status Attribute” ?
Can someone please suggest me with a solution on how to handle this?
Use afteroperation rule,create another attribute in schema and populate the value of it as yes/no or active/inactive based on “interface” attribute. Use that attribute as status attribute.
From the web service source reference documentation, It is mentioned that “Account Enable Status Attribute” is checked while loading the accounts itself (ie. in parallel with aggregation.)
From your feedback, what I understood is, “Account Enable Status Attribute” is checked after the entire ‘Account Aggregation’ operation is complete. Is it right? Please correct me if I’m wrong.
Also, I have two more queries here:
Since we are not receiving this new schema attribute value from the API endpoint, how can we populate it from within the ‘afterOperation’ rule. Can you please share any code snippet if available?
Can “IIQDisabled” attribute be set to “true” from the afterOperation rule to directly set the account status?
Are you sure the OR (||) operation does not work? I found the documentation - Server and Common Configuration Parameters - and it has an example: status=Active || status=Pending
Note that you will also need to configure the enable/disable operations: Supported Operations
From the web service source documentation, it says " The Account Enable Status Attribute field supports only single value for status attribute, for example: ‘status=Active’. Conditional operators are not applicable for the field as displayed in the following examples: status=Active || status=Pending".
So I don’t think that we can have conditional statements in “Account Enable Status Attributes”. However, it would be really helpful if there is any future update which will enable us to configure conditional statements in this field.
Also, pertaining to my query above:
Since we are not receiving this new schema attribute value from the API endpoint, how can we populate it from within the ‘afterOperation’ rule. Can you please share any code snippet if available?
Can “IIQDisabled” attribute be set to “true” from the afterOperation rule to directly set the account status?
Sorry, I was reading too quickly this morning and missed that line on the article… My apologies.
You’re right, you will need to use a WebServiceAfterOperationRule on the account aggregation operation to set the IIQDisabled flag as either false or true.
Here’s an example of evaluating UserState to set that flag:
Your web service source’s enable and disable operations should update the attribute that’s used in the calculation for IIQDisabled (in that example – the UserState attribute). Please note that IdentityNow data does not refresh by itself when you enable or disable an account (in other words, the enable and disable operations do not trigger a single account aggregation after updating the web service account) – you have to either force a single account aggregation or wait for next aggregation to happen to see the updated status in IdentityNow.
We need to ensure that the Account Id in the source schema and the unique id from the target API response are the same (case sensitive).
Here’s the snippet :
Map updatedMapInfo = new HashMap();
List list = new ArrayList();
List response = (List) JsonUtil.toList(rawResponseObject);
List finalList = new ArrayList();
if (response!=null){
for (int i = 0; i < response.size(); i++){
Map accMap = (Map) response.get(i);
if(accMap.get("<Account_Attribute>").equalsIgnoreCase("disabled")){
accMap.put("IIQDisabled", true);
}
finalList.add(accMap);
}
}
updatedMapInfo.put("data", finalList);
return updatedMapInfo;