
User Notifications
User Notifications
For a admin-level explanation of notifications, click here.
As for the architecture, the (preliminary) structure is the following:
(TODO: update!!!!!!!!!!!!)

Currently there are three channels through which notifications are sent:
-
Resource operation listener. When provisioning module carries out an operation (either successfully or not), it invokes registered operation listeners. One of them is AcccountOperationListener, which
-
Model change hook. As model progresses through a change execution, it invokes registered change hooks. One of them is NotificationChangeHook, which acts upon an operation in its FINAL phase. After it detects a situation it is interested in, it creates a notification request and passes it to NotificationManager. (Was implemented, but currently not used.)
-
Activiti Java delegate. At specified points in workflow processes there may be needed to send user notifications. Activiti uses a concept of a Java delegate to invoke custom java functionality. NotificationJavaDelegate is such an interface to our notification framework. (It is not implemented yet.)
Planned features
Note: In the following table, there are the following roles mentioned:
-
REQUESTER, i.e. the one who requested an operation. He may be actually the real requester (e.g. user’s manager) or the user himself (in such case, REQUESTER = REQUESTEE), or IT administrator using midPoint. This depends on how midPoint is used.
-
RESOURCE\_ADMIN, i.e. an administrator of a resource; should be defined as Resource attribute.
-
IDM\_ADMIN should be defined in System Configuration.
-
ANY\_OTHER should be defined as a constant or an expression somewhere (maybe in workflow configuration or System Configuration?) - an example: security administrator.
Operation | Notification(s) |
---|---|
MidPoint user creation |
REQUESTEE: provide status.
If password was generated, provide the password.\* |
MidPoint user change (attributes, roles, accounts assigned, org units, …) |
REQUESTEE: provide status and information about changes.
|
Change on resource (add/remove account, add/remove group membership, attribute change, …) |
REQUESTEE: provide status and information about changes, e.g. new/removed privileges, new logins and/or passwords.
|
MidPoint user deletion. |
REQUESTER: provide status.
|
Reset password. |
REQUESTEE or REQUESTER: provide new password (see note \* in first row). |
Automatic Provisioning and identity lifecycle maintenance (e.g. LiveSync) |
IDM\_ADMIN: Provide status.
If the password was generated, provide password.
|
Approval |
Before: Send approval requests to APPROVER.
|
External links
-
Evolveum - Team of IAM professionals who developed midPoint