Access modifiers

Limitations of Data Object Security Model

Data Object Security Model (DOSM) is used in implementations to ensure that the various users can only access relevant data. It is based on a hierarchical tree structure from which you can define security on every level, similar to a file structure.

In many situations, DOSM is too limited to support advanced requirements for Omada Identity implementation. For example, out of the box, a user can access and view identities if one or more of the following criteria are met:

• The user is a manager for the identity
• The user is the same as the identity
• The user administers a system which the identity has an account for
• The user owns a resource which is assigned to the identity
• The user is an HR manager responsible for the department in which the identity works.

The concept of the access modifier

An access modifier is a logical unit that can evaluate and modify access to data objects according to a ruleset.

More specifically, an access modifier is a .NET class that is used to modify and override the security rules stated by the DOSM.

You can apply an access modifier directly to the data object type or the view:

• Data Object types: Access modifiers are used here to increase the access otherwise stated by the data object type. This enables you to set the DOSM with very limited access for most users, and apply access modifiers to increase the access in certain cases. On processes, a normal user does not have read or updated access. An access modifier is implemented to allow to read and update a data object in processes that the user has created, or has a work item for.

• Views: When the specified view displays data objects, the view access modifier is applied. The concept of the view access modifiers is that a view will sometimes narrow the access otherwise stated by the data object type. For example, a user might be both a business manager and a role owner – each providing the user with access to specific identities. When the user starts a provisioning process, they should only be able to pick identities for which they are manager, and not identities for which they are role owner. In that case, the access modifier for the view used for selecting an identity will narrow the access that is defined by the data object type access modifier.

info

When an access modifier is in use in a view, it overrules any access modifier that may be specified on the data object type.

The following image shows an access modifier that is applied to a particular view called All identities.

Some access modifiers have parameters to configure the business rules that must apply, for instance ACCESSMODE on the IdentitiesAccessModifier. Here, the parameter ACCESSMODE has the value SYSTEMOWNER, so only system owners can see the data in this particular view Note that to See/Edit the access modifier for the view, you should go to the Advanced options section of the settings tab. When no ACCESSMODE is configured, the access modifier grants access according to all business rules. If, for instance, a user is both a Manager and a System Owner, then both the subordinate identities and the identities in owned systems will be displayed.

At first sight, the particular example may seem redundant, because you have already specified that the Visible to setting should restrict the view to be visible in the UI to System owners only, but when you add the additional security from the Access modifier and Access modifier parameters settings, they restrict the view to only the identities with a system managed by this system owner.

important

You should only use access modifiers for views to evaluate read rights for the actual view. For example, if you have access to a data object because of an access modifier that is enabled on a view, you cannot use the various detail pages for that data object. In other words, the overruling act triggered by the access modifier limits access to the view only, allowing only the display of the data objects in the view. The overruling act does not give you access to any detail pages for any of the displayed data objects, because these are defined by the access modifier on the data object type (if any) or the underlying DOSM.

When you access the details of a data object directly, and not through a view, the data object type's access modifier is always applied.

The concept of the view access modifier is that a view can narrow the access otherwise stated by the data object type or the DOSM. If no access modifiler is applied on a view, it falls back to the access modifier on the data object type (if any) or the DOSM.

For example, a user may be both a manager and a resource owner. Each role provides the user with access to specific identities. When the user starts a provisioning process, they should only be able to pick identities for which they are manager and not identities for which they are resource owner. In such a case, the access modifier for the view used for selecting an identity narrows down the access that is defined by the data object type access modifier.

Access modifiers can only modify Read and Update permissions. DOSM still controls the remaining permissions 100%.

Even though a data object type access modifier is specified, it is not always applied. This is the case when opening a view which filters on more than one data object type -- or doesn't filter on any data object type at all. In this case, the security "falls back" on the data object security model, which is why the DOSM must be configured with very limited access.

Access modifiers centralize the access rules and, for example, eliminate the need for building custom URLs for selection screens.

info

Omada Identity comes with a set of standard access modifiers to use with a default installation.

Standard access modifiers

Standard access modifiers are included in the out-of-the box system. You can implement your own access modifier classes.

API documentation

See the API Documentation for detailed information on the access modifiers available with the standard installation, and how to implement your own.

Some access modifiers are designed for use only in views because they have no access calculation logic, only load-option modification. The PrepareAccessCalculation method and CalculateAccess method are not implemented for these access modifiers. Several access modifiers use the parameter ACCESSMODE, which specifies whether access is permitted for MANAGER, SYSTEMOWNER, ROLEOWNER, or ALL. Other parameters are explained in the description of the specific access modifier.

• The length of the access modifiers parameter field is 1.024 characters.
• The AccessModifierUtils class has queries that look for the accessible identity IDs for managers, role owners, and system owners, which are used in the implementations of access modifier classes that are not view only.
• The access modifiers are located in the Omada.OE.AppLogic assembly or the Omada.OE.Solution.OIM.AppLogic assembly.
• Their namespaces are Omada.OE.AppLogic.AccessModifiers and Omada.OE.Solution.OIM.AppLogic.AccessModifiers.

Implementing access modifiers

You can implement an access modifier on a view or a data object through the dialog boxes for either a view or a data object. You should place access modifier classes in code method assemblies, because the application always loads the assemblies, and, as a consequence, also the available access modifier classes.