How could I integrate IDN with an applicatio with 4 level of entitlements?

Hi! I am needing some ideas for integrating IDN with a very complex application. I will try to explain like if it where a company which holds many hospitals.

Suppose that I have an application X, that have some users. In the application, every time I want to grant some functionality to some user, I go to some security area of the app screen, and first I select the Hospital. After selection is made, app display available cities where this hospital is located. Once city is selected, app displays the area (not all areas are available in all cities, for example Hospital A in Madrid does not have ophthalmology, but in Lisboa does). And finally, after selected hospital, city and area, then the app display some permissions (admin, receptionist, patient history read, patient history rw, etc). At this very end, is when app saves it on some DB (in a table that holds user_id, hospital_id, city_id, area_id, permission_id).

There is more consstraints to make the integration more difficult yet, for example, that HospitalA may display only Madrid and Lisboa, and HospitalB should display Buenos Aires and Montevideo. HospitalA-Madrid may display only shock-room and HospitalA-Lisboa may display shock-room and surgery.

So I am needing some ideas on how can I translate this into IDN. I think that in this case choosing the connector techonology is a challenge itself, but the more complex thing is how to bring this application behaviour to IDN Access Request system.

You will very likely need to create a custom connector. If the application in question is SaaS hosted and not within your intranet, then building your own SaaS Connector is the best option since it allows complete control over all of the operations. If your application is within your company’s intranet, then you will need a VA based connector like the Web Service connector. The Web Service connector will require custom rules to handle the complex entitlement structure.

In either case, handling that level of nested entitlements will require custom code.

Hi @colin_mckibben thank you for your response.

I would like to figure how to deal with the UI part, because IDN does not have to navigate through some entitlements, based on what user selects. For example, if I have entitlements of type A, B, C and D, in that order and each of dependant of the previously selected.

In native appliclation, admin select some user to grant him permissions. He first selects a1, then screen shows all B type entitlements available for a1 entitlements. Suppose user selects b1. The same for the rest, after selecting b1, application displays C entitlements that are available to b1. Admin selects c1, and then selects d1.

Effective permission should be the four entitlement a1,b1,c1,d1 (for example this can be saved in a database table in which every row holds vaues for user, A, B, C, D).

The unique solution I thinked was to concatenate all possibilities (cartesian product A x B x C x D), but this will introduce some noise to admins users, because when they want to grant a <a,b,c,d> tuple, it will be some tedius to select this on the IDN UI screen. Also, not all B permissions are available after some A is selected, and in that line, not C permisssions are available for A-B combination, and not all D permissions available to A-B-C selection.

If there is some other approach it will be welcome, it is not rare in applications to have this type of permission granting. And to be honest, in my experience using other IDM tools they all have this problem.

A common trick for flattening nested object is to use dot notation to reference the item path. For example, let’s say entitlement C1 is a child of B1, and B1 is a child of A1. To display C1 in the IDN UI, you would aggregate this entitlement as A1.B1.C1. As you mentioned, this could get pretty noisy if there is a lot of crossover of child entitlements.