Differences
This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
tutorial:adm:modules_vs [2017/11/07 20:17] poulm moved from admin guide |
tutorial:adm:modules_vs [2017/11/07 20:27] (current) poulm |
||
---|---|---|---|
Line 1: | Line 1: | ||
+ | ====== Modules - vs: VS account lifecycle and module configuration ====== | ||
+ | ===== Basic life cycle of virtual system accounts ===== | ||
+ | |||
+ | We have a **john.doe** identity and a role **RoleVS** linked to a virtual system **VS**. | ||
+ | - We assign the role ' | ||
+ | - The virtual system ' | ||
+ | - The identity ' | ||
+ | - We'll make a change on our account when we edit the last name of the identity from **Doe** to **Roe**. | ||
+ | - Saving the identity will trigger provisioning for the connected systems. | ||
+ | - Because the account ' | ||
+ | - The virtual system creates a second record in the VS request agenda and sends notifications to all implementers. | ||
+ | - Implementers have now two notifications and two corresponding requests in IdM. The first is for creating and the second for changing the same account. In the second notification, | ||
+ | - **The implementer makes a manual change on the target system - creates the account and changes its last name.** | ||
+ | - The implementer confirms in the Requests agenda in IdM that the account was created. | ||
+ | - By confirming the request, the creation of the account ' | ||
+ | - The implementer confirms Requests agenda in IdM that the last name of the account was changed. | ||
+ | - By confirming the request, the change (**Doe** -> **Roe**) is written into the VS data structure. | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ===== How to create a virtual system ===== | ||
+ | |||
+ | * In the left menu, select ' | ||
+ | {{ : | ||
+ | |||
+ | ==== It displays a dialog to create a new virtual system. ==== | ||
+ | You can fill: | ||
+ | * Name for the virtual system, e.g. ' | ||
+ | * Implementers - users, who will receive the requests for updating the real system | ||
+ | * Roles of implementers - users who have assigned these roles will be receiving requests for updating the real system | ||
+ | Beware: Users/roles have to have permission ' | ||
+ | {{ : | ||
+ | |||
+ | |||
+ | <note important> | ||
+ | |||
+ | |||
+ | === In the detail of the new virtual system, the system schema, mapping and attributes are configured by default === | ||
+ | {{ : | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | ===== Create a new role ===== | ||
+ | We have created the new virtual system. Now we will assign the system to some users. For this we create a new role and create the mapping for our new virtual system. | ||
+ | * In the left menu, select Roles. Click on ' | ||
+ | * You have to only fill the name for your new role, e.g. ' | ||
+ | * Click on 'Save and continue' | ||
+ | {{ : | ||
+ | |||
+ | ===== Create the mapping on the virtual system ===== | ||
+ | * In the detail of our newly created role, select the tab ' | ||
+ | * Click on ' | ||
+ | * In ' | ||
+ | * In ' | ||
+ | * and click on ' | ||
+ | {{ : | ||
+ | |||
+ | ===== Create a new user ===== | ||
+ | We will create a new user and assign him our role, so he will be provisioned to our new virtual system. | ||
+ | * In left menu, select ' | ||
+ | * Click on ' | ||
+ | * Fill Login, First name and Surname (e.g. ' | ||
+ | * Click on ' | ||
+ | * On the user detail, click on the tab ' | ||
+ | * Click on ' | ||
+ | * On the displayed dialog will be added the new role. Click on ' | ||
+ | * In the field 'Role name' select our role ' | ||
+ | * Click on ' | ||
+ | * Click on ' | ||
+ | |||
+ | ===== Requests ===== | ||
+ | |||
+ | The Requests agenda of the Virtual Systems (' | ||
+ | |||
+ | The Requests agenda is divided into two tabs: | ||
+ | * Unresolved requests of the logged user. This list contains all virtual system requests that haven' | ||
+ | * The Archive. This list contains all resolved, duplicated or canceled requests. | ||
+ | |||
+ | In our example, the implementers received a new task to create a new account ' | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | You can go to the detail of the request with UID ' | ||
+ | |||
+ | There are three specific groups of information: | ||
+ | * **Basic information** for the request (state, UID, system, type, created ). | ||
+ | * **Implementers** - All implementers who can resolve the request. The list includes all directly selected implementers and all users with assigned implementer' | ||
+ | * **Target state on system** - The table displays how the account should be set on the target system. There are only changes from the request (not from previous/ | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | If we do not resolve the create request and edit our user ' | ||
+ | * Request detail displays the same information as in the previous ' | ||
+ | * Request detail can display previous and next unresolved request (for the same account). For this case it shows the table with one previous request (our known ' | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | When we finally resolve our two requests, they are moved to the tab ' | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | ==== Operations with the request ==== | ||
+ | |||
+ | === Implement request === | ||
+ | The Implement operation marks the request as ' | ||
+ | * The operation ' | ||
+ | * After this operation is executed, all changes from this request are propagated to the data structure of the virtual system. | ||
+ | * The request is moved to ' | ||
+ | |||
+ | <note tip>When a ' | ||
+ | |||
+ | === Cancel request === | ||
+ | The Cancel operation marks the request as ' | ||
+ | * Operation ' | ||
+ | * It is required to fill the reason for this operation. The reason is displayed in the archived request detail. | ||
+ | * After this operation is executed, all changes from this request are discarded. | ||
+ | * All unresolved requests made after this canceled request on the same account are canceled as well. FIXME check this, is it true? | ||
+ | * The request is moved to ' | ||
+ | |||
+ | |||
+ | |||
+ | ===== Permissions ===== | ||
+ | * ' | ||
+ | * For displaying requests only for assigned implementers, | ||
+ | |||
+ | |||
+ | ===== Notifications ===== | ||
+ | After the request for updating virtual system is created, the notification is sent to all implementers. | ||
+ | |||
+ | As default was implemented email notification ' | ||
+ | |||
+ | Email template provides similar information as the request detail (described above). For example, ' | ||
+ | |||
+ | Email notification for creating a new account ' | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | Email notification for modifying the account ' | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | Email notification for modifying the multivalued attribute ' | ||
+ | |||
+ | New values ' | ||
+ | {{ : | ||
+ | |||
+ | ===== Virtual systems configuration ===== | ||
+ | |||
+ | |||
+ | {{ selection_074.png |}} | ||
+ | |||
+ | | ||
+ | * **Required confirmation** (boolean) - If not checked, then all requests for this virtual system will be resolved immediately (this will be visible on archived requests). No notification will be sent to implementers. The confirmation is required by default. | ||
+ | * **Attributes** (List of String) - Properties for create EAV model. This list defines the " | ||
+ | * **Implementers** (List of UUID) - Users, who will receive the requests for updating the real system. Every implementer must be an identity in CzechIdM. Values are identifiers of identities. | ||
+ | * **Roles of implementers** (List of UUID) - Users who have assigned these roles will be receiving requests for updating the real system. Every role must be a role in CzechIdM. Values are identifiers of roles. | ||
+ | * **Supports account disable/ | ||
+ | |||
+ | ==== Default implementers ==== | ||
+ | |||
+ | If the implementers of the virtual system are not directly configured, the default implemeter' | ||
+ | |||
+ | <code properties> | ||
+ | idm.sec.vs.role.default=< | ||
+ | </ | ||
+ | |||
+ | The default value of the default implementer' |