Virtual system system virtual

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.

We have a john.doe identity and role (RoleVS) linked to a virtual system (VS).

1. We assign role 'RoleVS' to identity john.doe, it will trigger provisioning for the connected systems.
2. VS creates request for create new account 'johne.doe' and send notification on implementers.
3. Identity johne.doe now has account on VS, but this account is not confirmed by implementer.
4. We'll make a change on our account when we edit the last name from Doe → Roe.
5. Save will trigger provisioning for the connected systems.
6. Because the john.doe account on the VS already exists (although only in unconfirmed request form), provisioning evaluates it is need to edit the lastName attribute to a new Roe value.
7. The virtual system creates a second record in the VS request agenda.
8. Notifications will be sent to users who are in the VS settings as implementers.
9. Implementer has now two notifications. One for create and second for change same account. In second notification is information about unresolved previous request.
10. The implementer makes a manual change on the target system (create account and change of last name).
11. The implementer confirms that he made the create in the VS requirements agenda.
12. By confirming the request, the create of account john.doe is written into the VS data structure (new item in VsAccount).
13. The implementer confirms that he made the change in the VS requirements agenda.
14. By confirming the request, the change (Doe → Roe) is written into the VS data structure.

Agenda with list of VS request has two tab. On first is unresolved requests for logged user. On second tab is archive with resolved, duplicated and canceled requests.

• Unresolved task can be marks as realize directly from list. You can use green button on end of row.
• Unresolved task can be canceled from list too. You can use red button on of row or use batch operation for this table (check some row and select operation 'Cancel' form select box).

Request detail show:

• Basic information for the request (state, UID, system, type, created ).
• Implementers - All implementers whose can reslove the request. In implementers are all directly select on VS configuration and all with assigned roles (setted in VS configuration).
• Target state on system - Table show how should looks account on target system. In the table are show only changes from the request (not from previous/next unresolved requests). For 'create' request type are all rows marked as changed (orange color). Generaly shows this table state against state on virtual system, in this situation show "True" without merge with others unresolved requests.

• Request detail shows same information as in previous 'create' case, but for update single attribute. Because previous 'create' request was not realized yet, is shows only one row. If 'create' request is resolved, then shows all attributes of the account with one changed attribute.
• Request detail can show previous and next unresolved request (for same account). For this case is shows table with one previous request (or know 'create' request).

Relize operation marks request as 'Relized'.

• After this is all changes from this request propagate to the VS data structure (VsAccount and EAV).
• Operation can be starts from table unresloved task or from request detail.
• After this operation is request shows in requests archive.

Cancel operation marks request as 'Canceled'.

• For this operation is requered fill the reason. Reason is show on archived request detail.
• If is request canceled the connector returns account without any changes from canceled request.
• Operation can be starts from table unresloved task or from request detail.
• After this operation is request shows in requests archive.

• For show request agenda is required VsRrequest permission.
• For show 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 new VS request is created is send notification to all implementers.

Notifications are send on topic:

VirtualSystemModuleDescriptor.TOPIC_VS_REQUEST_CREATED=vs:vsRequestCreated

You can create your own template (email, sms, console), this template only have to listen on correct topic.

As default was implemented email notification 'vs:vsRequestCreated' for new VS request. This notification by default automaticaly connected to this topic. Template for this notification is saved in VS module as XML:

Realization/backend/vs/src/main/resources/eu/bcvsolutions/idm/templates/VsRequestCreated.xml

Email template provides similar informations as request detail (described above). For example 'Target table' is constructed from same data as table on request detail.

Below is examples of notification emails send during process decribed in basic live cycle (create and modify account 'john.doe') and notification show change multivalue attribute.

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

Email notification for modify account 'john.doe':

Email notification for modify multivalue attribute 'ldapGroups' for account 'john.doe'.

To the attribute was added new values 'E,F' and removed values 'C,B':

BasicVirtualConfiguration contains this attributes:

• Required confirmation (boolean) - If is not checked, then all requests will be solved immediately (this is visible on archived requests). None notification will be sent to implementers. By default is checked.
• Attributes (List of String) - Properties for create EAV model. Define "columns" for virtual system. VsAccount contains only UID and Enable static columns. Others columns are defined in EAV model. By default are set basic attributes from Identity (firstName, lastName, email, titleAfter, titleBefore, phone).
• Implementers (List of UUID) - For this implementers will be created realization task. Every implementer must be dentity in CzechIdM. Values are identifiers of identities.
• Roles of implementers (List of UUID) - All identity with this roles will be implementers. Every role must be role in CzechIdM. Values are identifiesr of roles.
• Supports account disable/enable (boolean) - If is checked, then account disable is supported. It means, in schema will be generated attribute '_ _ ENABLE _ _'.

As you can see, VS configurations allows define implementers via assigned IdM role or directly by selected identities. If you do not define none directly implementers and none role in VS configuration, then will be used implementers from default role. Default role can be defined in configuration:

idm.sec.vs.role.default=<some-code-of-role>

• VsAccount - Keeps all realized accounts in VS. Contains only basic informations (UID, System ID, Enable). Must be equals to state of accounts on target system → shows "True".
• VsAccountFormValue - Contains dynamic values for VS account.
• VsRequest - Keeps all requests for VS. Shows not realized wish on target system.
• VsSystemImplementer - Contains implementers for VS. Implementers can be defined directly or via role.

For virtual system was created new connector virtual-system-basic (BasicVirtualConnector.class). This connector provides an interface for external communication with the virtual system.

Connector supported from 'czechidm' connector framework this operations:

• IcCanRead,
• IcCanCreate,
• IcCanUpdate,
• IcCanDelete,
• IcCanGenSchema,
• IcCanSearch (Search in VS supported only reconciliation, it means search return all accounts. None connector filter can be now used.)

Configurations for connector is represented by POJO class BasicVirtualConfiguration. This class contains attributes annotated with '@IcConfigurationClassProperty'. Annotation adds metadata as 'dispalyName', 'face', 'order', 'helpMessage', 'required'. Values from this configuration plus metadatas creates final configuration for virtual system and are showing on system configuration tab as you can se in chapter Virtual system configuration.

User name on identity is by default mapped as UID in VsAccount. Special situation happens, when is username (UID) changed id IdM. When is changed UID attribute on others connector (Ldap, Table, …) is returned new UID as result from connector update method. But virtual connectors works asynchronous, it means none result is returned and SysSystemEntity.UID is not updated.

This state is resolved in virtual connector:

Before is system delete in ACC moduel, is necessery call VS module and ensure delete connected entities (on the deleting system). For this is used 'SystemEventType.DELETE' event and processor 'system-delete-processor'.

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

1. Check on exists unresolved VS requests - If exists unresolved vs request, then is not possible to delete system (throws exception).
2. Delets all archived VS request for the system.
3. Delets all VS accounts for connector key from the system.
4. Delets VS account form definition for the system.
5. Delets all VS system implementers for the system.