How do I uniquely identify a ManagedAttribute (not by id)?

IdentityIQ (IIQ) IIQ Discussion and Questions
,
1

Which IIQ version are you inquiring about?

Version 8.4

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

This is something like my fourth time trying to type in my question here. The last three times, something went wrong and I lost my post, so please forgive me for being light on the details.

I’m looking at the JavaDoc for sailpoint.api.ManagedAttributer. There’s a variety of get methods with different parameters needed. Which one to use seems to depend in some cases on whether you are looking for a “permission” or an “entitlement”. There’s hashing methods like getHash, getEntitlementHash, and getPermissionHash which claim to generate “the” hash for an “attribute”, “entitlement”, and “Permission”, respectively. getHash goes as far as saying the hash is unique. The only unique key (other than the primary key) in the database is on the hash column. That said, getAll​(SailPointContext, String, boolean, String, String, String) says “Load all matching ManagedAttributes from the database. We don’t expect more than one but it’s hard to prevent. This is public so it can be used by cleanup tasks.” This seems to contradict what is implied by the hashing methods about uniqueness.

We’ve got code where we are currently doing this the wrong way, but I can’t seem to find anything definitive to guide me to the right way.

2

@kjperkin
If your goal is to identify a unique managed attribute based on the input application name, value of managed attribute and type of managed attribute you can use below code to get the same

Value, application and type combination is unique always.

  QueryOptions managedQO = new QueryOptions();

  managedQO.addFilter(Filter.eq("value","<Pass your value of Entitlement>"));

  managedQO.addFilter(Filter.eq("application.name","<pass your app Name>"));

  managedQO.addFilter(Filter.eq("type","<pass your type>"));


  List managedAttr = context.getObjects(ManagedAttribute.class,managedQO);

  if(managedAttr != null &amp;&amp; managedAttr.size()>0){



    return managedAttr;

// Here you will get only one entry in the list. 


  }else {
return "notValid";
  }
3

Hi @kjperkin

I used .get multiple times in projects,

Sample would be as below.

import sailpoint.api.*;
import sailpoint.object.*;

String groupDN = "CN=group1,..."; // Put complete DN here

Application appObj = context.getObjectByName(Application.class, "APPNAME");

ManagedAttribute ma = ManagedAttributer.get(context, appObj.getId(), "memberOf", groupDN);

if you want to use getAll then let me know. i can provide the sample for that one also.

Hope this will help on your ask.

Thanks,
Pravin

4

Thanks Satish,

I’m confident that for typical entitlement-like attributes, the attribute name is required as well. An object may have multiple managed attributes, and the sets of allowed values for those attributes could overlap.

My issue is that the documentation is not clear about which of the many get methods should be used and when. I’m hoping someone familiar with the internals of the implementation can explain the nuances.

5

combination of application name + entitlement value + entitlement type will be always unique in system .

6

@kjperkin Based on code inside the ManagedAttributer.getAll(Context, ManagedAttribute src)

It calls another getAll that accept name and value of ManagedAttribute. So In API Doc they said it will return 1 object but hard to say. but it always return 1 object. the reason is name + Value combination never return more than 1 object.

Based on all reading, i always prefer to use ManagedAttribute ma = ManagedAttributer.get(context, appObj.getId(), “memberOf”, groupDN);

7

The attached XML contains an Application, PreIterate Rule, CorrelationConfig, TaskDefinition, and sample Rule showing that the combination of (application name, managed attribute type, value) is NOT always unique. The application schema defines two account attributes named attr1 and attr2. Both attributes have the type set to String. Both attributes have the Managed, Entitlement, and Multi-Valued flags set. The account aggregation task promotes the values from these attributes to ManagedAttributes with type Entitlement.

ManagedAttributeTest.xml (9.1 KB)

8

@kjperkin
When we are dealing with ManagedAttribute object, it is always recommended to use the ManagedAttributer API. If my understanding is right, you are trying to fetch unique managedattribute object based on some input parameters.
In this case, you can use below method.

ManagedAtrributer attributer = new ManagedAttributer(context);
//Load one ManagedAttribute from the database.
ManagedAttribute att = attributer.get(SailPointContext con, java.lang.String appid, boolean permission, java.lang.String name, java.lang.String value, java.lang.String objectType)

//or you can use either of the below method as well
ManagedAttribute att = attributer.get(SailPointContext con, java.lang.String appid, java.lang.String target) //Get a ManagedAttribute for a permission.

//or
ManagedAttribute att = attributer.get(SailPointContext con, java.lang.String appid, java.lang.String name, java.lang.String value) //Get a ManagedAttribute for an entitlement.
9

Thanks, Soumyakanta. Empirically, these seem reasonable. However, I haven’t been able to find any documentation that made it clear that those are the right methods to use. What documentation I have found has some concerning inconsistencies. I was hoping to get a response from a SailPoint employee who knows what is going on behind the scenes, but maybe that is wishful thinking.

10

Or maybe I’m just not being proactive enough. They’ve got community contacts posted nice and prominently on the front page of the community, so…

@jthaytko As described above, I’m finding the JavaDoc for ManagedAttributer to be confusing, any ideas?

11

The java doc provides short description about all the methods and APIs available for the product. You can read through it and get an understanding about it.

In case you want to know the logic behind it, you can use the java decompiler and open identityiq.jar file. Go to the specific method/API path to learn more about it.

Note: You might not about to understand the full logic; but you can get an understanding of it.

URL: {IIQ_HOME}/doc/javadoc

12

As mentioned previously by others in this discussion, the combination of application, object type and value should be unique. Should, as theoretically it may not be, but it’s very unlikely to happen. The ManagedAttributer will log a warning on the get operations that find multiple instances matching the same criteria, but will eventually just return one.

Just to be clear object type is the name of the schema, not the fact that it is an Entitlement. An application can have multiple types of entitlements (group types, or non-group types).

Looking at a ManagedAttribute, these are the attributes that we should look for. Well, first, let’s look at an XML representation of such an object:

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE ManagedAttribute PUBLIC "sailpoint.dtd" "sailpoint.dtd">
<ManagedAttribute aggregated="true" attribute="groups" created="1718705560820" displayName="Users" hash="087984d44823bdc1c9e677262184385c292c486a" id="ac10042990261d1381902ad59cf41195" lastRefresh="1718785322074" modified="1718785322084" requestable="true" type="group" value="cn=Users,ou=groups,dc=training,dc=sailpoint,dc=com">
  <ApplicationRef>
    <Reference class="sailpoint.object.Application" id="c0a8c89c706916e3817069d7a20c02fe" name="389DS"/>
  </ApplicationRef>
  <Attributes>
    <Map>
      <entry key="cn" value="Users"/>
      <entry key="owner" value="cn=training.admin,ou=special,dc=training,dc=sailpoint,dc=com"/>
      <entry key="sysDescriptions"/>
    </Map>
  </Attributes>
</ManagedAttribute>

In the header we see (among others) the following interesting attributes:

  • attribute: this is the attribute that it corresponds to on the account schema.
  • displayName: the value that you would see in most places in the UI, but not so interesting for our search as it may not be guaranteed to be unique.
  • type: this is the object type or schema name that we should use for searching.
  • value: the technical, unique value per application, per schema type.
    (Note: often, the type and attribute are the same, but not always. This could lead to confusion.)

So, we found the first two necessary attributes: type and value. The third part of our puzzle is the application, which has a “hard link”, which we can reference as an application, the application name or id. In case of the ManagedAttributer, we can either use the full Application object or its id value to search for an object.

As an example, let’s say I have the id of an IdentityEntitlement object and need to find the corresponding ManagedAttribute, this is what I can do:

IdentityEntitlement ie = context.getObjectById(IdentityEntitlement.class, id);
if (ie != null) {
  ManagedAttribute ma = ManagedAttributer.get(context,
    ie.getApplication(),
    ie.getName(), 
    Util.otos(ie.getValue())
  );
  if (ma != null) {
    System.out.println(ma.toXml());
  }
}

I hope this helps…

– Menno

2 Likes
13

Thanks Menno,

I think we’re getting there… A few clarifying questions:

  1. There are some cases where objectType would give a non-unique result when using (application id, object type, value) to search. If you see the admittedly contrived example in my earlier post, although the object type is normally the schema object type, this will not be the case if the managed attributes are created simply by promoting attribute values (where the schema attribute is marked as Managed). In that example, both managed attributes get Entitlement as the object type. Is that intended product behavior?
  2. Earlier, you said the attribute name isn’t one of the pieces we want, but based on your code sample, ManagedAttributer.get(String, String, String) takes (application id, attribute name, and attribute value), so we would want the attribute name and not the schema object type. Is that correct?
  3. The ManagedAttributer API JavaDoc mentions permissions and nested schemas. Can you explain a little about how those other “kinds” of ManagedAttributes can come to exist?

Thanks,
Kevin

14

Hi @kjperkin,

  1. I have not yet had time to look at your example. The database may not prohibit duplicates, but under normal circumstances, duplicates should not be created. If attributes are just promoted, there may not even be a corresponding object type and in that case it will indeed behave as you describe.
  2. You would want the schema object type, but to prevent confusion, you could use the instance of the get operation with the extra parameter: get(SailPointContext con, Application app, boolean permission, java.lang.String name, java.lang.String value, java.lang.String objectType). where name is the attribute name and objectType corresponds to the schema name.
  3. In the almost 13 years that I’ve worked with IdentityIQ, I can only remember using permissions in training, not in any real-life scenario. So, forget about those. OK, just to explain what it is. In case of for example a database you could get access to a database schema or a table, which is what the entitlement represents, but the access to the database schema or table could have more fine-grained permissions, like you can select, insert or update records, but not delete them. Those would then be encapsulated inside the permissions. Provisioning of these permissions is often a “painful” process, which is one of the reasons they don’t really get used.
    – Menno
1 Like
15

Thanks for the confirmation about the behavior for managed attributes with no schema object type, and the explanation of permissions.

Your example is using this version of ManagedAttributer.get:

static ManagedAttribute get​(SailPointContext con, java.lang.String appid, java.lang.String name, java.lang.String value) Get a ManagedAttribute for an entitlement.

And it’s using ie.getName() which is the attribute name, right?

Thanks,
Kevin

16

Often the schema attribute and the object type are the same, but yes, it’s the attribute on the account schema.

17

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