Identity Manager Developer Guide

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 is meant for developers wishing to extend the PhenixID Identity Manager web edition functionalities.
The developer documentation is divided into a number of specific documents, this guide is the most general and provides an overview for the common extension scenarios as well as links to detailed information.

To read this guide, knowledge about Java™ development and the PhenixID Identity Manager as a product is assumed.

When to Extend

Currently there are eight extension points in IM qualifying as filter extension points. Depending on needs and requirements one of the extension points will give a developer the possibility to override the standard behavior. Sections below will guide you to select the most suitable extension point. Each extension point will have a document of it’s own for more drill down explanation and a corresponding example file for getting started purposes.

If this guide don’t give you enough information feel free to contact the phenixid support.
Information on how, is found on http://support.phenixid.se

Javadoc

IM comes with a set of Javadoc. This provides help for developers finding out what API to use when wanting to extend or override.
This document, as well as the more extensive filter documents, uses the new Javadoc as base when referring to classes or interfaces.

Most of the examples in the filter documents extends some kind of abstract base class. It is assumed developers wanting to extend IM do the same.
Download Javadoc here: LINK TO DOWNLOAD JAVADOC

Filter

Filter execution flow

When a form is opened or submitted control and form filters may run if configured. If there are any custom controls in the form lifecycle methods will be called for those as well.

When a form is opened initialization logic will run on the backend:

  1. Control filters configured for init runs.
  2. Form filters configured runs the init method.
  3. Custom controls runs the initialize method.

Then the user is presented with the form and if it is saved presave logic runs:

  1. Custom controls runs the preSave method.
  2. Control filters configured for preSave runs if any changes occured for the control data.
  3. Form filters configured runs the preSave method.

After presave filters the default save logic runs in the application. IM writes any changes to the database before executing post save logic:

  1. Custom controls runs the postSave method.
  2. Control filters configured for postSave runs.
  3. Form filters configured runs the postSave method.

The execution flow described is for one form. If there are multiple forms  submitted logical steps are performed per form and lifecycle type (init, presave and postsave). This means there should not be dependencies between filters configured in different forms for same event lifecycle event type.

Control Filter

A control filter is linked to an attribute object. Here it can validate data or alter the state of the attribute of an object. It has no knowledge about other attribute objects in the IM form. Therefore it can not change anything but it’s own state.

Typically, a control filter is used to validate data before saving it. It may also be used to clean it before presenting it to the viewer.

A control filter can stop the save operation if needed.

More on control filter in document Control Filter

Form Filter

Form filter, unlike control filter, is linked to an IM form. This gives the filter knowledge about all attribute objects in the form and can therefore affect all attribute objects in the form it is linked to.
A form filter can stop the save operation if needed.

More on form filter in document Form Filter

Form Restriction Filter

PhenixID Identity Manager gives out capabilities through out forms. Each form provides a set of editing or just viewing possibilities. For some reason one may want to prevent a form from being displayed for a specific object. This is where restriction filters are applicable.

It is possible to achieve form restrictions just by sheer configuration in the form designer tool. However, this may sometimes not be enough.
The solution may be to write a form restriction filter.

More on control filter in document Form Restriction Filter

Search Filter

Every time an administrator clicks on a tree branch, executes a predefined search or in some other way initiates a search operation, the search filter will be used. When a search filter is connected to IM it can affect ALL searches. Because of this it is possible to let your custom logic add or remove objects in the result about to be presented to the administrator.

More on search filter in document Search Filter

Search Filter for Predefined Search

When executing a predefined search it is possible to connect custom logic to it.
This could for instance be:

  • Data validation on user input
  • Completely override search logic with custom logic
  • Alter the result set before “returning” it to the screen

More on search filter for predefined search in document Search Filter for Predefined Search

Authentication Filter

IM comes with a standard authentication scheme. Sometimes this needs to be overridden. Developers then can provide custom authentication logic. Often this includes validating users in external systems.
More on authentication filter in document Authentication Filter

Policy Filter

Just after an administrator is authenticated IM policies are loaded. Policy filter allows developers to manipulate with the administrators IM policies.
Common scenario when policy filter is used is when IM predefined searches or forms should be added to or removed from the administrator. This extension point can also be used to store session data needed later on.
More on policy filter in document  Policy Filter

Event Filter

IM contains the common CRUD, (create, update & delete), event types. On every event type it is possible to append custom logic.

IM categorizes the CRUD events into a number of smaller event types:

  • The DELETE event
  • The MOVE event
  • The RENAME event
  • The CREATE event
  • The EDIT event

Typically custom event handling can be used to verify that an administrator is allowed to delete, move or rename an object.

More on event filter in document Event Filter

Presentation Filter

When a result set is about to be presented for an administrator it is possible for a developer to apply custom logic for each field in the data grid in the main window. In this custom logic it is possible to format data in a more friendly manor. This can typically be dates, numbers or names.

This filter type should not be used as a control filter.

More on presentation filter in document Presentation Filter

Extension

Custom Controls

IM provides a rich set of controls to represent data, ranging from simple text fields to complex multi-list searches, to be used in forms.

Although the controls provided with IM provides sufficient functionalities for most situations, sometimes a new control (custom) must be created.

More on Custom Controls in document Custom Control V3

New extension points

IM has a number of new extension points making IM more extendable.

Right click menu extension

When right clicking on an object the menu about to be shown to an administrator can be passed through custom logic.

More on right click menu extension in Right Click Menu Provider

View extension

PIM comes with four views (there are also two older views that are still available but not supported anymore).

The four views are:

  • MAIN
  • SELF SERVICE
  • BROWSE
  • PREDEFINED SEARCH

For more information about views, please read PSD1103

More on view extension in View Extension

Custom data handling extension

Since version 4.6 it is now possible to override how data is gathered and saved from data sources.
This is done trough this extension.