Identity and Access Management (IAM) or in simple words "the user management" – why it matters and what to do

Necessity of an identity and access management system embodied by two hands holding identities in form of circles with anonymous personas inside.

Every website, every App, every online service with a login-functionality needs to allow its users to authenticate themselves and must assign them rights and privileges: decide what those users can do, which data they can read, write, modify, and delete.

This is what Identity and Access Management (IAM) is all about.

Why Identity & Access Management (IAM) is important: if it fails, things break apart

We all have seen those set-pieces of hackers in movies: the hacker, trying to access a computer system, uses credentials of a person they pretend to be, then "guessing" the password, and voila: in they are. A bit later they may have to get extended rights or find a user with more privileges on the system they try to get under control.

And that is why IAM is so terribly important: when it fails, things fall apart, and do so in a catastrophic fashion. Users can steal, delete, or create new identities. And they can do things they should not be able to do: access trade secrets, change records, plant logic bombs. Or most often, just buy some stuff on somebody else's account.

IAM is the very access point to everything that can be done with a system, to all data stored, to all actions possible. It is akin to a house key plus code for the alarm system: if the IAM does not work, the whole system or platform is wide open.

What Identity and Access Management (IAM) must be able to do

IAM is a broad and not very precisely defined term. Hence, there are often used other terms, meaning the same as Identity and Access Management or shortly IAM, e.g. authentication solution, or user management. There are different kind of sub-groups, e.g. Customer Identity and Access Management consisting of services which are in particular important for all consumer facing websites with a login while enterprise solution might be facing inwards to the intranet of an organization.

Yet here are some things that any solution should be able to do:

  • Needs to be centralized, binding multiple resources and sub-systems seamlessly together.
  • Should support Single-sign-on: users should be able to access different sub-systems with one identity.
  • Needs to reliably authenticate users and should support advanced authentication methods (multi-factor) for users with advances access rights.
  • Needs to offer convenient self-service mechanisms to users (e.g., changing passwords).
  • Should offer role-based access rights: access rights should not be tailor-made but pre-defined on a least-privilege / need to access base.
  • Should be able to map complex set of access rules existing in the organization or on the platform.

Where data protection and privacy come in

This set of functions shows: the IAM service is the key to the whole system: all the data, all the identities, everything that can be done on the platform. Therefore, if there are deficiencies in technical data protection here, the whole system is non-compliant and may easily be compromised.

This is the reason why for example the German Federal Office for Information Security (Bundesamt für Sicherheit in der Informationssicherheit, or BSI) devotes a whole section of its IT-Grundschutz (base protection) Compendium to IAM (ORP.4 – Identity and Access Management. It notes, first of all, that responsibility for IAM rests at the C-Level (Section 3). Secondly, the IAM service should be a central network service (ORP.4 A18). And thirdly, that the service should meet all the criteria set forth in the comprehensive section of the Compendium.

For most services beyond a certain size and complexity, it is almost impossible to meet all those criteria with a self-made solution. This is especially true in distributed systems needing a cloud based IAM solution. A provider is needed, which means in data-protection thinking: commissioned data processing according to Art. 28 GDPR will take place (or, in some cases: joint controllership, Art. 26 GDPR).

As authentication data are personal data, and as they are the key to access even more data, a data transfer to and from the IAM provider is taking place, triggering the complex set or rules stipulated in the GDPR regarding such.

  • The IAM provider hast to be carefully chosen, the respective reasons should be documented.
  • A Data Processing Agreement (DPA) is needed between the parties to govern the processing of personal data on behalf of the controller.
  • Data transfers to third countries / countries without an adequacy decision are only possible with appropriate safeguards.
  • Such safeguards are almost impossible to meet in the case of IAM providers from the US, meaning that either the respective servers are located in the US or the provider (or the corporate parent of such) is headquartered in the US.

Action required

IAM systems do not always get the attention they deserve. They work under the hood, are very technical, and in no way exciting. Yet they are the gatekeeper between a system and the world. If they are weak or compromised or simply not compliant, then so is the whole system. Again: IAM is C-Level responsibility.

The good news: choosing a proper cloud based IAM system makes life easier for the organization, the IT-department, and users alike. Well defined roles and easy to use self-service interfaces minimize administration efforts and make processes transparent. Maintenance and further development are outsourced to a provider working centrally and efficiently and constantly following the latest developments in the technology, administration, and law.

We at Engity think: this is simply good business.