Audit

CzechIdM contains complete audit information about administered entities such as Identities, Roles, Organizations, Contracts and selected operations, e.g. Synchronization and Provisioning. Audit informations are available in form of a “snapshot”, i.e. what the entity looked like at the time of a change. Thin imprint can be searched for in the audit and compared with any other imprint or with the current state of the entity.

Identity is such an important entity in CzechIdM that it was granted its own agenda in the GUI for working with audit information. This agenda is, compared to the normal audit for entities, distinctive mainly because it searches for identities by the entered login. To the filtered result there are also added entities related to the found identity:

• user’s roles
• user’s contracts
• user’s extended attributes

This audit contains all snapshots of all audited entities:

• Identity
• Role
• TreeNode (Organization Tree)
• Contract
• System
• IdM Configuration
• …

CzechIdM also audit all changes on relations between those entities, e.g. Identities and their Contracts. There is also an enhanced filter that is advised to use when searching for particular changes.

The audit for login contains information about users' successful and failed login attempts. Each audit record contains information about the following:

• Identity (only in global agenda),
• result from login (failed/success),
• login date,
• number of unsuccessful attempts,
• required password change,
• valid password from,
• valid password to,
• password blocked to.

Audit contains information about password changes. The audit is not composed by classic audit records but from password history records. Same history records are used for check history password.

Audit contains information about added, removed and changed roles that is assigned to user. This audit agenda doesn't show role parameters.

Writing data from CzechIdM to managed system is realized via a provisioning queue. For example, if an Identity’s attribute has changed and, at the same time, the identity owns an account for a connected system (e.g. LDAP), then it is called for a writing of the operation UPDATE into the provisioning queue. The same principle applies to all objects supporting provisioning:

• Identity
• Role
• Organization (TreeNode)
• Role catalogue

All operations to connected systems are audited in provisioning history

Workflows in CzechIdM represent a process – e.g. New Identity, Start of maternity leave… These are basically an executable part of the application which realize these processes. From the perspective of architecture, it is, in fact, a finite-state machine. In each state it do some action e.g. it sends an an email to the manager when a new identity has been created or it creates a task for the IT department when an employee has left to remove all his accounts.

Every workflow run is audited. Moreover currently running workflows can be displayed. Thus administrators and users can e.g. see, who is on turn in solving some tasks they wait for.

• Audit - what state is my workflow in?

(to be deleted)

• Auditing
• Logging