The pros and cons of moving to a single team and vendor or keep separate groups of Customer Identity Access Management (CIAM) ad Enterprise Identity Access Management (EIAM)
Over the last few years, I’ve had this conversation with different CISOs, IAM Directors and Digital Marketing groups regarding how to support their differing IAM needs between the Business to Consumer, Business to Business and Business to Employee user populations. The question is always: do we move to a single team and vendor to do everything or do we keep Enterprise IAM and Consumer IAM as separate groups?
The Rationale & Downfall to Keep as Separate IAM Groups
Until a few years ago, my immediate response was always to keep them separate groups and functions. I based this response due to risks associated with public identities, compliance and regulatory differences in populations, limited control of users, and lack of utilitarian value of the data in the context of the IAM program.
But as these barriers started to break down and IAM teams matured more in terms of capabilities, I thought the general movement and momentum was to do more and centralize capabilities within single products and teams. As we moved into the COVID-era and the ‘new norm’, things shifted back to separate teams and technologies due to shifting priorities and usage patterns.
The long and short of the question though, is it really depends on your requirements, usage patterns, and functions of IAM you are looking to converge or diverge. I’m aiming to break down where things are today, why I think we’re going in this direction, and where the break and decisions are between converging and diverging the CIAM and EIAM products and teams.
Why the Difference Between CIAM and EIAM
With both CIAM and EIAM you are managing users and their access to applications. That’s in its simplest form, but looking deeper there are major differences between consumer or customer identity access management (CIAM) and employees (EIAM) that ultimately comes down to user environment and governance.
For employees accessing internal business management functions, applications, and data, the entire experience is controlled from onboarding via Human Resources (HR) to access large sets of disparate applications and data.
In a consumer or public scenario, everything is uncontrolled and you have a single or few integrated application stacks. Given these major differences, you have different ways in how you handle initial creation, access, and processes for managing the users in the different populations.
Given the differences in environment, the CIAM functions were traditionally managed by the application or digital marketing teams that focused on that public presence of the organization. This was supported given the monolithic ways of developing applications and limited data use cases for public user info in those applications. Large single application stacks and environments for consumers allowed for creating and managing users within that application environment.
IAM Components for CIAM and EIAM
CIAM and EIAM have different IAM components and focus areas. See Diagrams below.
- EIAM is more focused on the governance and program management.
- CIAM is more focused on experience, integrations, and driving business value.
As noted, it really depends on the convergence of CIAM and EIAM. When looking at the components of each, we can start looking at how to converge or diverge the different functional components in your CIAM and EIAM strategy.
Let’s take a look at what components and focus areas are in each. IDMWORKS likes to boil this down to five critical focus areas in each user group.
In an EIAM deployment, you are going to have different components support the EIAM program.
Figure 1: EIAM Program Components
In a CIAM deployment, you are going to have the critical components outlined in Figure 2.
Figure 2: CIAM Program Components
When Does it Makes Sense to Converge vs Diverge?
Since we are all trying to do more with limited teams and resources, let’s take a look at where we can leverage existing capabilities and infrastructure and what makes sense to separate out.
To start, in both CIAM and EIAM functional areas, you are going to have a data warehouse and storage of your identities. In most cases I experience, this is going to be your LDAP or other enterprise directory. This also doubles as your main authentication data store (usernames / passwords / history) and base authorization (ACLs, group membership, etc.).
In both a CIAM and EIAM deployment, this is generally populated with identity data via some form of onboarding or registration type of flow. Given the security and data storage model of LDAP, this is a good starting point to combine identity infrastructure. You could have separate tree or roots in a common LDAP data warehouse to store and maintain all your identities across your public and non-public IAM components. This gives you scale and visibility into the identities you maintain across populations.
The next major area to benefit from converging is going your primary Authentication (or Access Management) infrastructure. Commonly in the form of components like Single Sign-on, Federation, Oauth, etc. For CIAM and EIAM, you are going to want this for things like usability, Multi-factor Authentication (MFA), etc. The main difference with Authentication in the CIAM and EIAM is the factors that are used and enforcement of access restrictions.
In both populations, you could have a common vendor or deployment and have application and policy flows that account for usability and different identity sources from the data warehouse (e.g. employee use Kerberos / Push MFA vs consumers use username/password / OTP). I see a lot of my customers standardizing on a product vendor in this area then having separate installs for the different integrations.
Where we start to diverge in the IAM components is around identity governance
EIAM Solutions – Identity Governance
On the EIAM side, you have a heavy governance requirement for managing authoritative events, provisioning, and large set of target applications to integrate with differing rules. Additionally, you have a lot of ongoing maintenance of those identities and targets to ensure continued appropriate access is maintained.
CIAM Solutions – Identity Governance
For CIAM, you generally have a limited set of rules and policies other than some self-service profile management and limited ongoing maintenance of those identities. The largest issue I see in governance and identity management on the CIAM side is privacy changes and data storage and removal requirements. So, given this, I see most of my customers having separate identity governance components for EIAM and CIAM based on product capabilities.
Other primary components of Privilege, Data Governance, etc. are used in a CIAM deployment but this is more around maintaining employee access to that infrastructure so would fall into EIAM type of deployment and would be maintained separately.
Why the Change for CIAM and EIAM and Challenges?
It used to be that customoer facing and public applications were run mainly in monolithic application stacks maintaining credentials and security internal to that platform. However, as people are evaluating their applications, moving to cloud platforms, microservices, and starting to leverage a lot more integrations (e.g. Service Now ticketing, Salesforce ecommerce, etc.), they need an identity tier to map users across the different platforms and integrations. This gives rise to looking at EIAM teams and capabilities given this is being done internally for employees today.
This is where the challenge comes in. For EIAM deployments and teams, you have control, set processes and standards and largely you are more concerned with managing access or compliance. In a consumer type of deployment, you need to focus on the user experience and customizations. This is where I see a lot of failures in these types of conversations and deployments.
How to Move Forward?
Given you’re reading this blog, I’m assuming you’re challenged on how to manage your EIAM and CIAM infrastructure, resources, and strategy.
Pause
My first recommendation to move forward is to stop and take a step back for a moment. The easiest thing to do when being tasked with building this out is to stop, take inventory of what is needed, requirements, use cases, etc. and then develop a plan of what makes sense for your environment and use cases.
Take Inventory
Once you’ve paused to take inventory, start looking at how things are different or the same, and what you can build out to support the different user populations and infrastructure. With that in mind, go to the relevant points of contact for the business (EIAM and CIAM) and ask the simple questions of what the desired end-state and usage of the environments, what will be the impacts of each, etc.
Strategy
From there, you can formulate a strategy on where you can leverage existing resources and technology, where you need to diverge and add different infrastructure, etc. Use this as the basis of your plan and strategy to address these needs to support business.
Additionally, as you evaluate and build your strategy, look at partners and integrators that do this on a regular basis. At IDMWORKS, we talk with and help a lot of customers look at these types of scenarios and what makes sense for them. There is no easy answer to this, and honestly it can get quite complicated, so don’t go it alone and look for industry and partner support in developing your strategy.
Author, Nick Hunt, IDMWORKS, IAM Delivery Director