In part three, we learned about the management role, how permissions can be assigned to users and how to tame uncontrolled permission accumulation. In the second part, we looked at advanced identity management features. We went over license management, time-limited roles, delegation of privileged roles, escalation in permission management, and linking to the help desk system.

In this volume, we will follow up on these areas with two chapters related to identity management: access management as an active element of evaluating requests for access to systems, and SSH key management for better administration of Linux users.

Access Management

Access management ensures secure user access to the information system. We will focus here on the following chapters:

• AM in the context of IdM – how does it fit in with what we have already said?
• Authentication and authorization – what it is and what it is for.
• Single Sign-On (and Off) – for user convenience and security.
• Federation – when servers understand each other.
• BYOID – or when users bring their digital identity with them.
• Security considerations – identifying threats.
• RAdAC – and how to counter them.

Access Management in IdM context

How does access management fit into the whole identity management framework? In the beginning, identity management established the identity, then role management allowed the user to request access, then permission management ensured the request was approved, and login management added the necessary authentication and authorization data. It is now up to access management to match this data against the user’s current request for access to the information system. This is done using the Access Manager tool, through which access requests typically pass, and this is also where real-time evaluation takes place. This is clearly illustrated in the following figure.

Figure 1 – Access Management, principle

Access management and identity management area is collectively referred to as Identity & Access Management (IAM).

Authentication and authorization

Authentication is the verification of a user entity based on the submitted login credentials. This authentication can be based on more than one piece of information, then we are talking about Multi-Factor Authentication (MFA). The most common form of two-factor authentication (TFA) is a password + an independent code (SMS, hardware token, mobile app code).

An example of multi-factor authentication: a user enters a login name and password into the application and submits a form. The user then receives a one-time password (OTP, One-Time Password) on his mobile phone, which he enters on the next page of the form. This authenticates the user from multiple perspectives and increases the likelihood that they are who they say they are.

Authorization follows authentication and examines whether the user is eligible for the page/service/operation he/she is requesting. Generally, whether he/she has the right to access the resource. If so, the operation is allowed. If not, he/she is informed of this in some way – in the case of web pages this is information like “Server returned error 401 – Unauthorized access”.

A final note: we are talking about users here for the sake of convenience, but the same principle applies to automated communication between systems and services.

Single Sign-On (and Off)

Having multiple user accounts on different systems seems to be a necessity nowadays. However, with a new account comes a new password/PIN/code. Therefore, the concept of Single Sign-On (SSO) has been proposed to increase the user experience in this area. The basic idea is that a user logs in against one resource (system, service) and is then automatically logged in to other resources based on this login. Here, the authentication source serves as a guarantor of correct user authentication.

In the web environment, this concept is referred to as Web SSO, and we know it from, for example, Facebook or Google products. The opposite of Single Sign-On is Single Sign-Off. This refers to the automatic logout from all collaborating applications after logging out of the main authentication source. This is an important security point in solutions that treat situations where, for example, a user uses SSO to a company website in a coffee shop and needs to log out securely after work.

Federation

Related to the SSO area is another concept that arises in the context of access control – federation. Consider the case where there are two independent information systems that authenticate users (for example, a ticketing site and a hotel reservation site). Now suppose we want to log a user of the ticketing site automatically into the hotel registration site. The mentioned SSO is not enough for us here, both sites are at the same level. However, it will help us establish trust between the two servers (the hotel booking site trusts the ticketing store for user authentication) and use one of the standards, such as SAML (a standard for exchanging user information with a focus on authentication, authorization, and user attributes). Now, when a user comes to book hotels, the application will request information if he/she is not already based on ticketing, and if so, it will automatically create an account for the user. At the same time, it will pre-populate the booking form for his arrival date as the user’s information travels between servers.

This solution concept is referred to as domain federation and does not necessarily end with two servers. Thus, in the example mentioned above, a car rental site, a sightseeing site, and other themed sites can be added to the circle of trust within the federation for a better user experience when traveling.

Figure 2 – Federation

BYOID

Translated as “Bring Your Own Identity”, this term refers to a situation where a user logs into an information system or service with an identity that they have established with another identity provider. In practice, this term is used, for example, in recruitment, where candidates log in to the HR portal using, for example, Facebook, or to increase customer convenience on a company’s customer portal, where customers avoid having to register if they use, for example, a Google or Microsoft account.

Security aspect

As the last chapter of access control, we will look at the security aspect. We have shown that we have the ability to link different services with a single sign-on, which provides user convenience, but on the other hand increases the risk of misuse. What if someone steals a user’s identity at the identity provider? He then suddenly has access to many other services because of SSO. As we mentioned with multi-factor authentication, we can counter this by letting the user enter additional authentication credentials – password, fingerprint, code from a hardware token, PIN, one-time password from a generator, and in addition limit the user’s login to, say, 3 hours. All this increases security. However, if we let, for example, a privileged user enter three login factors over and over again every three hours, we get a securely logged-in but clumsy administrator.

This is what the relatively new RAdAC standard tries to prevent.

RAdAC

Risk-Adaptive Access Control, or RAdAC, is an advanced access control model. Here, the authorization decision (granting or denying a request for access to a system or service) depends on a dynamic risk assessment. This risk assessment not only decides whether to allow the user to access the system but also under what conditions this will happen – how the user will authenticate, what parameters such as time constraints will be used to access the resource, and so on. RAdAC can thus be used to manage privileges efficiently and securely. It is technically complemented by an implementation using the XACML protocol.

Example of RAdAC usage: in a local network environment, an administrator is allowed to log in to the information system using a name and password. However, if accessed from an external environment or outside working hours, two-factor authentication is required. In addition, when accessed from outside the local network, the validity of his authentication is limited to 3 hours.

With this, we have covered some important points of access control, or access management, in a nutshell. An associated area is the management of access to Linux or Unix servers using SSH keys or key distribution management.

Key distribution management

The following image illustrates what such a login using an SSH key looks like. Because this is often how users with administrative privileges log in to the server console, we are talking about the privileged account area here.

Figure 3 – Understanding SSH Key Login

The privileged user has been given a pre-generated pair of keys – a private and a public part. Anyone can use the public part to encrypt a message, which can then only be read (decrypted) using the private part. This principle is used when logging on to the servers mentioned above, where the server encrypts the connection data using the public part of the user. The user no longer needs to know his password, he just needs to have his private key (which is usually also protected by a password called passphrase, so he can avoid entering it altogether).

To achieve this, the public parts of the key need to be distributed to the servers where the user is to have access. And then delete them again if we want to deny the user further access. And this is the job of the key distribution manager, or key distribution manager.

How such a tool can work and significantly increase the security of privileged users’ work, we will show on the example of an actual product. At its heart is the KDM server, which is used for the actual distribution of SSH keys and initial authentication of users. The solution uses three-factor authentication (we have discussed it in this paper):

• something the user knows (the password to the private key, or passphrase, and the password to the account on the KDM server),
• something that is his own (the private part of the SSH key)
• and something that he cannot know (the private part of the second SSH key he receives from the KDM server).

Here the user needs to know his login credentials (name, password) to successfully log in – step 1. The private part of his SSH key is in his possession, the public part has already been uploaded to the KDM server so that it can be distributed to the target servers.

Figure 4 – Key Distribution Manager, Principle

The KDM server will generate a new SSH authentication key pair – a private and a public part. It sends the private part to the user (step 2) and uploads both public parts (the user’s and the newly generated one) to the target server (step 3). The private parts are thus stored with the user securely in the authentication agent from which the SSH client takes this information. Now, every time the user wants to access the target server, authentication is performed using both private parts of the SSH authentication key (step 4).

The connection to Identity Manager is easy – the decision whether or not the KDM server issues a new SSH key pair for the (privileged) user is based on whether or not the user has been assigned the appropriate role in Identity Manager.

Conclusion

In today’s fourth instalment of the series, we covered two areas: access management, which is closely related to identity management, and managing SSH key distribution for Linux users. Thus, we have learned about user authentication and authorization, single sign-on and sign-off – SSO, solutions for sharing identities between peer systems – federation and the related BYOID, and the security risks of access management along with the solution in the form of the RAdAC standard.

We will wrap up the series in the next instalment. First, we’ll look at selected Cyberlaw requirements that can be implemented using identity and access management tools, and ISO 27001. We will then look at technical solutions for Identity Manager – what options the market offers for implementation and how to navigate them.

Author: Petr Gašparík