I think therefore IAM: It's not cool, it's not sexy, but it's one of the most important and difficult areas in modern IT

Feature A search on LinkedIn's UK job site just now (1 June 2021) returned 5,265 roles for a network manager; 2,204 for a system administrator; 4,964 for a web developer; and 10,776 for a business analyst. None of these are a particular surprise – they're popular, sought-after careers.

Oh, and there were 1,522 results for "Identity and Access Management" (IAM).

What do you want to be when you grow up?

When, as an IT student, you consider in which field you want to make a career, there are some common choices. Web developer, database administrator, software developer, system manager, network engineer... or more recently something in machine learning (ML), artificial intelligence (AI), quantum computing or cybersecurity.

This is because they are the areas you are taught as a student. Examining the course details of 10 top UK universities' computer science courses reveals a high degree of commonality: systems development, web programming, database systems, data science, AI, cyber security, advanced networking, algorithms, data structures, cryptography, ML, graphics, the list goes on.

If you get the bug for, say, web development, at uni, a career as a web developer is going to be high on the list at graduation. And since not a single one of the universities this correspondent looked at has a course module covering IAM, there's little chance of us turning up at careers fairs desperate to talk to potential employers about access management.

Simple in the simple cases…

IAM is relatively simple in small, new organisations. This is because if we're starting from nothing, we can begin with a core directory service – generally Microsoft's Active Directory (AD) – and build everything with Single Sign-On (SSO). This means we can authenticate to AD either natively or via well-understood protocols such as Active Directory Federation Services (ADFS) or the Lightweight Directory Access Protocol (LDAP).

We have the luxury of insisting that any new service we take on must integrate to the directory service, and that nothing is permitted to have its own internal authentication database except perhaps for specific administrative logins (particularly last-resort admin logins for use when the directory integration is being set up or has broken).

… But it gets very complicated, very quickly

Even in a modestly complex organisation, though, one could argue that IAM is not only one of the most important IT and security tasks in the business, but also one of the most difficult. In such companies IAM is a significant job: in my 450-person day-job business, for example, there are two staff members who solely do IAM and others who also touch on it from time to time.

The average business has systems that authenticate in several ways, typically: (a) directly to the directory service, either natively or via LDAP/ADFS; (b) partially, so that the yes/no decision to permit access is controlled by the directory service but the app also has internal controls over each user's permissions; and (c) the system controls access entirely within its own user database.

Now, it is hopefully pretty obvious that the primary risk with IAM is a failure to de-provision system access when someone leaves the organisation. The process is fairly straightforward for systems where admission control is handled by the directory service, because ticking the "disabled" box in the control panel will instantly render all the connected applications inaccessible.

• Same old complexity beneath Windows 10 Cloud Config means it's unlikely to compete with the likes of Chrome OS
• This better not be a cruel prank: Microsoft promises 99.99% uptime for Azure Active Directory from 1 April
• Big Blue services enjoy a lie-in: IBM cloud gets the Monday blues and its customers won't have been happy either
• Five bag $300,000 in bug bounties after finding 55 security holes in Apple's web apps, IT infrastructure
• Move over, Alien vs. Predator: Signing into AWS with an Office 365 login is a real crossover

The difficulty comes with the applications that aren't linked to the directory. In some cases – where you host the apps on-premises or in your private data centre – you can at least take the approach of forcing users to log into your AD network before they're able to get into the application.

It's not perfect, but turning off the AD account prevents the user from accessing the app. In other cases, such as SaaS-based applications with no SSO link into your world, you can hopefully get the vendor to restrict access based on the IP address of the client machine – so again the user has to be connected and logged into something in your private network and you can keep them out of the application by turning off their AD login.

Knowing what to provision

We've established, then, that turning people's accounts off when they leave is a non-trivial thing. Equally tricky, for different reasons, is ensuring that people have the right access to the right things at any given time.

To provision the correct access in the first place, you need one of two things: either (a) fully defined Role Based Access Control (RBAC), in which each of the company's job descriptions is linked to a carefully crafted set of application and systems permissions; or (b) a regime in which "standard" permission sets are defined for most roles and there's a mechanism for getting deviations approved by the right authority. And you need to apply it rigorously.

Why is this tricky? Getting RBAC set up in the first place is a long, thankless task and keeping the definitions up to date is a non-trivial thing that needs focus and careful review. And the second option of the two relies on humans doing things, which means errors are inevitable.

Reviews and leavers

And now the hardest part – reviewing what access people have. The hardest question to answer in IAM is: "What applications does X have access to, and what permissions do they have within those applications?"

Imagine a user has just left the business, and you have to deprovision them. Easy, you think: just look in the records for what they have been provisioned with, and take away that access. But no, all it takes is one mistake – one failure to record a change – and your records are instantly invalid. The only reliable way to establish the facts you need are to look in the applications... which means every application for every leaving user. This may sound overkill, until the moment the auditors come along and point out a deprovisioning failure in an app in which you weren't expecting to see a user ID for that person.

Not only this, but you should be doing regular reviews of all your users as a quality check to make sure you've not missed anything (preferably before the aforementioned auditors point your mistakes out to you). Cue lots of manual effort, lots of spreadsheets, lots of Excel VLOOKUPs mapping application user IDs onto HR staff lists. I've seen it done and it's not pretty – you can be looking at months of aggro for just a couple of dozen applications, especially when you bear in mind that if issues are found you have to correct them and then repeat the exercise until the results are spot on. There's no application on the market that eases this task for you, so you either live with a terribly manual task or do what you can with scripts, spreadsheets, macros, screen-scrapers and the like to remove at least some of the monotony.

Skills like a mental octopus

An effective IAM specialist, then, needs to understand applications, design procedures, analyse, agree and write RBAC definitions, police the IAM fulfilment process, produce reports despite there being no off-the-shelf reporting solution, carry out reviews, address inconsistencies and verify the remediation work, interface with and provide data to auditors... alongside an ongoing regime of continuous improvement.

Why, then, does the IAM workload land so often on the Level 1 helpdesk team?

IAM as a skillset

Let us look back at our university course modules from earlier: systems development, database systems, web development, cybersecurity, algorithms, data structures, data science. These are all skills that can be applied in IAM – whether it's for automating the provisioning and deprovisioning of user access to systems (hence reducing the risk of human error), scripting the extraction of access data from applications for reporting, building a relational database for that data to live in so it's easy to query in a reporting tool, devising algorithms for calculating whether a user's login has lain unused for too long.

These are all complex skills, and it is a mistake not to have staff of a sufficient skill level in sufficient numbers to do the job thoroughly and correctly. Of course, there will be tasks that the more junior team members are able to carry out as they gradually develop their experience, knowledge and skills, but IAM is more than just a business-as-usual activity. It needs senior, competent, strategically thinking specialists who understand not just these technological elements but also related subjects such as business risk along with soft skills such as communication and persuasion that they can use to encourage those fulfilling IAM requests to do so robustly and explain to the business users why it's important to be following what might seem to be slightly nebulous procedures involving requests, checks and approvals.

Employers: don't under-skill your IAM function, then, or it'll end in tears through failed audits or exploitation of vulnerabilities caused by poor access provisioning and deprovisioning. And for those of you reading this who are at the beginning of your careers, or who are reading The Reg in your university residences when you should really be doing your Prolog assignment (and yes, one of the courses I looked at has a module titled "Introduction to Prolog"), don't just look at one of the subjects you've studied and decide on it as a career. What you learn across the breadth of your course could come together to set you up for a career in IAM... and a fiver says there will be a lower applicants-per-role count for those 1,522 roles than for the others mentioned. ®