Testing, going live and production
Before taking a new HelloID implementation live, it is essential to thoroughly test the configuration to ensure it delivers the desired results. This blog will cover everything you need to know on the topic of testing, launching and moving your HelloID environment into production, including some key points and tips to consider.
We recently discussed testing business rules on a single individual, an effective method for safely testing new business rules without impacting other users. However, in some cases, you might need to conduct a broader test, particularly before going live and moving your HelloID implementation into production. This blog post will guide you on how to carry out such an extensive test.
In this article
A stateful provisioning engine
HelloID functions as a stateful provisioning engine, meaning it remembers its past actions. This is crucial as it allows you to track in detail the changes made by HelloID and the reasons behind them. HelloID takes a snapshot of your source system, compares it with the previous snapshot, and maps out all the differences (the so-called delta). The actions HelloID takes with these changes are determined by your business rules, which specify the exact actions the Identity & Access Management (IAM) solution should execute. HelloID always retrieves a snapshot using a pull method rather than push, ensuring it has all the necessary data to perform its functions.
The advantage of using a stateful system is significant. It enables you to predict the impact of your business rules through evaluations, which is only possible if you are aware of the previous state and have an earlier snapshot for comparison. This approach ensures you know exactly what HelloID will do beforehand, helping you avoid unexpected surprises. If anything goes awry, the stateful nature of the engine simplifies pinpointing the source of the problem. You can clearly see what actions HelloID took and where the issues occurred, allowing you to tweak the configuration and resolve any problems that arise.
Impact on testing and going live
Working with a stateful provisioning engine significantly affects how you test and launch your HelloID implementation. For instance, before going live, you need to bring all accounts ‘into state’, assigning the correct rights to all users from your HR system. Once HelloID is operational, the IAM solution works entirely on a mutation-based system. In practice, this means that the IAM solution performs actions based solely on the changes identified in snapshots.
Correlations play a crucial role in the assignment of accounts. If HelloID cannot match data correctly, it will create a new account in your target systems when granting an Active Directory (AD) account. Conversely, if data can be correlated, HelloID updates the existing account instead. This process highlights the importance of ensuring your connectors to and from your source and target systems are correctly set up. In the settings of these connectors, you define in detail which information HelloID can and cannot modify.
Updating the existing population
You have control over this process. When correlating, you decide whether HelloID should leave existing accounts in your target systems untouched, only creating new accounts according to the HelloID standard, or whether you also want to retrospectively update your existing population. The latter option can be particularly useful since many accounts are often created manually and may become outdated due to untracked changes in your source system over time. HelloID offers a solution by refreshing these accounts to reflect the most current data from your source system.
Cleaning up your existing population is possible during the process of bringing your accounts ‘into state’. You get to decide which fields HelloID is allowed to update and which it should not.
Which fields can HelloID update?
This process is consistent across all target systems, and for illustration purposes, we will take Active Directory (AD), a commonly used system, as our example. You can locate the treshold settings in the HelloID provisioning dashboard, under the ‘Target Systems’ section. Within this area, open your AD environment connector and proceed to the ‘Account’ tab. Here, select the ‘Configure’ option found under ‘Mapping‘. This mapping function is where you detail which fields should be updated during an update event.
The configuration here can be tailored to your preferences. For example, you might choose to have HelloID update only non-essential fields, which we recommend when initially importing your user population. To set this up, simply deactivate the ‘Update this field’ option for all essential fields, such as user principal name, common name, sAMAccountName and proxy addresses. On the other hand, if you are aiming for a clean-up of your AD environment right away, you keep all fields active, so that HelloID includes every field in the grant. Alternatively, if you are looking to establish a baseline, a starting point from which HelloID can make future changes, then you turn off all fields. This ensures HelloID imports data without making any changes.
Once HelloID has loaded all accounts for the first time, you can enable all fields again, allowing HelloID to update these fields in the future. For example, if a future snapshot from your source system shows that a user’s last name has changed, HelloID will automatically update this moving forward.
Thresholds provide additional assurance
Remember to scrutinize your thresholds critically. Thresholds act as safeguarding values that offer extra assurance when HelloID modifies data. They are akin to a robustness guarantee. By setting thresholds, you ensure that if changes exceed certain limits, HelloID is not allowed to carry them out automatically. In such cases, the IAM solution will block the change and present it to you first. You then have the option to manually approve or disapprove each modification. This allows you to retain full control, which is particularly reassuring during the launch of your HelloID implementation, as it allows you to maintain a clear oversight.
Setting thresholds is done in the configuration of the connector to your source systems, which are accessible via ‘Target Systems’ in the provisioning dashboard. From there, navigate to the ‘Thresholds’ tab. We advise you to set the ‘Count’ to ‘1’ in all cases during testing at ‘Revoke’, and to leave the percentage at 5. This ensures that HelloID may never revoke accounts or rights without your explicit permission.
You might also consider setting the ‘Count’ to ‘1’ at ‘Update’ as well. This means that in practice, HelloID is not allowed to update any account, and must present all updates it wishes to perform to you first. This is particularly pleasant during the initial launch of your HelloID implementation, as it allows you to maintain control over every update that HelloID carries out. Have you been working with HelloID for a while and are you confident that all settings are correctly configured? Then you can lower this threshold to ‘0’, following which HelloID will carry out these updates without your intervention.
Evaluation
Are you ready to test your HelloID implementation and configured business rules? Then you can perform an evaluation, which allows you to easily assess all business rules you have put in place. This involves what is known as a ‘read-only run’, during which HelloID identifies which actions it would carry out during an enforcement, based on the business rules. It is important to note that the IAM solution does not actually perform these actions. A ‘read-only run’ simply allows you to safely test whether all set business rules result in the desired actions.
You can find the result of this evaluation in the provisioning dashboard under ‘Business Rules’ and ‘Evaluations’. When assessing this evaluation, there are several key points to consider. For instance, HelloID shows a ‘create’ action for all accounts, even if an account already exists in HelloID. This is because the correlation of accounts only occurs when HelloID creates an account, a step that does not actually take place during an evaluation. Also, keep in mind that an evaluation includes a maximum of five hundred entries. If the number of actions that HelloID needs to carry out based on your business rules exceeds five hundred, then HelloID will not show all evaluations and the overview will be incomplete. This is particularly relevant when conducting an evaluation on your entire population. After putting everything into state, the number of changes usually does not exceed five hundred, and evaluations thus provide a complete picture.
Getting started
Would you like to start testing, launching and moving your HelloID environment into production? Please contact us!
Written by:
KaHo Man