Authoritative source policy

Horizons feature enabled

With the Horizons feature enabled, the Authoritative Source Policies are not used to determine which source system is authoritative for the property on the Identity, Context, or Resource objects in ODW. For more information, go to Authoritative Source Policies.

Authoritative Source Policies are used to control the origin of the data processed by Omada Identity. Some data can be maintained by Omada Identity and some can be maintained externally, e.g. in an HR system, and only exported to Omada Identity. This source of data is controlled on the property level of a data object.

note

Binding rules with the authoritative source set to "External" are only applied if the attribute is imported from the target system.

An authoritative source policy can be applied to the following objects:

• Identity
• Resource
• Context

For those objects, the following attributes are in scope:

• Standard attributes, except for housekeeping attributes
• Configured extension attributes

Each object may only have one effective authoritative source policy. The binding rule for each attribute controls whether the value is imported from Omada Identity or the target system. By default, an attribute is imported from the target system, for example, in these cases:

• The object does not exist in the Audit database, e.g., during initial load.
• The object does not have an authoritative source policy, for example, after an upgrade from Omada Identity v12.
• The authoritative source policy for the object does not have a binding rule for the attribute.
• The attribute in the binding rule has not been translated to the ODW attribute name.

Authoritative source policies are evaluated when a data object is created or updated. They take effect in the following places in Omada Identity:

• In the ES portal, a form field becomes read-only if it is maintained in an external system.
• When data is imported into the Omada Identity portal from ODW, a policy can prevent certain properties in a data object from being assigned if they are not allowed to be maintained externally.
• ODW will not import data from a target system if it is maintained in Omada Identity.

note

You should trigger the Reset internal high-water mark feature in the import data process if you make changes to the authoritative source policies, as the collection of Master Data from is also affected by it.

Omada Identity comes with two built-in policies:

• Employee policy
• Non-employee policy

The Employee policy prevents the first- and last name of employee identities from being modified in Omada Identity.

The Non-employee policy prevents the first- and last name of non-employee identities from being modified externally.