CzechIdM 10.5

The main goals of version 10.5.0 were to implement Password filter for AD, improve application initialization data and improve performance by implementing the provisioning context.

Password filter is a new feature which enables users to have their passwords propagated to IdM during standard password change procedure (eg. ctrl+alt+del) in MS Windows environment or via MS Active Directory management tools. It consists of two main parts. The first one is the password filter dynamic library used by MS Active Directory which is invoked any time a password change happens. Its task is to query IdM whether the new password meets all password policies or not and consequently notify IdM that the password is supposed to be propagated to all related systems. The second part is the implementation in IdM which supports all necessary features pertaining to the validation of password policies and following password propagation invoked by dynamic library.

Uniform password always enforces that password will be changed on all systems defined in uniform password system. The combination with password filter is uniform system powerful tool that allow one password trough all connected system in IdM. Uniform password also simplifies password change form for basic CzechIdM users.

You can find more about this feature here.

Application init data are created (updated), when application is started. Init data contains product provided roles, form definitions, value generators, password policies, codelist, scheduled task etc. to cover basic CzechIdM usage right after application is instaled or updated.

You can find more about this feature CzechIdM 10.5.

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 case it is possible to load this contracts through the relevant service as a part of the transformation into the system. However, a problem can arise if we need these same contracts in the other five attributes. At such moment, it would mean 4 unnecessary loadings of the same contracts.

The solution to this situation is to use provisionig context, which allows you to load contracts only once and distribute them to each attribute.

You can find more about this feature CzechIdM 10.5.

User with a special authority can login as different user. The feature is usable for checking application behavior under selected user (e.g. helpdesk). Logged user needs to have the permission SWITCHUSER to select the target user. Feature is available from user main menu in application.

You can find more about this feature CzechIdM 10.5.

• #2325 - REST endpoint and behavior for password filter
• #812 - Create init application data
• #2246 - Performance - add provisioning context
• #2439 - Authentication: Switch user
• #2449 - Groovy script security - allow a inherited classes
• #2405 - Add support for code completions to the ScriptArea
• #2386 - Transform old repository filter for system attribute mapping to authorizable service for support get predicates method and filters that can be overriden and added by service or new filter
• #2413 - Cache: add cache for token
• #1967 - Autorization policies - apply distinct configured policies
• #2248 - Synchronization: save extended attribute values together with entity
• #2429 - Cache: number of items in cache
• #911 - Force password change at next logon
• #2319 - Filter identities which are not in org. structure
• #2441 - Roles: support business roles for default role
• #2411 - Swagger documentation for Authentication has wrong example
• #2454 - Documentation for uniform password and password filter in IdM
• #2445 - Authentication: Switch user permission
• #794 - Automatically create a role for Virtual System implementers
• #2075 - Filtering for code list in select box
• #2384 - Manager is not allowed to edit identity right after it's created
• #2347 - Implement searching by LRT desciption when planning a LRT by other task
• #2436 - Role catalogue: add tab with roles in catalogue folder
• #2437 - Identity projection - add configuration property to disable loading all assigned roles into projection
• #2463 - Improve delegation of tasks from inactive identity

• 🟡 #2393 - One user action with the same user transactionId has two different logged users in audit ([SYSTEM] in audit field)
• 🟡 #2383 - After approving the task, a new notification is sent about the same task
• 🟡 #2284 - Contact data of a different user (virtual system send notification by UID)
• 🟡 #2424 - Synchronization creates a new identity with the default value in EAV instead of the mapped value
• 🟡 #2415 - Business roles has subroles with mapped system and merge attribute. When you delete for example 2 subroles, one of them still remain on the end system
• 🟡 #2025 - SMS sent do not show in general notification
• 🟡 #2457 - Projections: Filter button submits form
• 🟢 #1238 - When account creation is cancelled from the provisioning queue, then next account creation doesn't send password for the account
• 🟢 #2385 - Audit of role requests - cannot filter by date, approvers are not displayed
• 🟢 #2422 - IdmRoleTreeNodeFilter doesn't search by automatic role name
• 🟢 #2433 - Password change failed for accounts without system entity
• 🟢 #2409 - Missing entity type input on frontend permissions detail
• 🟢 #2435 - Tasks dependent on ProcessSkippedAutomaticRoleByTreeTaskExecutor are started twice
• 🟢 #2467 - FE: fix favicon path in build