The Four "Ions", Or How To Provision CIAM Users

With IAM users (employees, contractors), users enter your system in a pretty straightforward manner, or are provisioned into it. "Provisioning" is a fancy identity word for bringing a new user into your system. There’s an event causing them to need access. Maybe it’s a new employee or vendor who has a contract, but it usually entails paperwork. If nothing else, invoices or tax documents serve as a record.

You know the start time and date. You know what access the user should have. And, when the employee leaves or the contract is over, you can disable their access.

This lifecycle clarity and access control is one of the main selling points for centralized IAM identity, from LDAP to Azure AD (or I guess they are calling it Microsoft Entra now?).

CIAM users are different. First of all, they are customers. That means they are paying for access to your system, which means that you can't dictate system setup or access method in the same manner that you can with employees.

Second, they don't have a well defined lifecycle. They may remain dormant in your system for months, only to become active when marketing sends them a special offer, a life event triggers need for your services, or even that they remember you.

Finally, there's not necessarily any paper record of the user, especially if they sign up for a free or trial account.

There are four ways for CIAM users to enter your user management system. I call them the four ions:

• registration: where the user signs up, usually on a website

• federation: where the user signs up, but the credentials are controlled by a third party like Google, GitHub or an OIDC provider

• creation: where you create the user directly in the CIAM system

• migration: where you are moving user accounts from a previous identity store

In the next few newsletters, I'm going to dive into each of these methods for CIAM user provisioning.

Dan