News

First, a small terminological digression: a simple translation of the English term Identity management can lead to two phrases: identity management and identity governance. Each of them encompasses a different perspective on the issue, and together they define what the field is all about.

The term identity management can be thought of as keeping track of identities, managing their lifecycle – creation, updating, termination, status reporting, i.e. the operational back end.  Identity governance can then be more evocative of a business view of the issue – defining rules such as: who can go where, from which system to which information travels, under what conditions and who is informed about it.

Nevertheless, we will allow ourselves a slight imprecision here, and in the following we will interchange these terms, in the meaning of identity management as a whole.

Let us now say what all falls under the umbrella of identity management, and what does not. First of all, it is necessary to sort out the terminology of what we perceive by what label:

• User – a natural person who intends to use the information system
• Information system – a program/application/software that performs a given function
• Account – an account on an information system that allows a user to log in and have permissions to resources available on the information system
• Permissions – permissions grant or deny a user rights on the information system
• Roles – roles allow users to add or remove permissions in a controlled manner; roles are assigned to identities in an identity management environment. There is a distinction between business roles (procedural, such as Finance Officer) and application roles (technical, such as Active Directory User)
• Identity – a virtual entity that represents the attributes, roles, and accounts of a user in end systems; identities are stored in an identity repository.

Figure 1 – Basic concepts in identity management

The term identity management can therefore be understood as:

• Identity management – who are the users of information systems.
• Permissions management – where users have access.
• Role management – what roles exist in the system and how they change.
• Login management – how users access information systems.

Identity management

Identity management provides an overview of what identities exist in the system and what attributes (properties) they have. It also takes care of the identity lifecycle. From a management perspective, the most common division of identities is into internal and external.

Employees

Internal identities represent employees in various types of employment (so-called Business-to-Employees, or B2E for short). Often, this includes people working under a work arrangement. They usually arise from the activities of the HR department. These identities typically have role-based access as well as a basic set of permissions that allow them to work with the company’s core information systems. It is therefore important to define, for example, rules for changing roles. Users often request permissions themselves or through a manager.

Suppliers

External identities represent business entities – suppliers, partners (Business-to-Business, or B2B for short) and customers (see below). B2B identities have a competent person on the company side who takes care of setting up the identity and arranges authorization requests. In internal systems (e.g. LDAP server) they tend to be organizationally separate from internal identities. These identities tend to be subject to security audits. This is because they can easily remain in the systems after the end of a project, for example.

Customers

The second group of external identities are customers (or Business-to-Customers, B2C for short) . The specificity of B2C is typically access to one system where they register themselves. From this perspective, it would seem that they do not need to be included under identity management, and often stand on the periphery of the field. However, a more interesting situation arises if the process is more complex – for example, customers receive a certificate that is issued independently of their registration and only then paired for authentication purposes, or if customers want to log into internal systems with their external identity (the Bring Your Own Identity (BYOID) concept). In such cases, B2Cs also become legal participants in identity management.

Management of authorisations

Permissions management allows users to request permissions, approve these requests, and then set permissions in information systems. It also includes reporting on important insights such as who has access to where, who has approved permissions and when.

Approving permissions

An important and almost essential part of permission management is the approval workflow, or the process by which a user’s request for a particular permission is approved in a defined way. There are three groups typically involved in this process: line workers (managers), role ghosts, and security. Line workers are primarily direct supervisors who act as the first filter for requests (“does my subordinate need this role?”).

They are followed by role gurus, who know the meaning of the role well and are therefore able to assess whether the applicant is eligible for the requested permission. The last link in the chain of approvers is represented by ICT security staff. They assess role requests in terms of compliance with the company’s security policy (“is a user with these characteristics allowed to access the resource?”).

Role management

In the predominant case where permissions are controlled by roles, you need to specify how the roles will be managed. To do this, we need to know: where the roles will be stored, who will manage them, and how they will be managed.

Where to store roles

In principle, we can store roles in any structured location – an Excel spreadsheet, a hierarchical tree, a dedicated role management tool. However, if we want to automate roles using Identity Manager, it is important that such a storage location is programmatically tractable for the identity management tool. Another option is to use Identity Manager as the authoritative source of role information.

How roles are managed

Properly defining the role management process is crucial, as it has a direct impact on whether a user can work with the information system and is authorized to do so. The questions to be answered are:

1. Who designs the roles?
2. Will changes to the role system be subject to approval by another person?
3. Who physically establishes the roles in the system?

Figure 2 – Role Hierarchy + example

Responsibilities

The correct design of the business role (see figure Role Hierarchy + example) is handled by the methodologist. It is his responsibility to ensure that each role created meets the business requirements. He also proposes, in cooperation with the information system owners, which application roles the business role consists of and what permissions these application roles have. It stores this information in the role repository. From there, Identity Manager either retrieves it directly or it is forwarded, for example, in the form of a report to IdM administrators, who then make the necessary changes.

Login management

The user now exists, has been assigned the correct role, and is based on this assignment on the endpoint information system. But he cannot yet authenticate – he has not yet propagated the relevant data to the information system. For this to be the case, it is the responsibility of the login management.

Login management involves the distribution of information that is essential for successful user authentication – authentication and authorization. This information may be, for example, a password, PIN, or certificate for authentication, and for authorization, for example, a role or group on the information system. If another provider is used for user authentication, this also includes the management of these attribute controls – for example, the identification of the user with that provider.

Security aspects

And what can corporate ICT security expect from the implementation of identity management? Surprisingly a lot.

In a nutshell, we can talk about the following points

• More detailed reporting
• Enforcement of company policies
• Permission audits and exception handling
• Review of authorisations through recertification
• Better information systems security

Company policies

Policies define the “rules of the game”. For example, they can describe what a password should look like – which is probably the most common use. We may also see access rules – who must and must not get where, what access people must not be granted at the same time (Segregation of Duties), a rule that all permissions must be assigned by role (RBAC principle), or perhaps what a login name should look like.

Audit

In addition to configuring these rules in Identity Manager, compliance tests help to ensure that they are not just on paper. These are periodically or purposely run reports that check whether accounts comply with the audit rules – for example, whether a user has the permissions in the information system that should belong to him according to Identity Manager, or whether each account in the information system is assigned to a user by role (RBAC principle). If such an inconsistency is found against the rules, a so-called remediation is triggered. This involves a remediator, who is the person whose job it is to deal with these findings. He or she makes an assessment of the situation, which can lead to two conclusions: either the finding is in line with the set safety level and then adds the finding as an exception to the rules, or it cannot be added as an exception. In this case, the remediator must ensure that the discovery is removed (for example, by removing the user’s permissions). However, since the actual resolution of the find is beyond the scope of the remediation itself, the find is marked as resolved in this case. A further audit will then show whether the situation is already in order or whether the finding will be repeated.

Figure 3 – Process of audit and remediation

Recertification

The last option we will mention in the context of permissions and security management is the ability to trigger recertification. This is useful when we want to force a review of a user’s or (more commonly) a group’s permissions. For example, we want to periodically review once a year whether our contractors still need all access. Recertification will restart the approval workflow for individual roles as if they were re-requested. If all approvers confirm that the role is eligible, the user will not know anything. However, if during the process it is determined that a role is no longer needed (because, for example, the project the supplier was working on has ended), the role will be denied and access will be revoked for that user.

Conclusion

In part two, we went over identity management and governance in more detail. We defined the basic terms and discussed the 4 main areas that make up identity management: identity management, permission management, role management, and access management. Finally, we looked at what ICT security can expect from IdM.

In the next installment, we’ll explore how permissions can be assigned to users in the context of role management, and we’ll show how to tame the rampant privilege sprawl. The second part of the episode then looks at advanced identity management features. We’ll go over license management, time-limited roles, delegation of privileged roles, escalation as a failsafe for procrastination, and linking to the help desk system.

Author: Petr Gašparík