Attention UMRA & IAM Customers!

Let’s take a quick look at the overall steps that HelloID is going to take during the provisioning sync process. So if we follow along with the flowchart here, our first step is going to be data collection from our Source Systems. Typically, this is going to be things like our ERP HR, or for the education side, student information systems. HelloID is going to pull that relevant information into an internal database within our HelloID tenant, and it’s going to store it on our common entity model that we call Persons.

From there, these Persons can be filtered down into specific Rules. These Business Rules will lead us to find out the types of entitlements that the related users should be granted in our target systems and where our target systems can be (Active Directory, Google, Azure, AD, etc.). Let’s go ahead and move over to look at the source systems that we have defined here inside of this particular instance.

HelloID does include some built-in connectors for source and target systems. But the vast majority of integrations are actually handled via a generic PowerShell connector template that HelloID makes available. This means that custom integrations can actually be created as needed, or existing integrations can be adjusted at a scripting level to better suit the organization’s needs.

Additionally, this allows HelloID to work with several different data synchronization mechanisms. In most cases, HelloID will communicate via things like flat files, APIs or ODBC queries. Tools4ever maintains a public GitHub for these HelloID connectors that have already been established; if you are interested in seeing some examples of these different methods or want to check out the existing connectors that we have already published.

Now while HelloID is a cloud-based service, local resources can still be incorporated into the configuration by leveraging the HelloID agent services. These are deployed out onto local Windows servers and will connect back to your HelloID tenant from your internal network and allow integration with systems that may be hosted on-premise.

Now that HelloID has data imported into his vault, we can view these Persons directly from the Admin console. This is helpful in providing visibility into the raw data that our account management will be based around.

Business rules let us define a filter condition based around attributes stored on our Persons, and then associate those to the different entitlement types that we can grant to them in our particular target systems.

We are going to use Active Employees here as a quick example. In this particular case, we’re looking at start and end dates for the person as well as a user type classification. Additional criteria can be added here, allowing for the rules to range from simple to very specific.

Any of the data points that we have on our persons is available for us to be used inside these conditions. So as our incoming data set grows, the possibilities for use within the conditions also grows.

With our filter setup, now we can start to tie together the list of entitlements that a user should be granted for falling into our particular rule. This is often going to be things like accounts inside Active Directory, Google, group memberships, or even specific permissions within our target systems themselves. Because the options available here are based highly on our target system integrations, this will vary largely based on the organization and the systems involved with our provisioning setup.

The Target Systems themselves are, at their core, similar to source systems. They define information about how we connect to a particular system. But on top of that, they’re also going to define information around how to take action around certain events. In the case of Active Directory, for example, they define how to create a new AD account and generate things like attribute values, user name, generation, and iteration control, OU management, and all of those different configurations. These are all going to be stored within our target system configuration as well.

Just like our Source Systems, Target Systems are also going to be built off of either the built in connectors, or make use of our generic PowerShell templates. If you are curious to see what that actually looks like, we do have the Tools4ever public GitHub for HelloID that allows you to dig into these templates a little bit further.

One of the critical functions needed when implementing identity management software regards logging and data or process visibility. All of the systems are integrated to help it actually capture audit logs automatically and use a configurable retention period as well. Additionally, audit information can be viewed per person giving a great view into the actions taken on a specific user across all systems or from a particular system.

One of the unique features of HelloID around source system imports is that it captures Delta differences with every snapshot import of those source systems. This means you can pull up a history for a given user and see all of the changes to that raw data that have happened to the user, making tracking down why an event occurred much easier.

Automating processes like account creation also need to have constraints and be forced to tell HelloID when processing should actually be halted. Similar to the audit logging, HelloID houses configurable thresholds that will automatically block actions if the pending number is greater than the associated threshold. So for example, if we were creating AD accounts, and we had more than the expected number, HelloID would stop that processing and actually do things like alert personnel so that action can be taken.

Email notifications, while being great for notifying when things like thresholds are hit, can also be used to send emails during different events during the normal processing flow. For example, we could be using these emails to generate welcome notifications to actual end-users, once their AD account has been fully created.

That will wrap up our quick overview of HelloID’s Provisioning module. We looked at:

• how system integrations work both from a source and target systems perspective,
• how HelloID can store the person data to be utilized in some business rules, and
• to link those users to the resources and entitlements they should be granted.
• auditing and logging features are available through the Provisioning module.

As you can see, HelloID offers a direct and straightforward approach to automating the user lifecycle. It is incredibly scalable and can be customized to fit almost any of your own specific user provisioning needs.