How a User Provisioning Solution Helps Your Organisation
In our earlier blog post, “Why Do You Need an IAM Solution?”, we explored the various challenges organisations face without Identity & Access Management (IAM).. We organized these challenges into three main categories: improving efficiency and reducing costs, compliance with legal and regulatory standards, and safeguarding against data breaches. In today’s blog, we’re revisiting these key areas but we will discuss them in the context of how an IAM system can effectively address and mitigate these concerns. We’ll kick things off by diving into the User Provisioning aspect. If you’re interested in understanding how a cloud-based User Provisioning solution could benefit your organisation, continue reading!
In this article
How does an IAM solution help?
In the previous post, we highlighted three key reasons for developing an IAM strategy and rolling out an IAM solution. We elaborated on challenges within each of these categories that could emerge when managing users, authorization, and access manually. For example, under the category of ‘Efficiency and Cost Reduction,’ challenges like managing manual changes, poor user experience and productivity, a surge in helpdesk tickets, and elevated software licensing fees can occur. In terms of ‘Compliance with Legal and Regulatory Standards,’ issues may arise such as accumulating redundant rights and conflicting permissions, along with the risky practice of using ‘copy user’ settings instead of adhering to the ‘least privilege’ principle. For the ‘Protection Against Data Breaches’ category, we pointed out human errors as a significant vulnerability.
As touched upon in the previous article, Identity & Access Management encompasses a range of technologies that deal with the management of users, authorization and access. In the continuation of this blog, we’ll explore these IAM technologies in greater depth. For clarity, we’ll organize our discussion into three main sections: ‘User Provisioning,’ ‘Service Automation,’ and ‘Access Management,’ which conveniently correspond to the modules that we use in our cloud-based IAM solution, HelloID.
User Provisioning
User Provisioning focuses on automating the various phases of an identity’s life cycle. Through established business rules and a role-based model, it links source and destination systems, allowing for nearly 80% of manual tasks related to user and authorization management to be completely automated. The life cycle of a user typically includes stages like onboarding, transitioning within the organisation and offboarding. The process can also accommodate re-entry. Automating these stages through IAM capabilities addresses a significant number of challenges related to errors, financial costs and timeliness.
Links
An Identity & Access Management solution automates the management of user identities and authorizations by linking source and target systems, eliminating the need for human intervention. Generally, there are limited options for source systems that are compatible. As for target systems, it’s wise to prioritize those applications that are used by many users and require frequent changes.
To realize the anticipated advantages in efficiency and cost reduction, the expenses associated with establishing these connections should be balanced against the time savings achieved. Generally, linking an application used by a small number of individuals isn’t cost-effective. The exception to this rule is when the application contains very sensitive data. In this case, you’d want to eliminate manual errors, making a connection worthwhile. However, even then, it might be considered to include this not within provisioning but within the service automation process.
Source system
The foundation for an automated user management process starts with a central core registration system that serves as the source system for other systems and applications. We also call this the single source of truth. In most organisations, the HR system is a good single source of truth. The organisation has an interest in keeping the HR system well-maintained. Salaries are also paid based on this data. If someone is not in the HR system, they won’t receive a salary. If someone still is in the HR system after leaving the organisation, that former employee would continue to receive a salary. In both cases, there’s sufficient motivation to invest time and energy in accurate registration.
In addition to the data integrity that this brings, the HR system also contains much relevant information needed for proper and accurate user and authorization management. This includes first and last names, as well as preferred names, which are needed to generate a username and email address. Even more interesting are contract details. Based on the start and end dates, you know when to create a user account and when to deactivate it. The individual’s role and department inform you about the activities and thus the rights they need. These details also often come in handy for a visual directory or contact list. Lastly, the individual’s manager is often registered in the HR system, which is very relevant for service automation, a topic we will explore in the next blog.
Multiple source systems
Don’t be misled by the term “single” in “single source of truth,” as there are indeed situations where you might want to employ multiple source systems simultaneously. For example, a healthcare organisation may use both an HR system and scheduling software as source systems. The latter could record which healthcare workers are treating which clients and when. Or, an educational institution might keep track of students in a Student Information System. Important to note: Identity & Access Management isn’t restricted to just employees; it encompasses all users who need access to your IT environment.
Target systems
The source system provides crucial information about your users and their roles within the organisation, but that’s just part of the equation. On the other end, you have multiple target systems where these users need an account or specific permissions. The list of such target systems can be diverse, ranging from (Azure) Active Directory and Google Workspace to NTFS file systems or SharePoint in the cloud. Furthermore, they can include specialized software like Customer Relationship Management (CRM), Electronic Patient Records (EPR) or Learning Management Systems (LMS).
Interestingly, a target system could also double as a source system. For instance, an HRM application often features Employee Self-Service for tasks like changing your address or submitting a leave request. To log in for these services, you’ll need a user account that may not necessarily be linked to HR records. These accounts can be managed by linking it as a target system to a User Provisioning system.
It’s also worth noting that target systems can be interrelated. For example, consider the case of a user’s email address. In a manual management system, this is usually generated by IT service desk personnel. However, before officially assigning the email address to a user, its availability must be confirmed. In an automated User Provisioning scenario, the IAM solution will handle the generation and check its availability in, for instance, an (Azure) Active Directory. This email address then becomes a crucial piece of data needed in multiple other systems, such as the previously mentioned HR self-service application
Identity Life Cycle
When talking about identity life cycle management, the principle is that when something changes for a user within a source system, it leads to modifications in one or more target systems. We can broadly distinguish the following identity life cycle events:
For example, once a person is registered in the source system, they need an account. The account is activated when the individual’s employment start date or admission date arrives. If other changes occur—such as name changes due to marriage or divorce, or role changes due to promotions—these result in updates to the account’s details and access rights. When an individual leaves the organisation, the system revokes their permissions, deactivates their account, and ultimately deletes it.
Typically, these procedures generate a substantial amount of manual work for both the HR and IT departments. HR is responsible for alerting IT whenever a change occurs to a user. In turn, IT service desk personnel and application managers must manually implement these changes across various systems. If either side fails or processes mutations in a batch, it affects timeliness, productivity, and data security.
A User Provisioning system can automate this entire process. The IAM system scans the source system at regular intervals and compares newly acquired data snapshots. A gap analysis is then conducted to automatically identify any mutations. For HR, the task remains the same— update the changes within the HR system. However, the HR team no longer needs to manually inform the IT department of these changes. The IAM system takes care of automatically updating the relevant linked target systems based on predefined procedures and attribute mappings. This not only reduces the workload for the IT service desk but also enhances functional application management. The end result is a streamlined automated process that ensures timely and error-free updates.
Role-based model
You may be curious about how the IAM solution knows which individuals in your organisation require a user account in specific applications, and what permissions they should have. This is governed by what’s called the role-based model within the IAM framework. Think of this role model as the brain system of your IAM setup. This model is sometimes also referred to as an authorization matrix, Role-Based Access Control (RBAC), or Attribute-Based Access Control (ABAC). In simpler terms, we could call these “business rules.” Each business rule is made up of specific conditions and permissions. The role model uses these conditions to decide when a business rule or role applies to a particular individual. The access rights specify what permissions they gain or lose based on whether or not they meet these conditions.
Conditions
Conditions determine which individuals fall within the scope of a business rule. Essentially, you’re filtering down to a subset of users who will be granted the permissions tied to that rule. The principle is that each user within the organisation is assigned a distinct ‘role’, correlating with their responsibilities and tasks. The type of work someone performs can be derived from their job title, team, department, service, and/or location. Initially, you’d lay out conditions that apply organisation-wide in an authorization matrix. For instance, almost every employee will require basic access rights such as an (Azure) AD account, as well as internet, intranet, and Microsoft Office access. As you delve into subcategories, such as departments, access to the department’s network drive may be required. Only when absolutely necessary do you consider individual roles or combinations of attributes like job title and department. In practice, you can handle many of the manual tasks at these broader organisational levels.
When you try to fine-tune access roles for each employee individually, you’ll quickly find that every person’s requirements are unique. As a result, you would end up with as many roles as there are employees. That’s exactly what we don’t want, as it simply shifts the manual user and authorization management to manual role model management. This will inevitably bring the same issues of error-proneness, timeliness, productivity, costs, etc., which a well-configured IAM solution is meant to resolve. The rule of thumb is that with User Provisioning, you can automate about 80% of your user and authorization management. The remaining 20% is managed by the IAM solution using service automation technology.
Access rights
Once you’ve identified a role, you assign access rights to specific applications and data to effectively fulfill that role. This ensures that everyone with the same role automatically receives the same rights.
There are five types of permissions that you can link to a role:
- Account
- Account access
- Group membership
- Permission
- Sub-permission
When assigning an account, a new user account is created for the user in a still blocked status. When account access is granted, the account is activated. Group membership refers to linking the user to a group in a target system. Permissions are custom rights in target systems to which optional sub-permissions can be linked.
Within an IAM solution, it’s important that these are closed-loop processes. In other words, there should always be a counterpart to the acquisition of an access right. If someone’s role changes, you’ll want their corresponding access rights to be automatically adjusted, so it’s not just additive. This is particularly challenging to keep track of for each user within a manual user and authorization management process. For an IAM solution like HelloID, this is much simpler. For example, the opposite of gaining a permission is revoking it; for account access, it’s deactivating an account; and for creating an account, it’s deleting it. By operating this way, you can be certain that you won’t end up with ghost accounts in your network that are no longer manually or automatically managed.
In our next blog, you’ll read how a Service Automation solution can help your organisation. Would you like to know more about our User Provisioning module within HelloID?
Written by:
Arnout van der Vorst
