10139N/AIn the usecase folder there are a set of files which together tell a user story based on some common examples.
10139N/AAfter building the openidm-zip project these files are copied and organized in an appropriate folder structure,
10139N/Aeach usecase folder contains the files that are needed for that certain use case sample.
10139N/AAll the samples assume a certain initial setup of managed users in OpenIDM.
10139N/AThe users are organized the following way:
10139N/A- there are 20 ordinary users: user.0 ... user.19 where
10139N/A - user.0 .. user.4 belong to Human Resources having user.0 as Manager,
10139N/A user.0 .. user.3 employees and user.4 contractor
10139N/A - user.5 .. user.9 belong to Production Planning having user.5 as Manager,
10139N/A user.5 .. user.8 employees and user.9 contractor
10139N/A - user.10 .. user.14 belong to Sales & Distribution having user.10 as Manager,
10139N/A user.10 .. user.13 employees and user.14 contractor
10139N/A - user.15 .. user.19 belong to Treasury & Payments having user.15 as Manager,
10139N/A user.15 .. user.18 employees and user.19 contractor
10139N/AFurthermore we have the following special users:
10139N/A- hradmin: user representing the human interaction of the HR department
10139N/A- systemadmin: user representing the human interaction of the populated systems (“Business” and “Project”)
10139N/A- superadmin: user representing the manager of the managers
10139N/AUsecase1 - Initial reconciliation
10139N/A In this step we import the users from OpenDJ to OpenIDM using reconciliation.
10139N/A To prepare to run the sample, download OpenDJ directory server from
10139N/A * Use "password" as the password for cn=Directory Manager.
10139N/A 1. Start OpenIDM with the configuration for usecase1.
10139N/A 3. Query the managed users created by reconciliation
10139N/A There should be 23 users created. The default password of the imported users is "Passw0rd".
10139N/A In this step we simulate an HR employee starting the onboarding process for an employee
10139N/A and approval step of the manager.
10139N/A If we want to use email notifications as part of the process make the following changes:
10139N/A - External email service of OpenIDM has to be configured using the following file:
10139N/A Update the smtp settings in this file before starting the workflow.
13931N/A - Change the notification email properties in the workflow definition file:
10139N/A emailParams = [_from : 'usecasetest@forgerock.com', _to : 'notification@example.com',
10139N/A _body : 'The requested user ' + userName + ' was successfully created']
10139N/A Change the _from and _to fields to contain valid email addresses.
13570N/A 1. Start OpenIDM with the configuration for usecase2.
14177N/A 2. Log in to the UI as user.1 (this user belongs to HR department, default password is 'Passw0rd')
17392N/A 3. Select the User Onboarding Process by clicking on it.
11965N/A 4. Fill the fields of the form presented by the UI. The fields marked with x are mandatory.
15942N/A By selecting one of the four departments we define which department the new user
15942N/A will belong to. Based on this the workflow will select the possible candidate assignees
15942N/A for the manager approval user task: it will be either superadmin (as manager of everyone)
10139N/A or the manager of the selected department (see description above).
10139N/A example: if HR is selected the manager candidates will be user.0 and superadmin.
10139N/A if the User Type field is Employee then the user will have access to an account called "Business".
10139N/A This is represented on the managed user in OpenIDM repository by having the following attribute on
15942N/A if the User Type is Contractor then the new user won't have any accounts associated to it in
15942N/A managed user representation in OpenIDM.
10139N/A - Send Email Notification field:
10139N/A If 'No' is selected for this field then no email notifications will be sent.
15288N/A Notifications will be added to the OpenIDM repository which will appear on UI.
10139N/A 5. Start the workflow by clicking on Start button.
10139N/A 6. Log out and log in as the manager of the department selected in the initial start form
10139N/A example: if HR was selected then log in as user.0
16309N/A 7. Click on the Onboarding approval task appearing on UI as task in the group queue
16309N/A and assign the user task to user.0 (select 'Assign it to me'). The task appears now in 'My tasks'.
16309N/A 8. Click on the Task and then on the 'Details' button.
16309N/A filling this field results in the user being created and adding the startDate property
16309N/A to the user. Furthermore, the user status will be 'inactive'.
10139N/A The field is optional, it will be used by TaskScanner to trigger sunrise workflow.
15942N/A filling this field results in the user being created and adding the startDate property
10139N/A The field is optional, it will be used by TaskScanner to trigger sunset workflow.
10139N/A Selecting yes will add 'title' field to the new managed user with the value 'manager'.
10139N/A Selecting 'Reject' terminates the workflow and sends a notification to the start user
10139N/A Complete the task by clicking on 'Complete' button.
10139N/A 9. If 'Accept' was selected then the user is created as a managed user in OpenIDM.
10139N/A The password of the new user is "Passw0rd".
10139N/A Two OpenIDM notifications are created about this event: one for the start user and one for the
15942N/A new user. Those are visible on the UI after login with the appropriate user.
15942N/A If email notification was selected then one email is sent to the user configured at the
10139N/A beginning of the use case sample.
10139N/A If the sunrise date of the new user was set then the user was created with inactive account status.
10139N/A To trigger sunrise activate the sunrise task scanner (it's inactive by default):
15942N/A The scan will run every minute and checks for users having sunrise date before
15942N/A Once the scan is triggered it picks the new user, starts the sunrise workflow on it:
10139N/A - changes the account status to active
11925N/A - adds an OpenIDM notification to the new user (visible when logging in to OpenIDM UI).
10139N/A If the sunset date of the new user was set then sunset workflow can be triggered
10139N/A To trigger sunset activate the sunset task scanner (it's inactive by default):
10139N/A The scan will run every minute and checks for users having sunset date before
10139N/A Once the scan is triggered it picks the new user, starts the sunset workflow on it:
10139N/A - a user task is assigned to the manager of the user (
e.g. in our sample the assignee is user.0)
10139N/A - Log in to OpenIDM UI with user.0 and select the task in 'My tasks'
10139N/A - Accept termination: the user's account status will be set to inactive and hradmin
10139N/A receives an OpenIDM notification about it.
15942N/A - Modify date: the sunset date of the user will be changed and the manager
15942N/A of the user receives an OpenIDM notification about it (user.0 in our sample).
10139N/A In this step we simulate a user starting an access request and having 2-level approval for it.
15999N/A If we want to use email notifications as part of the process make the following changes:
15942N/A - External email service of OpenIDM has to be configured using the following file:
15942N/A Update the smtp settings in this file before starting the workflow.
15942N/A - Change the notification email properties in the workflow definition file:
15942N/A emailParams = [_from : 'usecasetest@forgerock.com', _to : 'notification@example.com',
15942N/A _subject : 'Use Case Test Notification', _type : '
text/plain', _body : 'The access request was accepted']
10139N/A Change the _from and _to fields to contain valid email addresses.
15942N/A Note that there are 2 occurences of the emailParams, change both.
15942N/A 1. Start OpenIDM with the configuration for usecase3.
15942N/A 2. Log in to the UI as user.1 (this user belongs to HR department, default password is 'Passw0rd')
15942N/A 3. Select the Access Request Process by clicking on it and start the workflow.
10139N/A 4. A new task appears in 'My tasks', click on it and select 'Details'.
15942N/A - Access to Business system field: the value is reflecting the current value in OpenIDM database
16018N/A - Access to Project system field: the value is reflecting the current value in OpenIDM database
13092N/A - Send Email Notification field:
15942N/A If 'No' is selected for this field then no email notifications will be sent.
15942N/A Notifications will be added to the OpenIDM repository which will appear on UI.
15974N/A - Request field: Cancel terminates the process and does not change anything.
15982N/A Accept starts a user task assigned to the manager of the user (user.0 in this sample).
15989N/A Click on Complete after selecting the values.
18185N/A 5. Log out and log in as the manager of the start user (user.0 in this sample)
10139N/A 6. Click on the User Access Request Approval task appearing on UI as task in the group queue
10139N/A and assign the user task to user.0 (select 'Assign it to me'). The task appears now in 'My tasks'.
10139N/A 7. Click on the task and then on the 'Details' button.
10139N/A The two fields showing the required access rights are modifiable by the manager.
10139N/A Complete the task by clicking on 'Complete' button after selecting the Decision.
10139N/A - Reject: the start user (in our sample user.1) receives a notification about the denial. An OpenIDM
10139N/A notification is created about this event which is visible on the UI after log in with the appropriate user.
10139N/A If email notification was selected then one email will be sent to the user configured at the
10139N/A beginning of the use case sample.
10139N/A Accept starts a user task assigned to systemadmin.
10139N/A 8. If the manager accepted log out and log in as systemadmin (default password is "Passw0rd").
10139N/A 9. Click on the User Access Request Approval task appearing on UI in 'My tasks' and then on the 'Details' button.
10139N/A The two fields showing the required access rights are modifiable by the systemadmin.
10139N/A Complete the task by clicking on 'Complete' button after selecting the Decision.
10139N/A - Reject: the start user (in our sample user.1) receives a notification about the denial. An OpenIDM
10139N/A notification is created about this event which is visible on the UI after log in with the appropriate user.
10139N/A If email notification was selected then one email will be sent to the user configured at the
10139N/A beginning of the use case sample.
10139N/A - Accept: user.1 is updated in managed users table of OpenIDM reflecting the requested changes.
10139N/A An OpenIDM notification is created about this event which is visible on the UI after login with the appropriate user.
10139N/A If email notification was selected then one email will be sent to the user configured at the
10139N/A beginning of the use case sample.
10139N/A In this sample there is an escalation step attached to the manager approval task. If the manager does not complete
10139N/A the user task within 10 minutes then a new user task is created and assigned to superadmin. It has the same user interface
10139N/A as the one assigned to the manager of the user and has the same functionalities. If the superadmin
10139N/A completes this task then the execution is passed to the administrator approval (systemadmin).
10139N/AUsecase 4 - Orphan account detection and manual linking task started from reconciliation
10139N/A In this use case we show two different asynchronous tasks started from reconciliation:
10139N/A detecting orphan accounts on the target objects set and handling ambiguous results of correlation phase.
10139N/A 1. Before starting the test we need to rename the following file:
10139N/A In that file we have a mapping defined: recon_managedUser_systemBusiness.
10139N/A This mapping has managed users as source and a csv file as target object set. The target object set
10139N/A In that file we have all the users of the initial reconciliation (usecase1) which are employees
10139N/A and therefore have "Business" in the 'accounts' attribute (see usecase2 User Type).
10139N/A Since this mapping has a 'validSource' field defined only those managed users will be taken into
10139N/A There are some extra users in that csv file:
10139N/A - user.50 is defined only in the csv file so when running the reconciliation this user will be
10139N/A detected as an orphan account (orphan account workflow is triggered when the situation is
10139N/A "UNQUALIFIED" or "UNASSIGNED").
10139N/A - user.33: the 'userName' attribute of this user is 'user.3', same as for user.3.
10139N/A When running the correlation query during reconciliation there will be two candidate users
10139N/A to be linked with user.3 from managed users (correlation query is based on userName attribute).
10139N/A 2. Start OpenIDM with the configuration for usecase4.
10139N/A Two asynchronous workflows are started: an orphanAccountReport for user.50 and a
10139N/A manualMatch for user.3 of managed users.
10139N/A 4. Log in to the UI as systemadmin (default password is 'Passw0rd').
10139N/A 5. Click on the 'Details' button of the 'Manual Linking' task.
10139N/A The 'Possible targets' field is modifiable by systemadmin and it is required.
10139N/A - Ignore: no action will be taken (no link will be created) and the workflow terminates.
10139N/A - user.3 (user.3 - Atrc, Aaron) or user.3 (user.33 - Atrc, Aaron): these are the two candidate
10139N/A users found in the target object set by executing the correlation query. These values
10139N/A are queried in the workflow and the possible values of that field are determined
10139N/A runtime. Here we can choose the user we need.
10139N/A After choosing one of the users the workflow will link user.3 of managed user to the selected user
10139N/A 6. Click on the 'Details' button of the 'Orphan Account' task.
10139N/A 'Link to' and 'Decision' fields are modifiable by systemadmin.
10139N/A Complete the task by clicking on 'Complete' button after selecting the Decision.
10139N/A - Delete: the user will be deleted from the target object set and the workflow terminates.
10139N/A - Link: when choosing this option valid managed user id needs to be entered to link the orphan account to.
10139N/A Pick any user id from managed users where the managed user is not linked to any users in the csv file yet:
10139N/A if this use case is started after the initial reconciliation then pick
e.g. user.5.
10139N/A If users are created
e.g. by using sample2 that user can be used heres as well.
10139N/AUsecase5 - Certification workflow
10139N/A In this use case we have a scheduled task fetching all the managed users and starting a certification workflow
10139N/A 1. Start OpenIDM with the configuration for usecase5.
10139N/A 2. The scheduled task can be triggered by enabling the scheduled task in the
10139N/A 3. Log in to the UI as user.0 (default password is 'Passw0rd').
10139N/A 4. Click on the Certification process task appearing on UI as task in the group queue
10139N/A and assign the user task to user.0 (select 'Assign it to me'). The task appears now in 'My tasks'.
10139N/A 5. Click on the 'Details' button of the 'Access Status Check' task.
10139N/A - 'Access to Business system:' and 'Access to Project system:' fields can be modified.
10139N/A Those reflect the content of the 'accounts' field of the managed user being certified.
10139N/A 6. Complete the task by clicking on 'Complete' button after selecting the Decision.
10139N/A - Certify: no action will be taken, the certified user is not modified and the workflow terminates.
14177N/A - Change: a new user task is created and assigned to systemadmin user.
14177N/A 7. If 'Change' was selected in the previous step log in to the UI as systemadmin.
17597N/A 8. Click on the 'Details' button of the 'Access Status Check' task.
17597N/A - 'Access to Business system:' and 'Access to Project system:' fields can be modified.
17597N/A 9. Complete the task by clicking on 'Complete' button after selecting the Decision.
17597N/A - Accept: the user being certified is updated by the actual values of the access fields
17597N/A and a notification is sent to the user about the change
17597N/A (visible on the UI after log in with the appropriate user).
11965N/A - Reject: the user being certified will not be modified and a notification is sent to the manager
11965N/A about the certification change request being rejected by systemadmin.
11965N/AUsecase6 - Password change reminder
11965N/A In this use case we use TaskScanner to trigger a password change reminder workflow.
15995N/A Every managed user created in OpenIDM has a dedicated attribute to store the date of the last password change event (lastPasswordSet).
11965N/A sets the date of this attribute if a new password is stored for the user. The TaskScanner
11965N/A scans that attribute and starts a workflow if the password was changed more than an hour ago.
11965N/A - By default it sends the default OpenIDM notifications to the user (visible on the UI).
11965N/A - It can send email notification to the user if configured.
13678N/A External email service of OpenIDM has to be configured using the following file:
13678N/A Note that if you want to use this option you have to make sure that the 'mail' attribute of the
13678N/A managed user(s) used for this test case are valid email addresses.
10139N/A change "emailEnabled" : "false",
10139N/A The workflow does the following:
16539N/A - sends a notification to the user
10139N/A - five minutes later sends an other notification to the user (if password was not changed yet)
10139N/A - two minutes later changes the user's 'accountStatus' to 'inactive' and sends notification to the user (if password was not changed yet)