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.
So I’ve found an issue with this configuration and larger entitlement membership datasets that require paging. It seems to me that paging in my case isn’t possible?
I have a Group Aggregation configured that pulls in every single group, and then a Child Endpoint called Group Membership Aggregation that uses the group id to pull all the members of said group into an attribute (like the rule needs).
So the context URL for the child endpoint something like “/rest/v1/groups/$response.id$/users”.
The problem is that the Group Membership Aggregation child endpoint needs to be paged through, and that initial $response.id$ doesn’t seem to persist through paging and there doesn’t seem to be a way I can continue to reference it after the first child endpoint call.
So what happens is I only get the first 50 (page size) members of each entitlement and then paging fails (without the entitlement aggregation reporting an error). I’m unsure how to fix this as the initial $response.id$ that comes from the parent Group Aggregation call is lost during the paging steps but it is needed for the URL in every paging call.
Seems like a general issue with paging and child endpoints that need to reference a value from their parent’s response. Any ideas?
I guess I’ve just been wasting my time. The issue is that SailPoint just straight up doesn’t support pagination on child endpoints for seemingly no reason. Great.
From the documentation for Web Services paging: " Note
- If there are multiple Account or Entitlement Aggregation operations (endpoints) configured, paging is supported only for the first operation instance of Account or Entitlement Aggregation."
1 Like
Hi Ben,
The only way I can think of around this, is say you have a Before Operation rule, and you call the Group Membership from in there.
You would then need to handle the pagination yourself.
So basically just have a single Group Aggregation, and do the membership aggregation within the Before Operation rule.
Hi @fernando_delosrios Can you please help us provide an example for xml response too for IdentityNow after operation rule?
@Nadim, Could you kindly share how you have implemented the paging, we are currently trying to do this but it is not working as expected.