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

There are two ways to collect theoretical rights:

• Permissions are provided with accounts
• The criteria for obtaining permission are known using model policy

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

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

Collecting IAM Rights allows the you to directly provide permission/account links in import files. These are often provided by a IAM solution.

A dedicated target for collect lines has been added to allow the ingestion of IAM rights directly:

It is required to reference in the target to a given unique permission and a given unique account(i.e. referencing application/permission and repository/account pairs):

Role and comment are optional parameters that provide more information, they don't affect theoretical rights:

Here is some sample data to illustrate:

• DFIN_Agents role grants Elyxo/User and RACKSTATION/FIN_Share permissions to the VIOLET9 account in the ELYXO repository and JHORTON19 account in the ACME repository.
• DFIN_Admins role grants Elyxo/Admin and RACKSTATION/FIN_Share permissions to the ROMAIN11 account in the ELYXO repository and OLIVA8 account in the ACME repository.

Once ingested into the import tables, theoretical rights between Accounts, Identities and Permissions are not yet created. They will be created after the activation of the timeslot during the theoretical right model policy step, just after the manager policy step.

During the theoretical right model policy step, the accounts provided in the collect are linked with identities through the reconciliation.

After these steps, refer to the control section.

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

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

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

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:

Using an HRCode as param1:

• DFIN_Agents role grants the Elyxo/User and RACKSTATION/FIN_Share permissions for the identities having the HR000285, HR000878 and HR000666 HR Codes.
• DFIN_Admins role grants the Elyxo/Admin and RACKSTATION/FIN_Share permissions for the identities having the HR000007 HR Code.

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:

The content of this table will be used by the 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.

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

• For HR code

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:

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).

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

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

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