Security and Audit

This writer writes audit events using the Logging Configuration of the MDM Server (see Logging Configuration). You can set the name of the logger.

This writer writes audit events using standalone configuration and a logging engine not connected to the MDM Server logging. You must provide the name of the configuration file.

The following is an example of the nme-audit-logging.xml configuration file:

When multiple event filters are configured, they are evaluated in the order they appear in the XML. For each event, the first filter that matches triggers the audit — no subsequent filters are checked for that event. If no filter matches, the event is not audited.

For example, if AuditAll is listed first, it matches every event and all subsequent filters are effectively ignored. Order your filters from most specific to least specific to achieve fine-grained control.

Example configuration of event filters:

The following table lists all available event filters.

Requests refused for a missing permission are audited as UNAUTHORIZED events regardless of the event filters. Calls to the operational REST API endpoints appear in the audit log only if an event filter captures them (AuditAll, AuditDefault for writes, or OpsView and OpsWrite) and nme-audit-logging.xml contains a logging rule for the OPS_VIEW or OPS_WRITE event type. For example, to audit changes:

Several event filters have additional parameters or specific behavior. Those are explained in the following sections.

This default event filter audits all executions of batch operations and calls to native services belonging to the Special services or Write services groups.

Provide a list of regular expressions that are evaluated against all configured batch operations. Execution of all matched batch operations is audited.

Provide a list of regular expressions that are evaluated against all configured native services. A call of any matched native service is audited.

You can provide a list of source systems, so that only reads of instance records from those systems are audited. Otherwise, all reads of instance records are audited.

You can provide a list of master views, so that only reads of master records from those views are audited. Otherwise, all reads of master records are audited.

Provide a list of entities:

Provide a list of entities (both instance and master):

To include HTTP headers in the audit events, add the following configuration. List all the headers that should be included into the audit event.

The ATTRIBUTES part of the audit event JSON output will be enhanced with the HTTP_HEADERS:

When a user has multiple roles, their permissions are combined additively — the user receives the widest access granted by any of their roles:

Provide a list of regular expressions that are evaluated against all configured batch operations. Permission to execute all matched batch operations is granted.

Provide a list of regular expressions that are evaluated against all configured native services. Permission to call all matched native services is granted.

You can provide a list of source systems that the role has permission to read from. Otherwise, the role is granted permission to read all instance records.

You can provide a list of master views, so that the role has permission to read master records only from those views. Otherwise, the role is granted permission to read all master records.

Provide a list of entities:

Optionally, the entity element can contain a list of columns and conditions.

If there is at least one column, only the configured columns are visible to the caller. If there are conditions specified, only the records passing all conditions are visible to the caller (that is, multiple conditions are combined by the AND operator).

A condition’s column can be any column defined in the model configuration and several internal engine columns (eng_system for instance entities and eng_active for all entities).

An access attempt to invisible columns and records is silent. However, an access attempt to records of an entity the user cannot view at all is considered unauthorized and is logged according to the configuration.

Grants permission to write all instance records across all entities and source systems.

Grants permission to write all master records.

You can optionally provide a list of master views to limit the permission to specific views. Otherwise, the role is granted permission to write to all master records.

You can provide a list of entities, which can now include both instance and master entities. For backward compatibility, when no layer is specified, the entity is treated as an instance entity.

Optionally, the entity element can contain a list of conditions and sourceSystems (for instance entities).

If conditions are defined, only the records passing all conditions can be written by the caller (that is, multiple conditions are combined by the AND operator).

The caller can write records to any of the source systems specified (that is, sourceSystems are combined by the OR operator).

An attempt to write a record not passing the configured conditions and allowed source systems is considered an unauthorized attempt and is logged according to the configuration.

If a WriteEntities permission lists specific entities, it must also include the entities that an operation changes indirectly: the child master entities and the corresponding instance entity when the role deletes or merges an authored master record, and the dependent entities of a processDelta service the role calls (see Read-write Services > Change detection). Otherwise, the operation is refused even if the request contains no records of these entities. You can restrict the added entities with sourceSystems and conditions as usual.