Using access modifiers

You can assign an access modifier to:

• A data object type.
• A data object view.

Access modifier assigned to a data object type

An access modifier, which is assigned to a data object type, is applied whenever data objects of that specific type are loaded. However, the access modifier is skipped if data objects of more than one, or of unspecified, types are loaded.

Access modifier assigned to a data object view

Use a view access modifier to display data objects in a view. An access modifier that is assigned to a view overrides an access modifier assigned to a data object type. However, a view access modifier is only used to call ModifyLoadOptions, never in connection with calculating access.

Even if you have specified an access modifier for a data object type, it is not always applied. An example of this is when you open a view which either filters on more than one data object type or does not filter on any data object types at all. In such cases, the system makes a 'fall back' to the DOSM. This is the reason is why you must configure the DOSM with very limited access.

An access modifier is normally implemented to deal with data objects of one specific data object type. It can, however, be set up handle more than one type of data objects. An access modifier must deal with all types of users seeking access to the data objects.

An access modifier can both add and remove access compared to the permissions stated by the security model. Under normal circumstances, it only adds access. This is because the system sometimes 'falls back' to the DOSM.

Reverting to DOSM

The system cannot always apply an access modifier when it loads data objects. This is the case if data objects of more than one data object type are loaded.

Because the system, under some circumstances, falls back to the DOSM, it is important that you define the DOSM using a least-access principle.

This means that as a default when you implement Omada Identity, you should configure the data object security so that only administrators and maybe data administrators have access to everything in the system.

The suggested setup of the data object security model follows the least-access principle.

If no access modifiers are applied to a process target, view, and so on, the security from the DOSM is applied. You must restrict the access as much as possible.

For example, you should not assign Everyone the Read access to identities. The IdentitiesAccessModifier controls which identities you can access. If you create a view, where an access modifier that restricts access is not in use, and the security resorts to the DOSM, then Everyone can view those identities. Their Read access in the DOSM takes precedence because the access modifier is not in use.

Suggested setup DOSM

The suggested security setup is described in the following table. It is provided as an example, not a best practice because a best practice depends entirely on the specific situation.

Data object	Security
Root	Administrators: Full access
Root\System data\Processes templates	Administrators: Full access Everyone: Read, Clone
Root\Processes	Administrators: Full access Everyone: Create
Root\Target objects	Administrators: Full access Everyone: Create

Since a regular user does not have Read access to the Target Objects folder, it is important to apply the access modifier ProcessTargetAccessModifier to each custom data target object type within that folder.

By default, regular users cannot edit the properties of their own profile. To allow the users to do so, you need to update the form named My profile. Enable the OK and Apply buttons on the form and remove the read-only flag on those form fields that you want to make editable. The form itself will be still read-only if it has not been added as an allowed property in the configuration object named AccessModifierConfig_IdentitiesAccessModifier.

recommendation

• Assign the role Data Admins with the access to Create, Read, Update, Move, and Delete.
• Assign Read access to Master Data for Everyone. If you do so, you must maintain the security on the individual folders.

Apply an access modifier

To a data object type:

1. Go to the Data object type view.
2. Select the data object type to edit.
3. Click Access Modifier.
4. Select an access modifier in the dropdown.
5. Add the access modifier parameters.

To a view:

1. Go to Views.
2. Select the view to edit in the list.
3. Open the Advanced settings section.
4. Select the access modifier in the dropdown.
5. Add the access modifier parameters.

Additional features

The access modifier concept enables you to implement the following scenarios:

• Control the access to target objects generated by processes. Typically, normal users should only have access to target objects (representing, for example, some kind of request) if they created the request or they are assigned to one of the activities in the process which is working on the target object.
• Control security based on property values. For example, you can apply this in a helpdesk solution where the end-user should only be able to see target data objects which are "tagged" with a company (reference property value) that is the same as the company that is specified on the user profile.
• Control access to users and groups. In some solutions, it is not relevant for users to see all other users in the system.

Omada recommends that you configure the DOSM with very limited access, with access modifiers applied on top of the DOSM. Because access modifiers are only applied in views which filter on a single data object type, this has an undesired side effect in the global search functionality. Because the search screen "falls back" to the DOSM, it displays only a few data objects. You must consider this when you design the DOSM for your organization's needs.