Entitlement assignement restriction

IdentityIQ (IIQ) IIQ Discussion and Questions
, ,
1

Which IIQ version are you inquiring about?

[Replace this text with your version of IIQ. The more specific you can be
8.3

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

Hello ,

We have a use case in Manage Access where a user can assign two different types of entitlements for a single application account :

  • Entitlement Type A
  • Entitlement Type B

These two entitlements are logically linked :

  • Each value of Entitlement Type B is associated with a specific value of Entitlement Type A (via an attribute like entitlementAId stored on Entitlement B).

Currently, when requesting access users can select Entitlement Type B independently which creates ambiguity and allows invalid combinations.

We want to enforce a dependency such that:

  • When a user selects Entitlement A , only the linked Entitlement B values are available for selection
  • If the identity already has an Entitlement A,an automatic filter should display only compatible Entitlement B

We have thinked to do that in RequestObjectSelector rule , is there any better solution ?

Thanks
Best regards

2

hi @alshahim04

Yes — RequestObjectSelector is the right solution and there’s no better OOTB alternative for this in IIQ 8.3.

  • Use RequestObjectSelector to dynamically filter Entitlement B based on:

    • The selected Entitlement A, or

    • The Entitlement A already assigned to the identity

  • This enforces valid combinations at selection time, preventing bad requests upfront.

  • Optionally add a backend validation rule as a safety net, but UI filtering is the best practice.

:white_check_mark: So your approach is correct and recommended.

3

Hello @haideralishaik ,

Thanks for your answer ,

I have a question in the case of selected entitlement A , how to check if the requestee has selected an entitlement and read its value ?

Best reguards

4

hi @alshahim04 In a RequestObjectSelector:

  • You can reliably read Entitlement A if the identity already has it and filter Entitlement B accordingly.

  • Reading Entitlement A selected earlier in the same access request is not reliable in IIQ 8.3, as the selector may not always see same‑request selections.

The Best practice:
Use RequestObjectSelector for UI filtering based on existing entitlements, and add a backend validation (workflow/pre‑provisioning) to block invalid A–B combinations as a safety check.

5

@alshahim04 RequestObjectSelector can definitely help you with your 2nd case where you only need to show entitlement B and A is already assigned. But it’ll not help you with your first case, where user select A and then it should show B.

I would recommend, if combinations are not so high you can load them as EntA ~ EntB for all possible values and let user select them as per their requirement.

In case you need the specific behavior (as you mentioned), then you can create a custom form using quicklink where you’ll all flexibility to load the form as you need. Another alternative is to create a plugin to intercept the access request page and show the values as you need.

Considering your usecases, I feel creating a custom request form is a right approach.