What is a good sequence for an IAM implementation?
A modern IAM solution is connected to a multitude of systems, plays a role in numerous processes, and therefore cannot be implemented in one big bang. Typically, organisations start the implementation by migrating existing IAM processes and then plan the phased rollout of new functions. In doing so, what should you pay attention to? Every organisation has different starting points, requirements and wishes.
In the blog post below, we explain this in more detail. We use our HelloID cloud-based IAM platform as an example, which consists of three modules: Access Management, Provisioning and Service Automation. With these three modules, HelloID is essentially prepared for the most common growth trajectory: We start with basic authentication and authorisation functions; then we automate the associated user onboarding, transition and offboarding processes; following which we also streamline the ‘special cases’ and further account management processes, thanks to service automation. However, each module offers various functions that do not necessarily all have to be implemented – or implemented right from the start. Below, we outline an example of possible growth steps, show the interdependencies between the different functions, and demonstrate how you can gradually add more functions.
We also outline what each step can contribute to someone’s organisational goals. IAM functionality can contribute to various aspects including improving access and information security, compliance with privacy and security guidelines, the (cost) efficiency of account management, and the user-friendliness for end-users.
In this article
Step 1: Access Management implementation
The Access Management module provides the core access functionality for which IAM systems have traditionally been developed. It manages the authentication of users (often with a username and password) and then grants users access to applications and data (authorisation). In many organisations, this authentication and authorisation function is now standardly embedded within their Microsoft (Active Directory or Entra ID) or Google Workspace environment. They act as the primary identity provider to grant users access to their IT services.
However, this does not mean that the IAM Access Management functionality has become redundant. For some IT environments, indeed, that Microsoft or Google Identity Provider suffices, but there are plenty of exceptional situations and special requirements that cannot be easily achieved with this standard functionality. Also, in merger and migration projects, a more flexible Access Management environment may be necessary. And last but not least, in some cases, a solution using Access Management is simply (much) more cost-effective than one that uses the standard Identity Providers. For all those cases, an Access Management solution offers multiple functions and user scenarios that can be activated as needed:
Additional or overarching Identity Provider(s)
Expansion to various user groups
As explained above, in a standard IT environment that only needs to be accessible to an organisation’s own employees, the common Active Directory, Entra ID (formerly Azure AD) or Google Workspace Identity Provider usually suffices. However, more and more frequently, organisations wish to grant access to other user groups. For instance, companies may want to make CRM data accessible to customers, healthcare institutions may wish to give clients access to their personal data, and educational institutions may want students to directly log into their digital learning environment. There is also a need to give temporary workers access to IT applications and, during mergers, to allow employees from different organisations to easily use each other’s systems.
Issues using multiple Identity Providers
Many of these ‘new’ user groups are not registered in that primary Identity Provider. For customers, for example, the CRM system acts as the identity provider, and student account details are recorded in the student administration system. Hence, we are increasingly dealing with multiple identity providers, while target applications usually only support one identity provider. Such an application cannot then be used simultaneously by the organisation’s own employees and clients, temporary workers and students. Providing everyone with, for example, Entra ID accounts is often an undesirable and expensive solution.
Integration of multiple Identity Providers via Access Management
An Access Management solution like HelloID can in this case act as an ‘adapter’ between multiple identity providers and the target applications. Each user group can use their own identity provider to gain access to the access management system, which then ensures that everyone gains access to the required ICT resources. With the implementation of Access Management, you can flexibly manage multiple types of users in your IT landscape.
Single Sign-On
When someone logs into the network, they usually automatically gain access to basic office applications such as mail and office. However, inconveniences may arise if people use other applications and then have to log in again and again. Single Sign-On is the solution to this problem. Thanks to this feature, users only have to log in once at the start of the day, following which they have immediate access to all their applications and data without having to log in again. It is worth noting that, from this perspective, an easy growth trajectory is available; HelloID supports all the major SSO standards, allowing you to start with the most important variant and build from there.
Multi-Factor Authenticatie (MFA)
Within the world of access security, passwords are a source of risk. By adding an extra security check, we significantly improve access security. Through MFA, we perform an extra verification using something the person possesses (such as a smartphone). After the regular login with a username and password, the user must enter a code sent to their smartphone. In this case, we also have a growth trajectory available. You could start with one specific authenticator app for smartphones and gradually add other options (such as security tokens).
Conditional access
With the flexible Access Management module, you are also able to make access to applications and data dependent on the further ‘context’ of the user. From which location is someone requesting access? At the office, over the internet or from abroad? And with what device and at what time are they logging in? Depending on these factors, you can block some functions or data or only make them accessible after an extra MFA verification. Thanks to this conditional access, an access management solution ensures that organisations maintain more control over who gets access, when, and from where.
Access portal
If the organisation does not already have a start menu from which the various applications and data shares can be accessed with one click, Tools4ever can implement such a HelloID Access Management portal for you. If desired, this can be integrated as a widget in, for example, an existing intranet or SharePoint Online environment.
Step 2: Orchestrating and automating provisioning
With the implementation of the aforementioned Access Management functionality, we take care of the basic authentication and authorisation of users. An individual’s digital identity is verified, and based on that, access to the IT environment is granted.
However, Access Management alone does not prepare us for the increasingly complex management of all access rules for sometimes hundreds or thousands of users. These days, organisations often work with dozens of applications and data sources where ‘least privilege access’ is a crucial requirement; everyone should only have access to those applications and data necessary for their work. This is the only way to remain compliant with current information security and privacy guidelines. A person’s access rights, for example, depend on their role, department or work location, and if there is any change in these factors, the corresponding access rights must automatically be adjusted.
To achieve this, access management alone is insufficient. A management system is needed that guarantees that people are automatically provided with the correct rights throughout their entire period of employment. This applies not just to permanent staff but also, for example, to temporary workers, clients, students, etc. This is a requirement from the time someone joins the organisation, through their transitions to other roles, and up until they leave the organisation. The HelloID Provisioning module automates this workflow and thus forms the core of a modern IAM solution. It manages the account and rights for users based on a clear set of user roles and associated access rights defined in business rules. To do this, you will link the Provisioning module to the following systems and gradually implement further functions:
Linking with HR (and other source systems)
Traditionally, the IT support department takes care of creating and managing user accounts and access rights. A manager or the HR department would first send through a request for a new account – often in the form of a form. The IT staff member then timely starts preparing account details, access rights and other facilities, and activates these (or has them activated) in the various systems.
It is, of course, much more logical and efficient to directly deploy source data to achieve this outcome. HR registers all employment contracts and information about someone’s specific role anyway. By linking the HR system to HelloID Provisioning, you can trigger the creation of new accounts – but also the modification of rights when someone takes on a different role – directly from the HR system. HelloID then manages the ‘identity lifecycle’ of user accounts and access rights, processes updates automatically, and translates them into the correct settings in the underlying IT systems. Therefore, the link between the HR system and the HelloID Provisioning functionality is normally implemented right at the start of implementation. Similarly, for example, a student administration system can also be linked. In all cases, the responsibility for the user data lies with the relevant ‘business owner’.
Further development of business rules
The use of business rules is the most convenient way to achieve Role Based Access Control; a concept where someone’s role automatically determines which access rights they get. This is the best way to implement ‘least privilege access’ in a manageable manner. It is important to note that you can opt for a growth path here. Initially, you can start with basic business rules and gradually elaborate and refine these. For example, more operational roles (such as healthcare staff in healthcare institutions) can be fully developed into so-called key roles, where someone’s role can directly deliver all the necessary rights and facilities. For more generic roles like a project manager, a basic account is automatically created, following which specific rights will need to be requested separately.
Links to target systems
We often automate the provisioning of account details for basic (office) applications from the get-go, with links between the HR system, HelloID and, for example, Active Directory. From there, the link between HelloID and an IT Service Management (ITSM) solution such as TOPdesk often takes priority. This helps to simplify existing service desk processes, including the issuance of physical facilities such as laptops, smartphones, security tokens or access badges.
For more specific applications – such as a client file – the choice may initially be to only send automatic notifications, following which the respective application administrators must themselves process the data in the target systems. HelloID Provisioning then ‘orchestrates’ the issuance of accounts and rights but does not yet fully automate them. From there, a fully automatic link is the logical next step.
This way, the IT organisation can gradually implement more provisioning links with target systems and further automate the account processes. Each organisation can set their own pace for this. Tools4ever is increasingly providing more and more standard links that merely need to be configured and rolled out.
Step 3: Automating service processes
Through the help of step 2, we are thus managing accounts and access rights based on established user roles. This constitutes the policy you will be working with, which generally covers about 80% of all access rights. For the previously mentioned key roles, we can even fully automate the rights management.
However, the remaining 20% of all access rights normally need to be provided and managed on an individual basis. After all, we can never fully define all roles. For a project manager, the Provisioning module can provide the so-called birthrights, but if someone temporarily needs Visio access for a project, this must be individually requested. These are manual processes by nature, but thanks to the help of Service Automation, you can also better streamline this remaining 20% of ‘exceptions and special cases’.
This is not just a matter of granting extra access rights; we can also use Service Automation for other processes, ranging from password resets or name changes to creating and extending guest accounts. Service Automation can also be used, for example, to manage a process for the acceptance of user terms, required before someone can use an account.
Automating service processes
We do not have to start with self-service right off the bat. HelloID enables us to first optimise helpdesk processes, and from there carry out a ‘shift left’ migration for each process: initially, changes can be made by managers and functional administrators, and eventually, self-service can be offered to end-users:
Delegated forms support team
A first step is to optimise and better secure helpdesk tasks. To perform these tasks, helpdesk staff traditionally have extensive admin rights to complex applications like Active Directory Users & Computers (ADUC). This requires a relatively high level of knowledge from the staff, and that direct access is costly (user licenses) and risky.
HelloID Helpdesk Delegation allows for the provisioning of delegated forms to so-called non-skilled or semi-skilled helpdesk workers. Through these forms, they can perform IT management tasks – such as creating accounts and changing rights – without needing admin rights in the underlying systems. HelloID processes the forms and automatically carries out the required changes in the backend systems. This makes the workflow simpler, safer and cheaper, while ensuring that processes are uniformly executed and auditable.
Delegation to managers and/or ‘resource owners’
A possible next step is to move (some) management tasks to, for example, managers, functional administrators or license managers. They are best positioned to assess requests for their team or specific applications and can handle them directly using such delegated forms. Technically, this is a simple step because it builds on the forms and actions already developed for the service desk.
From an organisational perspective, the impact is more significant. After implementing this layer, managers, in particular, have much more insight into the licenses and access rights their employees use. This raises managers’ awareness of their department’s ‘IT footprint’ and thus helps in reducing unnecessary costs. For the IT department, this approach means that a cumbersome process involving service tickets and service workers is no longer necessary.
Self-service: delegation to users
The ultimate step is delegation to the end-user (self-service). Through an online catalogue, employees can independently request rights to applications, folders or mailboxes, for example. Through one or more online approval steps by involved manager(s) or product owners, Service Automation can then ensure that the changes are automatically processed in the concerned backend systems.
Besides handling access requests to systems, applications and folders, the platform also offers the possibility for controlled customisation to automate complex and organisation-specific issuance and management processes. Each type of request and service request can be scheduled as an independent project at the desired time. Once again, there is no need for a big bang approach
Step 4: Monitoring, audits and compliance
A crucial role for modern IAM environments is the airtight registration of issued rights and the logging of all user actions. This allows for the demonstration of compliance with one’s own information security plans, the underlying security standards and relevant privacy legislation. HelloID records all activities in audit logs. Based on these, HelloID provides standard reports to HelloID administrators, managers and product owners. Urgent information is communicated in the form of incidents. HelloID also offers a growth path for this information provision:
Standard logs and reports
HelloID provides standard logs and reports, depending on the HelloID modules used. For instance, Access Management reports contain information on current access attempts, while Provisioning reports focus on the creation of and changes to accounts, business rules and rights. The Service Automation module provides log data on specialised processes.
Client-specific reports, analyses and monitoring
The number of available standard logs and reports increases as you roll out more HelloID functionalities. Additionally, you can create client-specific reports as desired, for example, with the Elastic Kibana dashboard and reporting functionality. HelloID also has various APIs for Power BI and other business applications and security systems to store data longer, combine and correlate it with other data, and then further analyse it. This also supports links with, for example, customers’ SIEM environments.
Steps in implementing IAM
The HelloID roadmap
With HelloID, you can gradually roll out more IAM functionalities at a pace that suits your organisation and meets your needs. Additionally, we continue to develop the HelloID platform. Since the IDaaS solution HelloID has a new release every month, new features are periodically added. For more information on this, please refer to our public roadmap at https://roadmap.helloid.com/milestones.
Written by:
Arnout van der Vorst