Duplicate Validation in Child Tables with Entitlements and Composite Keys

User_NMGY9

Hey guys,

We are trying to implement duplicate validation for child data/entitlements in OIM 11.1.2.2.0 and are using the following section in the OIM Admin Guide as our main reference: Managing Application Instances - 11g Release 2 (11.1.2.2.0)

According to our business use case, we need to implement a scenario that is very similar to the one mentioned in line 5 of Table 9-2:

We have a child table with 3 colums COL_1, COL_2 and COL_3, where COL_1 has "Entitlement = true" and both COL_1 and COL_2 need to act as key values for provisioning. This means that a user must be able to request two entitlements of the same name (COL_1) which have different values for COL_2 on the same account (so OIM should only validate the composite key consisting of COL_1 and COL_2).

However, it seems we can only grant every entitlement instance (COL_1) once to an account.

Do you know if there is any way to configure OIM in a way to achieve this desired behavior?

Thank you very much in advance for your answers!

Best regards

Kevin Pinsky

It sounds like your entitlement is not just 1 value but multiple.  If this is the case, then your entitlement must have more than 1 field to be populated, and both must be made as key fields.

-Kevin

Abhishek Singh 'J_IDM'

Hi,

I have never tried the scenario, but after going through the link and line # 5

It says one attribute has Entitlement=true, and its not saying that you can have multiple fields(attribute) marked for Entitlement as true. Only for Key attributes used for reconciliation can have many recon key values.

Defined. One attribute, say UD_CHILD1_ENT1 has Entitlement=true Note: Entitlement attribute is a subset of the reconciliation field mapping key attributes.

Defined. Two or more attributes, say UD_CHILD1_ENT1 and UD_CHILD1_ENT2 are defined as key attributes in recon field mapping for child table UD_CHILD1.

Valid

Valid

so you can grant entitlement instance (COL_1) once to your account. Also please analyze the values stored in ENT_LIST and CATALOG table. It will give you understanding of how the entitlements are displayed in catalog.

~J

Abhishek Singh 'J_IDM'

One more point which I have earlier noticed with R2:

The Group lookup will have entries like:

Code Key      : Decode Key

AD GROUP1 : CN=group1 , ou= xyz,

AD GROUP2 : CN=group2 , ou= xyz,

AD GROUP2 : CN=group3 , ou= xyz,

In this case two entitlement AD GROUP2 will be shown in catalog search and user can have two entitlements in his/her profile with same name. I believe you can test the behavior in this way.

User_NMGY9

Hey guys,

thank you for your answers!

@Kevin: You are right, we have multiple required fields in our child table. What do you mean by "your entitlement must have more than 1 field to be populated, and both must be made as key fields"? The thing is that we do only want to have one of the child table columns marked as entitlement, and the second required part (COL_2) is also marked as key in the recon (kind of interesting that we need to mark it as recon key, even for provisioning).

@J_IDM: We are considering to multiply the values of the lookup that is used for the COL_1 entitlement, even though this is something we initially wanted to avoid.

User_NMGY9

@Kevin: You are right, we have multiple required fields in our child table. What do you mean by "your entitlement must have more than 1 field to be populated, and both must be made as key fields"? The thing is that we do only want to have one of the child table columns marked as entitlement, and the second required part (COL_2) is also marked as key in the recon (kind of interesting that we need to mark it as recon key, even for provisioning).

Thank you!

Kevin Pinsky

Sounds like you need to have your COL_1 actually be a concatenation of COL_1 and COL_2 into a single column because your entitlement isn't actually just the first value, but a combination of two, which doesn't sound like it is supported.  It's like your are trying to make a Child Table of a Child Table (One to Many to Many) which is not a format that is supported.

-Kevin

User_NMGY9

Alright, so it looks like "multiplying" is the way to go. Thank you!