1.1.1. Session object and session attribute

All information that enters the provisioning service via searches in databases, imports of files or actions (Persistent Search) is converted to session objects.

A session object can be created from a number of different sources and formats and can contain a number of different characteristics. For instance, session objects can be created by performing searches manually or scheduled at a specific time in an LDAP catalog, an SQL database or by parsing some type of text file (LDIF, csv, Excel). Session objects can also be created by notifying the Provisioning service that a change/action has been performed in an LDAP catalog service that supports Persistent Search (Dirsync in Microsoft Active Directory).

Searches in LDAP are performed by using the LDAP search filter according to RFC 2254, and in SQL databases by using SQL commands and syntax.

A session object contains information on for example the name of the object, type of event, from which database it originates and if the object has been changed. The session object can also contain one or more session attributes. These attributes can contain name, value, type of event and also flags (e.g. if the attribute has been changed).

1.1.2. Actions

One or more Actions contain definitions of what shall be executed on one or more session objects. A policy also states in which order one or more Actions shall be applied.

Actions can be simple like for example changing the value of a specific session attribute, or creating a Microsoft Excel file with contents from objects- and session attributes. Actions can also be more advanced, for instance synchronizing users between two or more databases.

The provisioning service contains a number of accompanying Actions that can be used to build the logic that shall be applied to the information that is being parsed. These Actions are divided into three different categories that state the specific type (Getters, Modifiers, Setters).

1.1.2.1. Getters

Are used to parse and create new session objects and associated session attributes. It can also complement an existing session object with information from other data sources and add these as new session attributes.

Examples of usage areas:

·         Add phone numbers from a switch system to existing session objects, match with the session attribute “cn”

·         Create a new session attribute on all session objects with the name “objectclass” and add to a static value: “user”.

Table of Action of the Getters-type.

1.1.2.2. Modifiers

Are used to change existing session objects and associated session attributes.

Examples of usage areas:

·         Control if the session attribute “mail” follows the standard. If not, change the attribute to the correct standard.

·         Re-format a time stamp so that it, in a later action, can be exported to a Microsoft Excel sheet where it can be more easily read.

Table of Action of the Modifier-type.

1.1.2.3. Setters

Are used to write/save data from session objects and associated session attributes to one or more sources (database, file, Web services, etc.).

Examples of usage areas:

·         Create a Microsoft Excel or a PDF report and send it via e-mail to an indicated e-mail address.

·         Synchronize session objects that have been collected from an LDAP database and that have been changed via Actions, and save these to an SQL database.

·         Write back changed session objects to their original database.

Table of Action of the Setters-type.

1.1.2.4. API to develop own Actions

There is also an API to develop own Actions in case one of the associated Actions are not suitable for the purpose.

1.1.3. Policy

A policy has several functions and is the component that holds together the logical concept by there defining:

·         Which database connector and configuration (database object) that shall be used to collect information in order to create session objects.

·         It contains rules for how session objects shall be created. For instance, session objects can be created by performing searches manually or scheduled at a specific time in an LDAP catalog, an SQL database or by parsing some form of text file (LDIF, csv, Excel). Session objects can also be created by notifying the Provisioning service that a change/event has been performed in an LDAP catalog service that supports Persistent Search (Dirsync in Microsoft Active Directory).

Searches in LDAP are performed by using LDAP search filter syntax according to RFC 2254 and in SQL databases by using SQL commands and syntax.

·         If one or several Actions shall be included in the policy

·         In which order the Actions shall be performed

·         When a policy shall start and begin a desired process (see section on the Policy Scheduler)

Picture 4: Shows how a policy holds together the logical concept.

1.1.4 Policy schedulers

The scheduler is used to define when and how a policy shall be started and begin the process of gathering information and create session objects and session attributes etc. There are three types of schedulers that can be stated for a policy.

·         Manual

A manual policy can only be executed manually in the administrative interface or by defining an action to start a manual policy depending on a given prerequisite.

·         Time based (scheduled)

A policy can also be configured via the administrator interface in order to be performed on a given point in time or at a given interval.

·         Persistent Search

If a policy is configured to use an LDAP database which has support for LDAP Persistent Search or DirSync (Microsoft AD), it will be possible to choose the alternative “Persistent Search” as an option in the administrator interface. This type of policy starts a separate thread with a listener towards the LDAP database, which can be notified that a specific event has occurred in the database. Through the thread and the listener, events in the database can create session objects and session attributes based on what has occurred.

1.1.5. Database (connectors)

The database objects contain configuration on how the service can connect to various data sources. The database objects are used by both Policies and Actions.

Is used by policies to point out a data source in order to gather information and to create session objects and session attributes.

Is used by Actions in order to read and write to the same data source that has been defined in a policy or to other data sources.

Following are examples of databases that are supported:

·         LDAP catalogs (also Microsoft Active Directory and ADAM)

·         JDBC (Java Database Connectivity)

·         ODBC (Open Database Connectivity)

·         CSV File (Files with fields separated by a character, eg. a comma)

·         LDIF File (LDAP Data Interchange Format)

·         Web services (XML)