You are viewing the documentation for an outdated or unreleased 9.5 version.
This page is also available in versions: 7.6, 7.7, 7.8, 8.0, 8.1, 9.0, 9.1, 9.2, 9.3, 9.4, 9.5, 9.7 (current), devel

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

— 9.5:documentation:audit [2019/02/28 07:44] (current)
Line 1: Line 1:
 +<- .:​user_tasks | User tasks ^ .:start | Documentation ^ .:​password_policies | Password policies ->
  
 +====== 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.
 +
 +===== Identities audit =====
 +
 +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**
 +
 +===== Audit for entities =====
 +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.
 +
 +===== Login audit =====
 +
 +The audit for login contains information about user successful and failed logins. Each audit record contains information about:
 +  * 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.
 +
 +<note tip>When user (not admin, or user with permission change password to another users) change password itself, is during this change logout and login. This information is now available in audit of password change and in login audit.</​note>​
 +
 +{{ :​devel:​documentation:​loginaudit.png |}}
 +
 +===== Password change audit =====
 +
 +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.
 +
 +<note important>​This audit store data only about password changes done against CzechIdM. When user change password only against end system (eq AD, LDAP, ...) the audit for password change will be empty</​note>​
 +
 +{{ :​devel:​documentation:​passwordchangeaudit.png |}}
 +
 +===== Add or removed roles audit =====
 +
 +Audit contains information about added, removed and changed roles that is assigned to user. This audit agenda doesn'​t show role parameters.
 +
 +{{ :​devel:​documentation:​identityroleaudit.png |}}
 +
 +===== Provisioning audit =====
 +
 +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
 +
 +===== Audit of workflow runs =====
 +
 +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.
 +
 + 
 +===== Admin tutorials =====
 +  * [[tutorial:​adm:​audit_workflow| Audit - what state is my workflow in?]]
 +
 +===== Admin guide =====
 +(to be deleted)
 +
 +===== Devel guide =====
 +  * [[.audit:​dev:​audit|]]
 +  * [[.audit:​dev:​logging|]]