Version:

MarketplaceSupport

Theoretical rights

Theoretical rights allow to load a list of accesses Identities should have in theory, and compare it with real access rights.

The goal is to run controls, that list over-allocations and under-allocations:

  • Over-allocations: rights the Identity has in real applications that are not in the theoretical rights model
  • Under-allocations: rights the Identity should have according to the theoretical rights model, but does not have in the real applications

Theoretical rights model

To achieve this goal, you have to implement the following steps:

  1. Collect of the theoretical rights model, from an IAM application
  2. Define the theoretical rights model policy using the ingested data
  3. Run controls for the theoretical rights to return over-allocations and under-allocations

Project & Facets

If possible, don't implement it yourself, but use the facets & what is included in the project already:

  • bw_iamcollector:
    • Allows to load the Theoretical rights of an IAM application into the ledger (Silo & collector lines)
    • It also contains a model policy: iam_rolemodel
    • You might need to add a collector line to convert your source data to the format required by this facet
  • IAP / IAS, already contains:
    • Theoretical rights controls: bwcd_ACC17 and bwcd_ACC23
    • Fragments for theoretical rights:
      • webportal/pages/bw_fragments/iamapplication: to display the role model of the IAM applications
      • /webportal/pages/bw_fragments/identity/theoreticalrights: to show over-allocations on Identities

Collect

There is a dedicated target in the collect, for theoretical rights:
Theoretical rights target

It requires to point on the target permission (which means to point to the couple application/permission):
Theoretical rights target permission

And the parameters used by the model policy to determine the population that should have said permission:
Theoretical rights target model params

The model can vary between clients.
It can use an identity's job, organization, or HR code.

Here is some sample data to illustrate:

Using a job title as param1:

Rule type
Application code
Permission code
Role
param1 (Job)

IAMTYPE

Elyxo

User

DFIN_Agents

Actuary

IAMTYPE

RACKSTATION

FIN_Share

DFIN_Agents

Actuary

IAMTYPE

Elyxo

Admin

DFIN_Admins

Actuary_adm

IAMTYPE

RACKSTATION

FIN_Share

DFIN_Admins

Actuary_adm

Using an HRCode as param1:

Rule type
Application code
Permission code
Role
param1 (HR Code)

IAMTYPE

Elyxo

User

DFIN_Agents

HR000285

IAMTYPE

RACKSTATION

FIN_Share

DFIN_Agents

HR000285

IAMTYPE

Elyxo

User

DFIN_Agents

HR000878

IAMTYPE

RACKSTATION

FIN_Share

DFIN_Agents

HR000878

IAMTYPE

Elyxo

User

DFIN_Agents

HR000666

IAMTYPE

RACKSTATION

FIN_Share

DFIN_Agents

HR000666

IAMTYPE

Elyxo

Admin

DFIN_Admins

HR000007

IAMTYPE

RACKSTATION

FIN_Share

DFIN_Admins

HR000007

The end-result might be the same, even if the model is not build the same way. Some methods require larger files, like using the HR code to define theoretical rights for each identity (instead of using the Job title for instance).

The data collected using this target in the collector line can be retrieved the Theoretical right model in the views:
Theoretical rights model view

The content of this table will be used by the model policy.


Entitlement model policy

The entitlement model policy will use the data loaded by the collect in the Theoretical right model to determine for each permission the target population (identities).

It is defined in the model folder of the project, and the logical is very similar to manager policy.

Model policy project explorer

Model policy

Each rule defined in the Theoretical right model will be called, passing the parameter values set in the collect (see previous point) and returning identities that should have the associated permission.

Based on their Job Title or HR code if we take the examples from earlier, associated model rules should be set as below:

  • For Job

Model rule with Job

  • For HR code

Model rule with Job

For each rule, all Identities returned by it will be linked to the concerned Permission by a Theoretical Right. Those results of the model computation will be stored in the database, and can be retrieved from a view using the Theoretical rights entity:

Theoretical rights entity


Controls

Now that the model, theoretical rights and real rights are loaded, we can run controls to compute over-allocations and under-allocations.

Theoretical rights controls are type 5 controls (Theoretical entitlements), with the control result type determining over-allocations (=1) or under-allocations (=2).

Active identities rule

A theoretical rights control requires two rules that will determine the perimeter of real rights the controls are run on against the theoretical rights model:

  • Identities, for example active identities only

Active identities rule

  • Permissions, often permissions that are used to define the theoretical model

Active identities rule

For each Identity/Permission couple returned by theses rules:

  • If the Identity has a real right and a theoretical right to the Permission, no discrepancy returned, we are in the normal situation
  • If the Identity has a real right but no theoretical right to the Permission, a overallocation discrepancy is returned
  • If the Identity has no real right but a theoretical right to the Permission, an underallocation discrepancy is returned

IN THIS PAGE