Model

intro

When we speak about identity management within small, medium or large organisations, one of the most common challenges we have is identifying what the specific organisation model is.

In an ideal world, we would define a model that is applicable to all organisations, so our identity management solution is generic and can be used in each use case.

But ....

Fact is that due to the nature of the of the specific industry in which the organisation is residing, specific needs and data structures appear. These structures grow kind of automatically because of the fact that they are the most efficient way to guide the processes and workflows needed for the organisation's needs and maintainability.

Data models in the banking industry, medical departments, telecom, insurances and so on, differ and people working within these structures tend to rather not change their specific model.

Therefore out of the box identity management solutions are a challenge, specifically to merge and incorporate them with these models.

Either you compromise on the model and give in to have a simple model, either you customize the chosen product until is it not the standard product anymore.

Both options have important downsides.

Models for customer identity management (CIAM) and for internal employee identity management (or corporate IAM) also differ.

Customer identity management is more focused on authentication, coarse grained authorization, billing and person oriented.

Employee identity management required finer grained authorization via roles, automatic assignment, approval workflow and is more organisation oriented.

scope

The scope of the model within a IAM system is important.

One should think the entities to be included in such a model would only be related to authentication and authorization.

That would lead us to a simple model containing identities and roles.

But reality learns us that is is more complex.

First of all, when you want to 'manage' identities, or human resources like some of them call them, we came to conclude that the environment in which the identity operates is gigantic.

For example, the identity has devices like laptops, smartphones, entry badges and so on that have to be managed.

The identity operates within one or several contexts, called organisations or departments, and people in charge of these organisations need to manage and audit.

People are joining, moving and leaving and have to be notified.

The identity has to have access to applications and these applications need to be aware of their existence and function.

Also the privacy of data is becoming more and more important.

For reducing the workload on managing identities, self service processes are introduced.

So next to the authentication and authorization, we come to realize that there about five main blocks for managing a identity in the environment and the processes around.

• identity vault : containing identities and entities

• workflow : (automatic) approval processes and tasks

• provisioning : pushing data from the model to other applications

• governance : control, audit, (re)certify

• schedulers : notification, automatic assignment and expiration, ...

One could argue that all those entities and modules can be separated and managed by different products.

There are specific products for each module, but they all have the challenge to match with the domain model of the company.

Would it be possible to have a domain-centric approach: start from a domain model and generate the IAM building blocks?