Hu @Arshad
In the UI, I created a header called ‘X-IDNClientSecret’ and set the value to $application.private_key_password$
Then in the WSAO, I use
String IDN_CLIENT_SECRET = (String) headers.get("X-IDNClientSecret");
1 Like
I was initially getting normal errors from the after operation rule indicating it was running, but now that I’ve solved those my aggregation fails immediately and says:
“sailpoint.connector.ConnectorException: Error: The application script threw an exception: java.lang.Exception: Authentication call failed: Source JSON is not a Map. class java.lang.String cannot be cast to class java.util.Map (java.lang.String and java.util.Map are in module java.base of loader ‘bootstrap’) BSF info: WSReverseMembershipAggregation at line: 0 column: columnNo”
I saw in another thread that the user solved this issue by fixing how they uploaded the rule but the thread is closed and they didn’t actually explain what they changed. Anyone have a solution to this?
Hi Benjamin,
From your description it’s difficult to know what’s going on other than a type mismatch. I don’t really know where that could be or what you mean by “normal errors”. If you could provide more context, how you configured your call, a sample of data, etc., I would look into it.
Thanks.
Hi Fernando, thanks for the reply. By normal errors I mean the exceptions set up in the script you wrote such as “X-IDNClientId header is missing” so we must be at the point where the script is running and trying to do its job. I have all the group, group membership, and account data coming in as expected otherwise. It’s a different API (JAMA) but I essentially have it set up exactly like your example here with the group entitlement type and the members attribute within it.
It seems like it might be more of an issue with how the rule was uploaded based on the thread I saw here: Attempts to use WSBO rule produces cannot be cast to class java.lang.String error
but I don’t know how they fixed it
So solved the current issue, turns out I was missing the “.api” in the X-IDNUrl header being sent (whoops!). No longer getting an errors.
Problem now is everything succeeds with no errors but the I’m not seeing the entitlements assigned to the users. I’ve stepped my way through the script mimicking what it does in REST clients and such and can’t seem to find where anything would be going wrong. Makes sense since there are no errors but I can’t seem to figure out why the association between user and entitlement isn’t being set.
Did you run an entitlement aggregation first ?
Hi Jason, thanks for reaching out to help. I did indeed run an entitlement aggregation first and I can see the members attribute of all my entitlements properly holding a list of user ids. I’ve even mimicked the rule’s API call to /beta/entitlements too and it returns the data as expected, and then tested the JSONPath statement in the rule on the data it returned and it properly returned the list of entitlement ids.
Actually I think I may have figured it out. I thought the Rule was pulling in the account schema attribute named “id” to compare with the “members” entitlement attribute. It is actually using whatever account schema attribute is marked as the “account id” which I previously had as a different unique attribute.
Changing the account schema’s official “Account Id” attribute to the id attribute that appears in the members array should fix this hopefully. Running an aggregation now.
Update: looks like this worked! Also worth noting that changing the Rule itself to use the id attribute rather than dynamically pulling the attribute labeled as the accountId should also work to fix this if you don’t want your accountId to be the ids on the members attribute.