Virtual Systems [vs]

A virtual system is not directly connected for online management. The virtual system is basically only a registration mode, where for each system change is generated the implementation request (notification) that is assigned to the particular administrator. This administrator must provide that the change is made to the target system. In other words, IdM "knows" what the user should have on the system for accounts and permissions, but on the real system this is executed by the implementer (administrator). The reason may be the need to manage a large number of systems without the need for demanding integration.

• In the left menu, select 'Virtual systems / List' and click on Add.

You can fill:

• Name for the virtual system, e.g. 'NewVirtualSystem'
• 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 'Requests on virtual systems (VsRequest)' to receive these requests.

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 'Add' green button to create the new role.
• You have to only fill the name for your new role, e.g. 'RoleForNewVirtualSystem'.
• Click on 'Save and continue'.

• In the detail of our newly created role, select the tab 'Systems'
• Click on 'Add' green button.
• In 'System' field, select our virtual system, on picture it is 'NewVirtualSystem'.
• In 'Mapping' field, select 'Default provisioning (Identity - Provisioning)'.
• and click on 'Save'

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 'Users'
• Click on 'Create user' green button
• Fill Login, First name and Surname (e.g. 'john.doe', 'John', 'Doe').
• Click on 'create and edit'.
• On the user detail, click on the tab 'Roles'.
• Click on 'Manage Authorizations'.
• On the displayed dialog will be added the new role. Click on 'Add' green button.
• In the field 'Role name' select our role 'RoleForNewVirtualSystem'.
• Click on 'Set'.
• Click on 'Submit a request'.
  

Implementers received a new task to create the new account 'john.doe' on the virtual system 'NewVirtualSystem'. You can check the request. In the left main menu, select 'Virtual systems / Requests'. There are two tabs 'Unresolved requests' and 'Archive'. In 'Unresolved requests' there is a list of all tasks, which yet will be resolved.

If you did previous tutorial, you have here this request. You can go to the detail of the request with UID 'john.doe' and the system 'NewVirtualSystem' (click on the button with "magnifying glass"). And you can now see the detail of the request for creating new account.

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's roles (Implementers can be configured during the creation of the virtual system or in the detail of the virtual system).
• 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/next unresolved requests). For the 'create' request types, there are all rows marked as changed (orange color). Generally, this table shows the state in CzechIdM against the state on the virtual system, in this situation show "True" without merge with other unresolved requests.

If we do not resolve the create request and edit our user 'john.doe', e.g. change user's surname to Doe. A new update request is in 'Unresolved requests'. Click on the detail of the update request.

• Request detail displays the same information as in the previous 'create' case, just for the single attribute. Because previous 'create' request was not confirmed yet, is shows only one row. If the 'create' request is resolved, then it shows all attributes of the account with one changed attribute.
• 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 'create' request).

When we finally resolve our two requests, they are moved to the tab 'Archive'.

Implement request

• The operation 'Implemented' can be started in the table 'Unresolved requests' or in the request detail.
• 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 'Archive'

Cancel request

• Operation 'Cancel' can be started in the table 'Unresolved requests' or in the request detail.
• 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. check this, is it true?
• The request is moved to 'Archive'

• 'VsRequest' permission is required for displaying the request agenda.
• For displaying requests only for assigned implementers, you have to set evaluator 'VsRequestByImplementerEvaluator'. With this evaluator can user show and edit requests where is implementer (directly or from roles).

After the request for updating virtual system is created, the notification is sent to all implementers.

As default was implemented email notification 'vs:vsRequestCreated' for new virtual system requests. This notification is by default automatically connected to this topic. Template for this notification can be modified in left main menu 'Notifications / Templates'.

Email template provides similar information as the request detail (described above). For example, 'Target table' is constructed from same data as the table on the request detail. See below for examples of notification emails that are sent during the process described in its basic live cycle (creating and modifying the account 'john.doe') and notification, which displays the change of a multivalue attribute.

Email notification for create new account 'john.doe':

Email notification for modifying the account 'john.doe':

Email notification for modifying the multivalue attribute 'ldapGroups' for the account 'john.doe'.

New values 'E,F' were added to the attribute and the values 'C,B' were removed:

Before the system is deleted in ACC module, it's necessary to call VS module and ensure the deletion of connected entities (on the deleted system).

Sequence of executing operations in delete system processor in VS module:

1. Check existing unresolved VS requests - If an unresolved vs request exists, then it isn't possible to delete system (it throws an exception).
2. Delete all archived VS requests for the system.
3. Delete all VS accounts for connector key from the system.
4. Delete VS account form definition for the system.
5. Delete all VS system implementers for the system.