Customer Identity and Access Management (CIAM) deployments include numerous elements though one of the key requirements is the ability for users to register.

Registration broadly falls into one of two categories:

• A user who hasn’t engaged with the company before and wants to register for services.
• A user who was previously engaged with the company though not registered; such as opening a bank account, taken out an insurance policy, registered for healthcare or entitled to government services.

The first case is well served by the out of the box functionality of CIAM vendors and is typically handled by either: by logging in through an external social identity provider such as Google or Facebook, or presenting a simple form asking customers for details such as email, first name, last name etc.

This works well for simple registrations but can soon start to produce long and complex forms. Research indicates forms should be broken down into individual questions to be easily digested and with advanced logic allowing questions to be altered depending on decisions, e.g. is the person registering under or over 21?

The second case is much more challenging. Let’s take for example the scenario of having previously opened an account with a bank and then wishing to register for Online Banking. In this scenario it is necessary to verify the following details against the held customer records:

• First name
• Last name
• Address/post code
• Date of Birth
• Account identifier e.g. credit card number, sort code and account number etc

With this information needing to be potentially matched against multiple sources of truth e.g. the credit card system, current account system etc. Combining this with the advice to break a form into multiple sections you can quickly end up with a complex registration flow as show in the following figure:

You can see that this starts to become a complex process, and this is omitting the details of the checks to see if the customer details match an existing customer which may reside in a database, LDAP directory or be verified against an API.

If customers currently using PingFederate for their CIAM solution have these additional requirements they should talk to ProofID about their off the shelf customer registration flows, which integrate with their existing business systems and add value to their current investment.

Blog sign-up


Latest from twitter

Ben Andrews

Written by: Paul Heaney, CISO – ProofID

Paul Heaney spent the last 10 years building, designing and supporting and provisioning access management and federated single sign-on solutions.  Since graduating from the University of Manchester with a BSc in Computer Science, Paul has held many technical roles including Support Engineer, Trainer, Architect and Developer across a number of identity technologies.

As ProofID’s CISO Paul travels the world evangelising in the latest trends in identity management and architecting identity solutions to meet our customers complex requirements.

Recommended for you

Ping Identity the challenge of 'run'

Single Sign-on to Outlook Web
Access Using PingFederate

9th February 2016

Automating the Route to Live with ProofID ConfigMigrator

Automating the Route to Live with ProofID ConfigMigrator

18th October 2017

PingFederate’s Dynamic Client Registration

25th March 2020