IM Developer Guide – Event Filter

About this guide

This document gives an overview of the installation of PhenixID Identity Manager. Additional information is found on PhenixID web site or through PhenixID support.

Summary

This document explains Event Filter in PhenixID Identity Manager version 4.8. It is assumed reader is familiar with both the Identity Manager and Identity Manager Configurator. The document is a part of a collection of documents explaining how to extend and customize Identity Manager. In addition there is also Javadoc and sample code.

Mentioning of abstract base class assumes these are used when developing custom code.
First time readers are recommended to read overview document, IM Developer Overview.

Definition

The Event Filter has five point of extension in IM:

  • Object deletion – Enables developer to override standard deletion mechanism. For instance move object instead of deleting it.
  • Moving an object – Enables custom logic to validate if the administrator is allowed to move object or verify that the selected target is allowed to move object to.
  • Rename an object – Validate if rename is allowed or if new name is allowed.
  • Object creation
  • Edit an object

Since Form Filter and Restriction Filter much overlap creation and edit event only the three first events will be covered in this document.

Developing Event Filter

An Event Filter is a Java class. Required source level is version 8. An event must implement se.nordicedge.interfaces.CustomEvent

A base class is provided through:

se.nordicedge.misc.tab.filter.BaseEventFilter

Flow of Execution

  • isEventSupported is called. If the return is false, this filter is not designed for this type of event, so the configuration is not correct. The execution stops.
  • allowEvent is called. If the return is false, the event is not allowed for this logged in user or this object and the execution stops.
  • preEvent is called. If the return is true, a veto is raised and the event will not be executed.
    • If the variable errorMessage is assigned, the message will be displayed to the administrator and the execution stops.
    • If the variable errorMessage is not assigned, Identity Manager will assume that the filter handled the event on its own and the execution continues.
  • postEvent is called

Configuration

Linking an event filter is done with policies in DSEditor.properties.

The actual Java class file must be located in the class path for the Identity Manager.

Set the desired policy to the full package name and class name. Do NOT include “.class” suffix.

EVENT_FILTER_CREATE=myPackage.myCreateFilter
EVENT_FILTER_DELETE=myPackage.myDeleteFilter
EVENT_FILTER_EDIT=myPackage.myEditFilter
EVENT_FILTER_MOVE=myPackage.myMoveFilter
EVENT_FILTER_RENAME=myPackage.myRenameFilter

An Event Filter can be written for all event types, but this is not recommended. Keep Event Filter logic separated based on event logic is a good rule of thumb.

Configured Event Filters will have effect on all operations. A never ending loop may occur if calling move operation from the move event filter. To avoid such a loop consult the Javadoc.