The One Identity Manager Configuration Guide gives you an overview of the One Identity Manager architecture and the basics of working with objects in One Identity Manager. It describes the structure of the One Identity Manager schema and explains how to customize and extend the One Identity Manager schema to specific requirements.
In addition, it details how to customize the user interface of the administration tools, especially Manager and Launchpad. The guide explains how to extend the user interface navigation, customize forms, create reports, or localize custom captions.
The basic rules for process orchestration are described in the One Identity Manager. It describes how to customize processes to your requirements and your own processes. An explanation of how to configure logging of data changes and information from process handling is also provided. Advanced configuration settings for the Job server One Identity Manager Service are described. Information is also provided on integrating web services, binding a SOAP Web Service and data exchange using SPML.
This guide is intended for end users, system administrators, consultants, analysts, and any other IT professionals using the product.
NOTE: This guide describes One Identity Manager functionality available to the default user. It is possible that not all the functions described here are available to you. This depends on your system configuration and permissions.
Available documentation
You can access One Identity Manager documentation in the Manager and in the Designer by selecting the Help > Search menu item. The online version of One Identity Manager documentation is available in the Support portal under Technical Documentation. You will find videos with additional information at www.YouTube.com/OneIdentity.
The basis for the One Identity Manager structure is classic 3-tier architecture. However, in One Identity Manager the object layer (business logic) is shared. This allows high performance gain due to separate time and location processing.
Database layer
The database represents the core of One Identity Manager. It fulfills the main tasks, which are managing data and calculating inheritance. Object properties can be inherited along the hierarchical structures, such as departments, cost centers, location, or business roles. For data management, the database maps managed target systems and ERP structures as well as compliance rules and access permissions.
The database is separated into two logical parts; payload and metadata. The payload contains all the information required to maintaining data, such as information about employees, user accounts, groups, memberships, operating data, approval workflows, attestation, recertification, and compliance rules.
The metadata contains the description of the application data model and scripts for formatting roles and templates or conditional interactions. One Identity Manager’s entire system configuration, all the front-end control settings, and the queues for asynchronous processing of data and processes are also part of the metadata.
Recalculation of inheritance is started by the database trigger logic. For this purpose, the triggers place processing tasks in a task list known as the DBQueue. The DBQueue Processor processes these tasks and recalculates inheritance of the respective database objects. A table labeled JobQueue is used to store processing orders that are to be run by the object layer.
A SQL Server or a managed instance in Azure SQL Database is used as the database system.
Object layer
The object layer enables object oriented access to the database data. The VI.DB.DLL generates entities for objects and collections. Entities use external session services for loading (EntitySource) and saving (UnitOfWork) data objects. Save operations are grouped so that several data objects can be saved in bulk. The default events Insert, Update, and Delete are available for each object and can be generated after objects are saved.
One or more processing logics are assigned to each entity (EntityLogic). These combine operations that can be run for a particular entity. Separate customizers were developed for the various entities. A customizer is an EntityLogic that deliver specific behavior for an entity. Customizers run processing logic which would normally be implemented in the object code, such as mutual exclusion of properties.
A value template can be assigned to each of the generated object’s properties. Templates are implemented for generating user data or for transforming values. You can use templates to fill object properties with default values or to form property values from other properties of the same or other objects.
One Identity Manager uses processes for mapping business processes. A process consists of process steps that represent processing tasks and are joined by predecessor/successor relations. This functionality allows flexibility when linking actions and sequences to object events. Processes are modeled using process templates. A process generator (Jobgenerator) is responsible for converting script templates in processes and process steps into a concrete process in the ’Job queue’.
The One Identity Manager Service enables the distribution throughout the network of information that is administrated in the One Identity Manager database. The One Identity Manager Service performs data synchronization between the database and any connected target systems and runs actions at the database and file levels. The One Identity Manager Service retrieves process steps from the Job queue. Process steps are run by process components. The One Identity Manager Service also creates an instance of the required process component and transfers the process step parameters. Decision logic monitors the performance of the process steps and determines how processing should continue depending on the results of the run process components. The One Identity Manager Service enables parallel processing of process steps because it can create several instances of process components.
The One Identity Manager Service is the only One Identity Manager component authorized to make changes in the target system.
Strictly speaking, the One Identity Manager Service is part of the object layer because it does not contain any business logic. The One Identity Manager Service provides help for realizing asynchronous processing.
Figure 1: One Identity Manager object layer
Presentation layer
The presentation layer comprises front-ends that are used to input and output data. There are different front-ends for different tasks. For example, a different front-end is used to configure One Identity Manager than that for managing employee data. The contents to be displayed and the extent to which it can be altered is determined in conjunction with the access permissions of the respective user through the object layer. Available front-end solutions are both client and browser-based.
Clients connect to an application server storing business logic. The application server provides a connection pool for accessing the database and ensures a secure connection to the database. Clients send their queries to the application server, which processes the objects, for example, by determining values using templates and sending the results back to the clients. The data from the application is sent to the database when an object is saved.
Clients can alternatively work without external application servers by retaining the object layer themselves and accessing the database layer directly. In this case, only the part of the object layer that is required for the acquisition process is mapped in the clients.
To implement browser-based user interfaces, there is an application running on a web server that is based on a website render engine. Users use a web browser to access the website that has been dynamically set up and customized for them. Data exchange between database and web server can take place either directly or through the application server.
Figure 2: Layer distribution with application server
Figure 3: Layer distribution without application server
Related topics
Object oriented access to tables and data sets is done through the One Identity Manager object layer.
Figure 4: Access to tables and data sets
The following applies to this:
Objects and collections are mapped using entities. Entities are those data units that can be called from the database and saved to the database. An entity corresponds to a row in a table in the database. It contains data columns and some metavalues such as display values and permissions.
Entities can contain either some or all columns in a table. In the first case, these are flagged by the IsPartial property and cannot be changed.
There are three types of entities:
-
Read-only
Data values can only be read. You cannot save the entities.
-
Delayed logic
You can change and store the entities. The delayed logic mode runs all business logic rules and methods when saving the entity. If the entity runs with an application server, it exists on the client side and does not use server resources.
-
Interactive
You can change and store the entities. The underlying logic is applied immediately after a value is changed. The entities' primary application is in user interfaces, where users want to see the business logic directly. For an entity to be able to run the logic without restriction with the user's permissions, it must exist on the application server if it is not run directly with a database.
The entities have the following default methods for performing the database operations.
Table 1: Default methods
|
EntitySource |
Creating new objects and collections or loading objects and collections |
|
UnitOfWork |
Grouping together save operations of multiple objects and collections |
|
discard |
Discarding of objects |
|
MarkForDeletion |
Marking objects to be deleted Not deleted until saved. |
When an object is loaded, all the columns are loaded. When a collection is loaded, not all the columns are loaded for performance reasons. The primary key columns are loaded and all columns that are in the display template and those where an object is marked for deletion. Defined display templates specify how each collection object is displayed in the front-end. Defaults for each table's display template are stored in the One Identity Manager schema and can be customized.
Objects recognize the following default events, which can be generated as a result of saving.
Table 2: Default events of the objects
|
Insert |
Insert an object. |
|
Update |
Change an object. |
|
Delete |
Delete an object. |
|
Assign |
Add M:N assignments. |
|
Remove |
Remove M:N assignments. |
Processes can be linked to these events that run actions in different target systems, for example, to add user accounts, add a home directory on a server, or write data to the One Identity Manager database.
Table 3: Lifecycle of an object
|
Insert an object. |
Object does not exist. |
Insert |
UID is created and the object is added to the database. |
|
Change properties. |
Object exists in the database and is loaded. |
Update |
Object properties are changed. |
|
Delete object. |
Object exists in the database and is loaded. |
Delete |
For objects that have the Marked for deletion (XMarkedForDeletion) property:
-
The MarkForDeletion method is run. Objects are locked and cannot be modified.
-
If deferred deletion > 0 days is configured, a deferred operation is created for deletion. The objects are initially disabled. During the retention period, you have the option to restore the objects. If a deleted object is restored, the object properties are reset to their state before deletion. The objects are finally deleted when the deferred deletion time period has expired.
-
Object with deferred deletion on 0 days are deleted immediately.
Objects that do not have the Marked for deletion property are immediately deleted. |
Related topics
All actions in One Identity Manager are run over the object layer and saved in the One Identity Manager database. Each change to an object (insert, change, delete) is run within a transaction. Another fixed item in a transaction of this type creates the processes itself. The transaction can only be successfully completed if the changes are saved and the processes have been successfully generated. If errors occur within the transaction, the entire transaction is rolled backed.
The following is an example of how to insert an object in One Identity Manager.
Run the following steps in the front-end:
-
Insert a new object.
-
Enter the object properties.
Dependent properties within this object are created with templates. Side effects implemented in the Customizer, such as mutual exclusion of certain properties, are applied.
-
Save the object.
After saving the object in the front-end, run the following steps in the object layer:
-
Start a transaction (Begin Transaction).
-
The following steps are processed in parallel:
-
Save the object in the database.
-
Apply the templates and formatting scripts to dependent objects.
-
Generate processing tasks for the One Identity Manager Service in the Job queue.
-
Generate processing tasks for the DBQueue Processor in the DBQueue.
-
Generate a record of changes in the history.
-
The transaction ends with success (Commit Transaction) or changes are rolled back if an error occurs (Rollback Transaction).
The following figure shows the flow of data when an object is inserted.
Figure 5: Dataflow inserting an object
