Creating a user registry - design and development tips based on modern guidelines and standards [Part 1: Introduction]

Sooner or later, it is almost inevitable that a software engineer comes across the challenge of creating a user registry to store users, user attributes, user credentials and authentication / authorization activities.

It is a very common need since most applications, especially Web and mobile ones, require such functionality, however there are quite a few pi
tfalls in building a secure registry that will resist external and internal attacks. And it will attract attackers since it is one of the most critical component of an application / platform were sensitive data are stored.

Nowadays, there are offerings by cloud providers to create your user registry on their platforms or use OAuth to accept users from other applications, instead of storing their credentials in your premises. Also, there are of course, COTS solutions to run on-premises. Such solutions are definitely a valid way to avoid a significant number of concerns that you have when you build and maintain your own user registry, however there are significant drawbacks too. I will not get into that discussion and I will suppose that your organization decided to create and maintain its own registry of users, their credentials and their behaviors. Now your job is to create a component that will provide the appropriate functionality, be stable, have high performance, allow for various integrations and above all be secure.

The literature in this area is vast. As is the terminology used with the primary being: Identity and Access Management (or IAM) [Wikipedia article]. Yet, it is typical for IT security documents to be lengthy, abstract and lack practical advice - thankfully with a number of notable extensions, on which, this series of posts are based.

So, in the following posts, I will discuss certain aspects of building a user registry, focusing on design and development practices to ensure primarily security and secondarily flexibility with regard to requirements. I will avoid lengthy theoretical discussions and whenever possible I will point to what is currently regarded as best/leading practice.

Stay tuned!