Product Features
Identity Provisioning may be used for many purposes, the most common are:
- Quality Control of existing information from data sources e.g.
- Verify that userID and other objects follow corporate naming standards
- Cell phone numbers syntax follows international code standards +4670…
- Create Reports, information can be consolidated from one or multiple data sources. Attributes can be converted to human readable format. Information is presented via .e.g. Excel. Reports can be distributed via email or saved to file.
- Send Alerts. The PIP service can be notified that a specific event has occurred in the LDAP directory, the LDAP directory must support “Persistent Search” (Dirsync in Microsoft Active Directory). The PIP service reacts to incidents the moment the change occurs .e.g.
- Changes in high security groups
- Password changes on sensitive accounts
- Account lockout after a number of incorrect login attempts
- Provisioning/Synchronization. Automatic updates in multiple data repositories can be performed simultaneously.
Identity Provisioning Policy Concept
Architecture
A PIP policy are constructed from:
Where to collect information from
- LDAP directories.
- Databases through ODBC/JDBC connections.
- File import, LDIF or comma separated file.
- Web service interface.
When to do it
- Scheduled: a policy can be configured to run at a scheduled time or a configurable interval.
- Persistent Search: When a policy is configured to use an LDAP database supporting LDAP Persistent Search or DirSync (Microsoft AD) it will start a separate thread to listen to the LDAP directory, then the PIP service will be notified about events occurring in the LDAP directory.
- Manual: a manual policy can only be executed from the administrative interface or triggered by a PIP action depending on configurable prerequisites.
What to do with the data
The Identity Provisioning includes a large number of actions that can be used to build the logic that shall be applied to the parsed information. These actions are divided into three categories depending on their type (Input, Process, and Output). There is also an API providing customers with the opportunity to develop their own actions when standard actions are not suitable.
Type of actions:
- Input
Can complement a virtual image of an object with information from several data sources and create new attributes. - Process
Are used to change existing objects and associated attributes. - Output
Are used to write/save data from objects and associated attributes to one or more repositories (database, file, Web services, etc.).
Session Objects and Session Attributes
All data entering the Identity Provisioning via a web service interface, database and LDAP searches, text file imports or actions are converted to session objects.
Session objects can be created by performing searches directly or scheduled, from different sources and formats like LDAP directories, SQL databases or by parsing some text file (LDIF, CSV).
Session objects may be created automatically by the Identity Provisioning when a change has occurred in an LDAP directory service supporting Persistent Search (Dirsync in Microsoft Active Directory).
LDAP searches are performed according to RFC 2254 and PhenixID specific search filters and SQL searches via standard SQL commands and syntax.
A PIP session object may contain information such as the name of a database entry, event type, data source and changes affecting it.
A session object can have one or more session attributes. These attributes may also have a name, value, EventType and flags (e.g. if the attribute has been changed).
Session object with session attributes
Identity Provisioning Policy Components
A PIP policy is the concept holding together the business logic to gather and treat data, its components are:
- Data source connectors
- Rules to gather, modify and save data
- Actions to be performed
- Scheduler
Action types
A Identity Provisioning policy contains all the business logic to perform one or several actions. A policy is independent from all other policies. This is a vital functionality in an ITIL “change management” scenario.
Data Source
Data source objects contain configuration information how the service will connect to various systems. The data source objects are used by Policies and Actions.
Policies use data source objects to access systems in order to gather information and then to create session objects and session attributes.
Actions use data sources to read and write data following rules and flow defined in a policy.
Following are examples of supported data sources and file formats:
- LDAP V3 directory services, Microsoft AD and ADLDS, Novell eDirectory, Siemens DirX, OpenDS and more.
- JDBC (Java Database Connectivity)
- ODBC (Open Database Connectivity)
- CSV File (Files with fields separated by a character, e.g. a comma)
- LDIF File (LDAP Data Interchange Format)
- Web services (SOAP)
- Identity Provisioning to Remote Identity Provisioning. This web service can be used to synchronize information between two B2B parties or different organizations over HTTPS.
- Generic web service. This web service includes the following configurable requests:
- Create objects
- Modify objects
- Delete objects
- Search objects
- Web services (REST)
- Actions. Some actions can be used as input of information to PIP. Most common usage when getting information from cloud/service providers, such as Google, Salesforce.com and Office365.
Policy Scheduler
The scheduler is used to define when and how a policy shall be started.
There are three types of scheduler that can be configured.
- Manual
A manual policy can only be executed directly from the administrative interface. - Scheduled
A policy to be executed on a given point in date/time or at a given interval. - Persistent Search
A policy can be configured to take advantage of LDAP Persistent Search or DirSync (Microsoft Active Directory).
This type of policy starts a separate thread listening to the LDAP data source. These policies can be notified so that a specific event has occurred in the data source and will act upon it automatically. Session objects and attributes will be created and treated following the rules and flow defined in the policy.