IdStory Identity Manager - devel:documentation:adm

Architecture

Anonymous (anonymous@undisclosed.example.com) — 2019-03-04T14:00:54+00:00

Architecture frontend architecture The application is divided into 2 technological lines: backend (java) and frontend (javascript). There is a REST interface between the two. Minimum executable application The minimal executable application always contains the app + core modules.

Bulk actions

Anonymous (anonymous@undisclosed.example.com) — 2019-03-04T10:42:26+00:00

Bulk actions bulk action operation How they work There are 2 types of bulk action: * With items selected * Without items selected - action can be executed without items being selected on frontend - can be used on the whole agenda for importing / exporting features or simply for all data within the agenda.

Confidential storage

Anonymous (anonymous@undisclosed.example.com) — 2021-02-22T19:59:53+00:00

Confidential storage confidential security configuration To save sensitive data, a confidential storage solution has been created in the application. To read the data from this storage, one needs to know its owner (entity), and the key. The storage is currently used for: * saving the sensitive data in

Configuration - backend

Anonymous (anonymous@undisclosed.example.com) — 2025-12-18T09:39:37+00:00

Configuration - backend Read more here: Configuration - frontend configuration Frontend configuration is stored in czechidm-app module under czechidm-app/config folder and is separated by profile (by client) and stage (development / test / production) read more.

Cross domains

Anonymous (anonymous@undisclosed.example.com) — 2025-09-01T09:02:11+00:00

Cross domains ad provisioning system What are cross-domains? By cross-domains, we mean a set of external systems that are linked and share, for example, the same permissions. A typical example of a cross-domains group might be the linking of multiple domains in MS Active Directory

Delegation

Anonymous (anonymous@undisclosed.example.com) — 2020-10-06T15:30:10+00:00

Delegation delegation The aim of delegations is to transfer approval tasks to another solver. We divide delegations into automatic and manual. Automatic delegation In automatic delegations, a rule is first created according to which tasks are automatically delegated. A typical example is

IdM data export/import agenda

Anonymous (anonymous@undisclosed.example.com) — 2021-09-17T15:25:03+00:00

IdM data export/import agenda export import zip batch This agenda is used to transfer configuration data from one IdM to another. A typical use scenario is when you already have IdM configured on a test environment and now you need to migrate the tested configuration to a production environment.

Virtual system

Anonymous (anonymous@undisclosed.example.com) — 2019-03-01T13:58:54+00:00

Virtual system system virtual A virtual system is not directly connected for online management. A virtual system is basically only a registration mode, where for each system in which a change is generated an implementation request (notification) is assigned to a particular administrator. The administrator must make sure that the change is made to the target system. In other words, IdM "knows" what accounts and permissions the user should have on the system, but on the real system this is exec…

Modules overview

Anonymous (anonymous@undisclosed.example.com) — 2019-03-01T11:53:36+00:00

Modules overview There are several custom modules to be installed along with CzechIdM. Modules often have really similar structure consisting of: * Java source code * test suites * Groovy scripts - used primarily as transformations while connecting end-point systems

Notification system

Anonymous (anonymous@undisclosed.example.com) — 2019-03-01T07:40:21+00:00

Notification system * One message can be sent in more ways (e.g. according to the configuration of a user's account) or sent by a specific channel defined by notification type. * Messages are saved into the database - there is a notification agenda available for the application administrator

Modules - OpenAM: Admin guide

Anonymous (anonymous@undisclosed.example.com) — 2022-01-20T15:02:09+00:00

Modules - OpenAM: Admin guide When the module is enabled in the CzechIdM, users can authenticate to CzechIdM with their login and password valid for OpenAM. Or they may be authenticated by Single-Sign-On when they already have valid OpenAM session.

Provisioning context

Anonymous (anonymous@undisclosed.example.com) — 2021-01-13T17:29:29+00:00

Provisioning context provisioning context attribute mapping suggestions Provisioning context is used to optimize provisioning by allowing you to prepare data earlier than in individual attributes. The purpose is to avoid load the same data in multiple attributes. An example might be the need to compute a value of an attribute based on identity contracts. In such a case, it is possible to load this contracts through the relevant service as part of the transformation into the system. However, a…

Provisioning queue

Anonymous (anonymous@undisclosed.example.com) — 2019-04-23T05:30:27+00:00

Provisioning queue Provisioning queue shows all items that will be processed or items that will be processed. All items in queue can by started again (retry mechanism), canceled or deleted. More information about provisioning queue can be found in developers documentation.

Provisioning

Anonymous (anonymous@undisclosed.example.com) — 2020-08-28T11:17:14+00:00

Provisioning identity role provisioning Just like synchronization, provisioning can be done for the following entities: 1. Identities (IdmIdentityDto) 2. Roles (IdmRoleDto) 3. Role catalogue items (IdmRoleCatalogueDto) 4. Tree nodes (structures) (IdmTreeNodeDto) Provisioning of roles

Password policies

Anonymous (anonymous@undisclosed.example.com) — 2026-02-04T09:22:44+00:00

Password policies password security configuration Password validation and generation depends entirely on the CzechIdM system. In the CzechIdM system, two kinds of policy may exist: 1. for password validation, 2. and for password generation. Note that the password policies with the type

Reports module

Anonymous (anonymous@undisclosed.example.com) — 2020-03-10T13:41:54+00:00

Reports module report The reports module integrates the following three features: * long running tasks (LRT) – report generation can be cancelled (or killed) the same way as LRT. Report shares LRT's result state (RUNNING, CANCELLED etc.). * attachments

System

Anonymous (anonymous@undisclosed.example.com) — 2019-05-13T07:55:14+00:00

System system The CzechIdM system determines the behavior towards connected end systems. The system allows: * to define configuration and connection of an end system (via connector). * to create / generate a scheme of an end system. * to create mapping for

Tasks scheduler

Anonymous (anonymous@undisclosed.example.com) — 2019-02-27T14:39:27+00:00

Tasks scheduler scheduler The task can be scheduled in three different ways or using three types of triggers: * Settled time - this sets a launching time. If the time is set with a past date, the task is launched right away. * Cron - Quartz expression * Dependent task - the trigger here is when another task has successfully ended. Dependent tasks are executed by

Groovy scripts

Anonymous (anonymous@undisclosed.example.com) — 2019-02-27T11:36:37+00:00

Groovy scripts Scripts allow you to change the behavior of the application without restarting the server. Another reason to use scripts is authorization: they allow only some classes (services, managers, etc.) in scripts, see script authorization. Also, a script may call another script from within itself, by calling a special evaluator, see section scriptEvaluator.

Uniform password for new accounts

Anonymous (anonymous@undisclosed.example.com) — 2025-10-03T07:42:52+00:00

Uniform password for new accounts uniform password common account create (since IdM version 11.0.0) The main goal of a uniform password for new accounts is to ensure that new identities will have the same password in newly created accounts. This feature solves this scenario: * Let's have the