Access account attributs in before operation webservices

IdentityIQ (IIQ) IIQ Discussion and Questions
,
1

Which IIQ version are you inquiring about?

Version 8.3

Share all details related to your problem, including any error messages you may have received.

Is it possible to get the value of a specific account attribute (multivalued) using a before operation on add / delete entitlement?
For example:

  • I have an account with id, name, access rights, access_ids
  • When doing a remove entitlement for example I want to send another attribute in the json body

Thanks

2

You can use nativeIdentity from the accountRequest object and just iterate over identities links to find Link object with this nativeIdentity and application. This will give you access to all currently set attributes in the account. Something like that:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE Rule PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<Rule language="beanshell" name="Sample Before Operation Rule" type="WebServiceBeforeOperationRule">
  <Source>
String nativeIdentity = provisioningPlan.getAccountRequests().get(0).getNativeIdentity();
Identity identity = provisioningPlan.getIdentity();
String appName = "SampleRest APP";

Link detectedLink;

for(Link link : identity.getLinks()) {
if(appName.equals(link.getApplicationName()) &amp;&amp; nativeIdentity.equals(link.getNativeIdentity())) {
detectedLink = link;
}
}

String sampleLinkAttribute = detectedLink.getAttribute("sampleAttribute");
  
  </Source>
</Rule>
1 Like
3

after working out a solution arroud this example , i’am getting a null pointer on :

Identity identity = provisioningPlan.getIdentity();

NB: the remove entitlement is triggered when a role access is deleted

here below an example pf my provisioning plan :

<ProvisioningPlan nativeIdentity="XXXX" targetIntegration="XXX" trackingId="XXXXXXXXXXXXXX">
  <AccountRequest application="XXX" nativeIdentity="XXXXXXXXXXXXXX" op="Modify">
    <AttributeRequest name="XXX" op="Remove" value="XXX">
      <Attributes>
        <Map>
          .
          .
          .
          .
          .
          .

    </Map>
  </Attributes>
</ProvisioningPlan>
4

Try this instead

String nativeIdentityString= provisioningPlan.getNativeIdentity();
  Identity identity = context.getObjectByName(Identity.class,nativeIdentityString);
1 Like
5

is it possible tu use application name , and accountrequest native identity and filter to find the attribute ?

application = context.getObjectByName(Application.class, "app name");
.
.
.
.
6

Each account request is always for.single application which you can check eg by. accountRequest.getApplicationName(); and each account.re1uest contains list of AttributeRequests (1 attribute request for each attribute) which you can get by accountRequest.getAttributeRequests();

1 Like
7

i was thinking for something more about :

            QueryOptions Qo = new QueryOptions();
            qo.setResultLimit(1);
            Qo.addFilter(Filter.eq("application.name", appName));
            Qo.addFilter(Filter.eq("identity.name", nativeIdentity));
            Qo.addFilter(Filter.eq("nativeIdentity", accountnativeIdentity));

to limit the queries for retrieving the link and then get the attribute ?

8

@massinissa
Yes, you can use the filter for getting the data from Link object.

1 Like
9

In 8.4 you can do that as Links are available as separate objects, I’m not so sure if in earlier versions it would work.

1 Like
10

Hi @massinissa,

In the current version your link is available as a separate object itself so it should not be a problem to query it.

In earlier version where your Link object is not directly available there you can use “IdentityService” API to get the link directly if it is for the same identity on which your operation is triggered.

Let me know if you need further help.

Thanks

1 Like
11

One note: If you do it this way, you should qo.setCloneResults(true) and qo.setCacheResults(false), which will cause Hibernate to fully detach the Link object from the session and make sure everything is loaded into memory.

You will run into strange and difficult-to-debug caching errors if you don’t. That same Link object is already loaded into the Hibernate cache elsewhere via the Identity whose access is being provisioned.

12

An alternative approach to getting values in your beforeOperation rule is to add it to the provisioningPlan as an accountRequest attribute.

You can use your before provisioning rule to add if to the accountRequest directly from the Identity as accountRequest.setArgument(string, string).

I wrote a blog post that addresses this for IDN, but the same code works for IIQ. Additionally, as SailPoint is trying to transition IIQ implementations to IDN, using this approach would mean less code changes should you ever migrate platforms:

13

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.