How to deal with dependant entitlements?

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Hi! I am having an scenario where I have 2 types of entitlements. Source is JDBC, but I think this question should be extensible to all sources.

Applilcation has 2 types of entitlements, for example let me name them “area” and “profile”. The profile entitlement means nothing for itself, in fact table row is like id_user, id_area, id_profile.

That means that some person may have the same profile in 2 areas, or different profiles on the same area, like this:

person1 - area1 - profile1
person1 - area2 - profile1
person1 - area1 - profile2

How can be managed something like this? I thouth something that can help, reading the cartesian product of area x profile, and letting user select all possible combos, but this should be difficult to read in the request center, specially those who have large names.

2

Hi @jsosa,

By management of the entitlement types ‘area’ and ‘profile’, do you mean setting up the requestable status of the entitlement based on prerequisites met, or do you mean the entitlement permutations allowed for users?

3

Exactly the entitlement permutations. Structure of security table is (id_person, id_area, id_profile).

In their application, when they go to the security module in app UI, they choose some user, then next screen shows available areas, and when clicking on some areas another windows comes, which display available profiles. So when selecting the profile, a new row is inserted (user/area/profile).

4

Hi @jsosa,

“area” and “profile” are managed in two different tables ?

5

Yes, there is a table for areas and a table for profiles, but there are only one table that join the three entities (user, area and profile).

6

I tried to impement a model in which areas and profiles are 2 entitlement types, and implemented logic in code, so that if I first request and area, is saved in some user’s field. On account schema, I marked id_area as entitlement sigle valued, and profile as entitlement multi-valued.

Then all profiles requested next, will be saved in the user-area-profile table with that profile. For selecting another area, user has to revoke current area (does nothing on code) and request new area (saves new id_area in the user table row). So, following reuqested profiles are saved right, because it always selects the id_area from user table before inserting user-area-profile.

Problem is that users can have the same profile in different areas, for example they can be administrators of area1 and area5. In this case I found that IDN does not meet the requirement. Suppose I have requesed area1 and profile administrator, and then revoked area1 and requested area5. At this moment all works fine. Administrator profile still appears as selectable in the Request Center. In fact, requesting it gets the green box with “success, 1 request was submitted”. But after that, I received a failure mail notification (and request goes to fail state) without passing through java rule.

I asked support if there were some way to bypass this validation, and at least let the last request reach the code, but they told me that IDN does not allow to request the same entitlement more than one time (it makes sense, but I deal with this scenario in previous implementations with other tools).

So, I think that only remains the cartesian product solution, that is, select id_area || # || id_profile as ID, desc_area || # || desc_profile as DESC from areas, profiles

This solution works, as in the rule I received both areas and profiles separated with #, but results in 50k entitlements, making the Request Center complex to handle… (and perhaps auditing activities too).

7

As you say “I thouth something that can help, reading the cartesian product of area x profile, and letting user select all possible combos” i think it is an alternative solution for this use case.

You can use JDBC BuildMap Rule for concatenate “area - profile” as one entitlement and in your JDBC provision rule you can split and insert in table as specified (id_user, id_area, id_profile).

8

Exactly… I just thought it in reverse, aggregating area and profile concatenated, and use the JDBC Provison rule to separate them. The real problem with that solution is that the resulting number of permutations should result in about 50k entitlements to be shown on Request Center. Adding noise to other sources’ entitlements also.

9

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