Making an Update Notification Request

Administrative Update Notification uses the UPDATE form of the ESF API.

The Update Notification request has only one required parameter, a pointer to a valid ACEE (returned by an VERIFY request). Note that this means that Update Notifications require a valid set of user credentials. This allows Update Notifications to be audited with user information, and in the future may be used to restrict access to the Update Notification feature.

The Update Notification request can contain additional information that describes what was updated. Setting this information may reduce the amount of cached information that ESF and the ESM Modules have to discard, or the additional work needed to be done by the ESM Modules to update other internal state (such as information about group membership).

Not setting this additional information has some performance cost, but will probably only be noticeable under relatively heavy loads.

The optional fields include:

Note that if a user's primary group is changed, that will generally be a user update. Supplementary group membership may be stored as part of a user's definition or as part of a group's definition, depending on the ESM. For the MLDAP ESM Module, changes to a user's supplementary group information should be signalled with a saf78_TYPE_UPDATE_GROUP Update request.

You can also set the ESM Index in the request block to a non-zero value to indicate that the specified ESM Module is the one to receive the update notification. (ESM Modules are numbered consecutively from 1, in the order that they're shown in the security configuration in MFDS.) Unless performance becomes an issue, however, we recommend leaving this set to 0 and letting all ESM Modules be notified, to avoid errors that could leave an ESM Module with stale data.