HelloID: Cloud Identity and Access Management in Your Hands

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.

Identity-as-a-service provides automated provisioning, self-service, sophisticated identity and access management (IAM), along with SSO, adaptive multifactor authentication (MFA), and enterprise security.

IDaaS solutions, such as HelloID, often include SSO. However, SSO alone does not support other IDaaS functionality.

SSO solutions streamline user authentication, requiring only one set of credentials to access IT systems, applications, services, and other IT resources.

When a user logs in, the SSO solution acts as an "Identity Provider" (IdP). After logging into the SSO portal, the user's identity is provided to the connected resources without requiring any additional logins. The user's identity is communicated via SSO protocols, such as SAML, OAuth, or OpenID Connect.

While this may sound complicated and pretty technical, the end user simply sees a dashboard of their accessible resources after logging into the SSO portal. HelloID offers multiple "plug-and-play" connectors for all types of systems, applications, services, and other IT resources.

For more information on individual connectors, including functionalities and SSO protocols, please refer to our continually expanding list:
https://www.tools4ever.com/connectors/

Gaining a basic understanding of attributes, business rules, entitlements, source systems, and targets will provide a solid framework for understanding HelloID, its operations, and why connectors are so valuable.

Attributes, Business Rules, & Entitlements
In order to drive identity management and provisioning automations throughout your IT environment, HelloID relies upon user attributes, business rules, and entitlements. Attributes include various pieces of identity data that make up a person within HelloID (e.g., name, title, department, manager).

A user's attributes determine the business rules that apply to them, such as all users receive an Active Directory account. The applicable business rules determine the entitlements users receive, such as accounts in various systems and permissions in the file system. By filtering combinations of attributes, your organization can build enhanced business rules and assign entitlements to meet your identity requirements.

Source & Target Systems
HelloID connects to the systems and applications within your environment to execute identity management automations and other processes. "Source systems" are those configured to provide HelloID with the user attributes needed to execute various tasks. HelloID detects and syncs all changes in the "source system," whether newly added users or updates to existing ones. For example, HR and SIS systems commonly serve as an organization's "source system."

All other systems and applications that HelloID connects to are "targets." HelloID executes identity management processes in target systems and applications, such as creating and provisioning accounts.

HelloID leverages connectors to create and set up new users' accounts, group memberships, and assigned permissions. For example, when new users are detected within the configured "source system," HelloID automatically syncs their data and attributes. The user is created as a "person" in HelloID.

HelloID automatically provisions each "person" accordingly based on your organization's configurations. Accounts are created, group memberships are added, and various permissions are assigned accordingly. With automated account creation, provisioning, and access management wrapped into one, new users hit the ground running on their first day.

HelloID's automated identity management processes reduce time-consuming manual efforts, reclaim significant IT staff bandwidth, ensure consistency, and track all actions for easily compiled audit logs.

By using group memberships, HelloID's Service Automation module facilitates complete self-service for users. Outside of automated role-based provisioning, self-service is used to provision specialty access cases and temporary projects.

HelloID configurations assign the "Product Owners" who approve or deny users' access requests for a given resource. Users who need to access a given resource may submit requests from the Service Automation tab located on their HelloID dashboard menu. When access requests are approved, HelloID automatically processes the group membership changes to provision the new access, which may include a revocation date.

Automatically Update Roles & Access
HelloID automatically detects user attribute updates in source systems in the same manner as detecting new users. When changes occur, HelloID will sync and process them accordingly to ensure that user data and access remain up-to-date. Throughout promotions, role changes, and any other events that occur during a user's account lifecycle, HelloID has you covered.

Provisioning New Resources for Existing Users
Organizations' applications and resources are always changing. As a result, IT departments need a dynamic and simple way to provide or remove employee access. HelloID Business Rules is the solution. Rules are simple to understand and have only two parts, members and entitlements. Based on HelloID filters, you can easily and automatically determine who should be in a Rule based on HR data. Entitlements such as groups are assigned to the Rule. By being a member of a Rule, you have the entitlement to access the resource.

As part of processing user account changes, HelloID swiftly deactivates and offboards departing employees once their status changes in the integrated source system. Typically, offboarding includes deactivating accounts, removing group memberships, and revoking access to connected systems and applications. This minimizes offboarding delays, orphan accounts, overlooked access rights, and unnecessary license expenditures.

No, HelloID has three modules, and each one can be independently licensed.

Provisioning Module
Automated Identity Management and User Lifecycle Management. The process of Creating, Reading, Updating, and Deleting/Disabling (CRUD) user accounts across multiple systems using automation.

Service Automation Module
Streamline the "Workflow Approval" process with secure web forms. Supervisors can now approve employee access requests and automatically implement them with HelloID, all with no helpdesk interaction.

Access Management Module
Single Sign-On (SSO) and MFA solution simplifying access to cloud applications by providing an application dashboard.

For added security, an organization may use Multi-Factor Authorization (MFA). While the first factor is the password itself, a second factor can be a secret question, which may include personal details such as your mother’s maiden name, favorite color, or pet’s name. They may also involve biometrics such as fingerprints, retinal scans, voice recognition, etc.

The advantage of MFA is that it helps prevent people from guessing your password. It also makes it harder for someone who steals your login credentials to access your account because they would need your username and password, along with your answer to the secret question or access to biometric data, etc.

MFA is particularly useful when you use different devices to log into your accounts, such as your laptop, tablet, smartphone, etc. That is why organizations often use MFA to grant access to sensitive data such as their files, personal information, and other types of confidential information.

MFA is becoming increasingly popular because it offers better protection against hackers than traditional login credentials like usernames and passwords. Some organizations use MFA in front of self-service forms that allow users to change passwords, phone numbers, email, etc., without contacting helpdesk support. As a result, this frees up the helpdesk personnel, thus increasing the organization’s efficiency.

A One-Time Password (OTP) is used to authenticate users accessing their accounts. Common OTP methods are email, text messages, authentication applications, or a physical token device. The purpose of OTPs is to provide an extra layer of security on top of the normal username and password. The main benefit of this authentication method is that the OTP expires after a certain period and can only be used once.

The most common use case for one-time passwords is two-factor authentication, which is used in addition to a user’s login credentials. For example, Google Authenticator generates codes that must be entered into a website in addition to a user’s username and password. This code is generated via an algorithm and changes in intervals, usually around 60 seconds. The benefit is that users do not need to remember the code since it is different every time they sign into the resource. OTP is used extensively in organizations to prevent unauthorized access to accounts. Its main advantage is that it provides additional security measures beyond just one form of identification alone. It is also useful when users change their passwords frequently due to forgetfulness. For example, if a user forgets their password, they can use the OTP feature to reset it without remembering the old one. In addition, OTPs are more secure than traditional passwords because they cannot be easily guessed.