Identity & Access Management (IAM)Authentication

The Fundamentals of IAM Authentication

A definition of authentication is “the process of proving that something is real, true, or what people say it is”. 

Given the first word in IAM is Identity, the process of proving that the identity is real is probably the most importing and fundamental of  all of the five pillars of IAM. Without this accurate verification all of the other pillars are on very shaky foundations.

We are all familiar with the process of authentication by having to login to nearly every application, infrastructure, resource just verify who you are.  Most people would assume that authentication in IAM terms is simply “login”.  In other words, authentication is simply the process of managing the login. However, that definition too simplistic and misses out a great deal of required functionality, security and good user experience that a robust IAM solution must provide.

The Components of Authentication

In the old days, when chocolate bars were as big as your hands, proving who you were was simply a matter of entering the correct username and password.

Despite many reports and articles from many marketing departments, passwords have not gone away, they still form a key part of Identity Management. As a result, password management is essential.

Thankfully this functionality was built into most applications and directories decades ago. However, policies around this do still need to be considered.

These passwords policies often stated that passwords need to be modified frequently by users, Help Desks become overrun with forgotten passwords tickets. This has lead to Self Service Password Reset (SSPR) capability being vitally important, especially in larger organisations.

Now unless you have been living on an island cut off from the rest of the world, we know that passwords alone are not safe enough. Therefore, Multi Factor Authentication (MFA) plays a vital role in ensuring we have greater assurance in the user is genuine.

Modern authentication systems will consider different attributes of the authentication request to provide clues about the authenticity. For example, location, time of day, device used, browser etc can all be used to an extra degree of confidence in the authentication process.

To mitigate the number of passwords Single Sign On (and not forgetting its smaller cousin Single Sign Off) became a thing. This provides the user with the ability to authenticate once and then for a period of time, do not have to re-authenticate to use an application.

To sum up the pillar of authentication consists of the following functionality

  • Password Management
  • Multi Factor Authentication
  • Self Service Password Reset
  • Attribute based Authentication
  • Single Sign On

Password Management

The hip and trendy amongst the readers are probably going “Oh I just use Passwordless authentication, password management is so retro.” (More on Passwordless later).

The flaw with this statement is that passwords still exist. Nearly every application will require a password at some form during its lifecycle. For example, try creating an account anywhere without using a password. There may be the odd exception, but a password is required.

Therefore, we are talking about the same password vulnerabilities i.e complexity and duplication which ultimately lead to poor security.

The common answer is to use Multi Factor Authentication (MFA) which should improve the security. This is certainly true, but MFA Bypass hacks are prevalent and perhaps additional belts and braces should be required.

As passwords cannot be avoided, an IAM solution should have something to manage the passwords. Firstly, is a policy to ensure passwords are rotated regularly and are of sufficient complexity. A word of caution here, many identity stores, e.g Active Directory, provide a password policy and change solution, but the reach of the password change is often very limited. This can lead to a vulnerability in end systems where the password change didn’t happen. The advice here is to ensure that password policies apply to all systems.

Enforcing rotating and complicated passwords onto users does lead to a poor user experience, with many users becoming frustrated and then swamping help desks with requests to reset passwords.

The best approach to keep your users happy is to provide a password manager that stores and autofill the passwords for many applications.

Self Service Password Reset

The swamping of Help Desk to request a password reset and its associated cost is the most common marketing ploy used by many vendors to push their tools.

Even if you don’t believe the near $70 per ticket cost, the downtime and cost of Help Desk personnel does mount up.

The SSPR tool though should be considered more than just a way of reducing the stress of the IT team (which is always a good thing) but it does help with the end user experience. It makes them self-sufficient even if some communication is required to tell them that they need to be self-sufficient. In other words don’t forget to say tell users that there is an SSPR tool.

The SSPR tool, if implemented properly, can have an important security impact especially when tied to a strong password policy. If the tool is connected to a number (ideally all) applications and end-points then it can help improve the security of the password as it reduces the likelihood of old passwords and potentially compromised passwords still being in use.

Multi Factor Authentication

It should be universally accepted that relying just on passwords is extremely bad. It is that something you know which other people can know also. Those other people can be not very nice people and look to steal your data or charge you lots of money not to steal your data.

The best approach is to have additional forms of authentication that between them will give a greater assurance of someone being real and the genuine article. Those forms should be ideally of different levels of factor.

Simply put the different levels are

  • Something you know (weakest)
  • Something you have (mobile phone typically)
  • Something you are (biometric)
  • Where you are (location)

IAM Aware readers may be a little surprised by location, or would only consider it as part of conditional access polices. However, if you think about it, it has been around since the very beginning of computers. The location factor in those days was the office. Computers weren’t necessarily connected to an external network and therefore the office location was an implicit factor. That is true in modern times. If a device or application is 100% certain to be accessed from a set location, then password will often suffice. The additional security is implied by the security from entering the building.

In a remote context, it is hard to guarantee that the location is correct. IP Addresses and GPS data can be spoofed by a determined hacker.

A good IAM solution will ensure that every user will be using multiple forms of authentication and those forms are of suitable strength given the user and the application.

Attribute Based Authentication

There are many terms for this such as dynamic authentication, step up/down, conditional policies, every vendor has there own unique term. They all mean the same thing though, that is taken into account different attributes of the authentication request.

For example, device, time, location, browser, previous behaviour etc. The list can be quite long. The pedantic may argue that this should be under the authorisation pillar (i.e is the user allowed to access the system at this time, from this location, from this device). That is certainly true, but these additional factors should be considered whether they themselves are authenticate. For example, if the policy of restricting access by device is used then there needs to be a means of identifying that device. Not every factor will need to be validated, e.g time of day, but a large number will.

However, these additional attributes will greatly increase the security of the authentication process.

The topic of conditional access will be discussed in the sister blog on Authorisation.

Single Sign On

Single Sign On is probably a strange one to have under authentication. Typically, this is the preserve of the Access Management products and therefore part of the authorisation pillar.

That is certainly true, but the technology employed by this products improve authentication in different ways.

Firstly, not every application or system has out of the box functionality for MFA or supports a range of authentication processes. Often applications will trust that a user has been authenticated on another system. By offloading the authentication process, different authentication processes than those supported by the client application can be used.

This is known as federation.

From a user’s perspective this is a good thing as it is likely that they don’t have to login in multiple times (hence the name single sign on). Whilst that is true, consideration has to be given about how often a user should be asked to revalidate who they are.

A note on Passwordless

As promised earlier, let’s take a look at passwordless authentication. Passwordless authentication is certainly a good thing as it does remove the weakness of passwords. However often a passwordless solution will only use a single factor to validate the user (e.g fingerprint, face etc). This is an improvement, but it would be better to have multiple forms of authentication.

As stated earlier, try creating an account without using a password. The password is weak and often is used as a point of attack.

Another issue is that many implementations of passwordless have a backdoor route in which a user can press the escape key and enter a pin number or password. In this case the passwordless implementation merely provides a better user experience rather than improving security.

Being completely passwordless is a difficult thing to do, therefore password management and MFA should still be necessary.

Summary

This article hasn’t gone into detail about which products an organisation might need to have a robust authentication solution. The answer to that question is why there is a such a large industry around IAM.

The article is merely trying to focus on the functionality required to have full confidence that the person attempting to sign in is genuine whilst not trying to torture them to prove so.

Traditional means would have been username and passwords. Whilst passwords are inherently weak things such as MFA and attribute authentication can help with the security.

Trying to remove passwords completely is the Holy Grail but is still very difficult to achieve. Therefore, policies and functionality should be used to manage passwords. User experience can be improved Self Service Password Resets to remove the burden on the IT Help Desk especially when forcing users to rotate passwords frequently.

Single Sign On also has been a great addition to the authentication process by improving the user experience and augmenting the capabilities of the end application.

With the user and by association their digital identity being fundamental to everything in IAM it is worth taking the time to ensure everything is in order and not to take age old practices or even fancy new ones for granted.

Need Help Finding The Right Solution?

If you're looking to strengthen your user security framework, we're here to help. Contact us today to discover how our solutions can protect your organisation.