Differences

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

--- eng_installation_package [2018/08/07 15:00]
romana [MS AD - synchronized data structure]
+++ eng_installation_package [2018/08/07 15:03] (current)
romana [Prerequisited and system requirements]
@@ Line 1: / Line 1: @@
+====== Installation packages CzechIdM ======
+===== Implemented processes =====
+ * Identity lifecycle management
+    * Identity synchronization + job contracts synchronization
+    * Standardise process of password delivery - sending an email to a user when creating an account in AD / LDAP / DB.
+    * Standardize processes identity lifecycle management: enable contract, end of the contract, contract exclusion, work position assignment, work position change.
+      * User attributes must be in order for using standard processes (synchronization from a data source or manually in CzechIdM)
+  * Organizational structure synchronization
+  * The approval process for requesting a change of assigned roles.
+    * Configuration of the standard approval process:
+      * Approval/Complement request by Helpdesk,
+      * User’s manager approval,
+      * User management approval,
+      * IT security approval.
+    * Define role criticality:
+      * 0 – not approving
+      * 1 – approval by role guarantor
+===== Priviliges definition in Identity Manager =====
+ * Super administrator - at least one user, who has the highest rights in the Identity Manager.
+ * Helpdesk – passwords management, access to audit information and sent notification.
+ * User –  can change a password, see profile in reading mode, can request for new roles (privileges) and access to managed systems.
+ * Manager – rights as a user + can see his subordinates and apply for permissions change for them
+===== Data source =====
+  * Supported data source:
+    * Database – connect to database using JDBC connector, for each type of object separate table or overview
+    * CSV files – for each processed object separated file
+  * Synchronization Support: if the data source does not contain for each record "timestamp", it is not possible to run only synchronization of changes, the entire data needs to be processed. Organizational structure synchronization does not allow process only changes and always process entire data.
+==== Synchronization data structures ====
+For identity manager implementation with installation package is necessary to disclose data source according to following structure. Disclosure may be in the form of a database table, view, or CSV file. Column names can be arbitrary.
+View or CSV structure corresponds to the following relationships Identity, Contracts, Department, Position shown below https://wiki.czechidm.com/_media/devel/adm/idm_entities.png
+=== Persons ===
+Persons table is a basic data source information for creating user identity in CzechIdM.
+^ attribute ^  unique  ^  compulsory  ^ note ^
+| id |  *  |  *  | usually presented by personal number, in time does not changing identifier ideally, which is not after contract expiration used again.|
+| login |  *  |    | minimum 2 characters, if it is not available, login is generated by identity manager|
+| first name |     |    |  |
+| last name |    |    |  |
+| title before name |     |     |  |
+| title after name |     |     |  |
+| email |     |     | standardly used for sending password |
+| mobile phone |    |    | in case of Identity Manager SMS gateway connection, password can be sent by SMS |
+| timestamp |    |    | timestamp changes, the so-called "Unix timestamp" ideally
+ |
+=== Relationship ===
+For case, that identity has more than one contract is possible to synchronize contracts from external source as it is done with identities. If relationships are not used at a company, there is no need this synchronization – identity manager “itself” create baseline where is linked all functionality.
+Contracts are presented as an employee contract for work, agreement to perform work, contract of services or as a contract with an extern supplier, intern at a department, participant at a project, students at the faculty and so on. Very important attribute is an owner of contract. If automated processes as an entering or ending employment contract should be run, validity of a contract must be filled.
+^ atributte ^  unique  ^  compulsory  ^ note ^
+| id |  *  |  *  | necessary for processing |
+| contract name |    |    | e.g. "Courier", optional |
+| owner |    |  *  | reference to personal id |
+| valid after |    |    | sql timestamp – Validity of contract  |
+| valid until |    |    | sql timestamp - Validity of contract |
+| exclusion from registration number |    |    | boolean flag decommissioning from registration number|
+| main contract |    |    | boolean flag of the main contract. If it is not stated, automatic calculation will do. |
+| superior |    |    | reference to the id of the person, can be used without the organizational structure |
+| organization |    |    | reference to the id in the organizational structure |
+| timestamp |    |    | timestamp change, "Unix timestamp" ideally|
+=== Organizational structure ===
+If required to synchronize organizational structures to identity manager, it needs to corresponding with the following data structure. To this synchronized organizational structure can be assigned identity contract. Identity manager support more than one organizational structure. In case of using this installation package only one is synchronized. If element of organizational structure from the source data is deleted. Structure in Identity Manager is deleted only when it is empty.
+^ atribut  ^  unique  ^  compulsory  ^ note                                                 ^
+| id       |  *         |  *        | unchanging key for processing                              |
+| name    |  *         |  *        | unique name of an organizational unit or position          |
+| superior element    |            |           | references to superior id element of the organizational structure  |
+All columns are varchar data type with limited 254 marks except timestamp, which is timestamp data type.
+==== CSV file format ====
+Data from CSV file must be in the following format:
+  * Text file with columns separated by separators-,;:|.
+  * One record for a line
+  * Each record has the same order of columns
+  * New line: LF, CRLF
+  * Header: 1st line - optional
+  * Coding: UTF-8
+  * Column/text can contain quotation marks " ("column1", "column 2", column 3)
+  * Quotation marks in text must be doubled ("column1", "column"" 2", column 3)
+  * New line in text is supported only in columns containing quotation marks.
+===== Data destination =====
+Supported data destinations:
+  * LDAPv3 - provisioning of identities and their roles
+  * MS AD - one domain, provisioning of identities and their roles
+  * Database - connecting to database with JDBC connector, one table for each identity (user).
+==== MS AD - synchronized data structure ====
+^ attribute  ^  compulsory  ^ note ^
+| DN |  *  | distinguished name |
+| sAMAccountName |    | User login |
+| cn |    | common name - frequently used as a RDN |
+| displayName |  | User name, frequently showed in applications, where AD is used. |
+| description| | |
+| password|  |  |
+| sn | | last name |
+| givenName| | first name |
+| mail |  | user email |
+| userPrincipalName| | login + domain |
+If not defined below in other way, all attributes mentioned above are transferred from the user identity without transformation.
+If password should be managed from IDM, customer must configure SSL connection to AD via port 636 (LDAP protocol).
+Significant attributes with transformation:
+  * DN is generated on the basis of the user's organizational structure inclusion or composition by not more than 2 attributes of a DN. If some part of DN is not in AD, then CzechIdM will create it.
+  * Cn is generated by composition of not more than 3 attributes. It is recommended to use it as a RDN.
+  * RDN (whether a cn is used or not) is recommended to use format which ensure uniqueness in within OU (in whole AD better). For example <name surname (ID)>. If uniqueness of RDN is not ensured within OU requirement for creating new user account during collision stays in provisioning queue and waiting for admin manual resolution.
+  * DisplayName is generated by not more than 3 identity attributes
+  * Password is filled with user password. Password cannot be mapped on other attribute.
+====== Prerequisited and system requirements ======
+  * [[faq:prerequisites_and_system_requirements|Prerequisited and system reqiurements]]
+  * For installing and configuration is needed to have access from a server to the internet for downloading needful software.
+===== Customer cooperation  =====
+Operation mentioned below are expected as a customer cooperation:
+  * Server preparation (hardware/virtual server).
+  * Installing an operating system, firewall configuration, etc.…
+  * Mail server setting – identity manager requires access to SMTP server
+  * SSL configuration to Active Directory (if password is managed)
+  * Remote access for technicians doing the implementation
+  * Prepare data source in the structure defined above, access to the network
+  * Participation in training and environment transmission
+~~NOTOC~~