We have webservice connector setup and we have written a web services after operation rule for account aggregation, right after “Create Account” is completed. This is to fetch additional parameters on newly created account, as “Create Account” operation has limited response attributes. For any subsequent operation such as “Add Entitlement”, we need those additional attributes and hence we have to enforce account aggregation.
On the rule, we are using below import statements. Just wanted to check if these import statement works when we deploye this rule on IDN for execution. This is working fine as stand alone code when tested through eclipse IDE with reference jars. Do we need to change these import statements as per SailPoint IDN specific APIs or Do we need additional(SailPoint related) jar on VA server.
I am not sure if those packages would be supported or not unfortunately. Is there any reason why you could not just use the ‘sailpoint’ or ‘java’ packages instead? I’d say to test your rule in your sandbox instance to see if it can execute properly.
Alternatively, you might be able to trigger this aggregation a different way. Are your Create Account and Add Entitlement operations being executed simultaneously or separately? If they are separate, one option could be to define an Account Aggregation operation and set the Parent Endpoint to the Create Account operation. This should allow for the Create Account operation to process, then trigger the Account Aggregation to get the additional attributes, then a subsequent Add Entitlement operation which should be able to reference any account attributes.
One more question I have, I came across your query where you were trying to add a default entitlement while user creation. Here also we have a quite similar requirement where we need to add “Base user” entitlement on user creation but in IDN we can only create user when we request an entitlement. So, my question is that how we can give the default entitlement while user creation?
Does the entitlement need to be included in the Create Account operation, because the source API requires it, or are you just looking to make sure all users have this entitlement?
If you are just looking to make sure all users have this entitlement and the account can be created without it, I would recommend just using a role to provision the entitlement to all users that have an account on your source.
My situation that I believe you are referring to was that the source API would not allow accounts to be created without an entitlement. If this is what you are looking for a solution for, I can elaborate further, but the role solution would be simpler if that works for your use case.
Yes, we are looking for whichever user will be created should have “base User” entitlement by default. But in our case create API do not allow add entitlement, for this we have different API.
In that case, the simplest answer sounds like it would be to use a Role to add this access. Unfortunately, the assignment criteria can be a bit tricky for this use case, so here is an example of what we use for our Active Directory source when this comes up. Since every AD account has a UPN and every UPN contains ‘@’, this role criteria will add the access to every account.
