Introduction
Identity and Access Management (often shortened as IAM or IdM) consists of the set of frameworks, policies and practices that ensure the correct users have access to the right resources in a given system or collection of systems. Almost any system with multiple users will benefit from or require IAM, even more so systems that need limited access to certain parts, actions or resources.
IAM typically comprises two parts, the identity (or authentication, sometimes shortened authn) and access control (or authorisation, sometimes shortened authz). Authentication responds to the question of ‘who?’ and refers to the process used to identify a specific user (for example, using a username and password combination), and authorisation answers the question of ‘is this allowed?’ and represents the policies that determine whether someone may perform a specific action or access a particular resource.
Consider a simple message board system used for internal announcements within an organisation. The identity part of IAM may be fulfilled by prompting users (likely employees) for a username and password. Once users log in, they may have different roles, which define how to interact with the system and determine the access control part. For example, users may be divided into viewers (who can only read posted announcements), editors (who can read announcements as well as publish new announcements and edit and delete existing ones) and administrators (who can do all that editors can do as well as change the role assigned to other users).
Why IAM is important
Imagine a scenario where a company has a database of its clients’ details, including personal and financial information. If that database falls into the wrong hands, it could spell disaster for the company and its clients. For instance, the attackers could use the information to commit fraud, tarnish the company’s reputation, or cause financial loss. This is where IAM comes in; it helps prevent such scenarios by ensuring that only the right individuals can access the system and its resources.
IAM achieves this by identifying users and their roles, authenticating their identity, and authorising them to access resources and services that are relevant to their roles. It is important to note that IAM is not only about security but also helps maintain compliance, reduce risk, and increase productivity.
Because IAM plays such a central role in systems and organisations, implementing them correctly and efficaciously can be incredibly challenging, commanding specialist skillsets, a deep understanding of the business domain, best security practices and intimate knowledge of the systems.
Authentication
Authentication is the process of verifying the identity of a user before granting access to a system. The identity could be validated using various methods.
Authentication methods
Username and password
Passwords are by far the most common method of authentication, where the user provides a unique username and a password, and these credentials are then validated against the system’s records.
Username and password is a common authentication method for many applications. For example, it is the default method for establishing a session in many operating systems, as shown in this Windows Server 2003 log-on prompt.
This method is the most widely used authentication method due to its low entry barrier, ease of implementation, and convenience for users, as passwords are straightforward to use, do not require any additional hardware or software and can be easily changed if needed.
However, the use of password authentication has several disadvantages. Passwords can be easily compromised through brute force attacks, where attackers use automated software to try numerous password combinations until they find the correct one. Users also tend to choose weak passwords, such as common words or easily-guessable patterns, which attackers can easily crack. Furthermore, users often reuse the same password across multiple accounts, which increases the risk of a security breach.
Moreover, several steps must be taken to prevent passwords from being compromised when implementing password authentication. These steps include using encrypted connections and other general good network and operation practices to prevent interception during transmission, rate-limiting to prevent guessing by attackers, and proper password storage methods like hashing and salting.
Magic links
This authentication method involves sending a one-time link to the user’s email address or phone number, which they then open to gain access. Magic links can be a more convenient authentication method, especially for users who may forget their passwords, and avoids the issue of password management. However, the link could be intercepted or forwarded to an unauthorised user. Thus an attacker could gain access to the system, making it a relatively weak authentication method.
Magic links are a relatively low-friction authentication method. A link is sent, typically by email or SMS, that when opened automatically signs the user on.
Cryptographic authentication
Cryptographic authentication is a passwordless authentication method that uses cryptography to establish trust between the user and the server. Traditionally, this is done with digital certificates, also known as client certificates, issued to users and stored on their devices. When the user attempts to access a resource, a cryptographic protocol is run between the server and the user, ensuring that the user is whom they claim to be and possesses the private key associated with the certificate.
Client certificates are a high-security authentication method that has seen relatively low adoption.
While cryptographic authentication has been used for a long time, it has been challenging to implement on a large scale because of the complexity of managing the necessary infrastructure. The administration of certificates, certificate revocation and key management can be difficult and time-consuming, leading to higher development and operation costs than other methods, such as passwords, and potential security risks.
Newer approaches, such as FIDO and WebAuthn, have addressed these challenges of cryptographic authentication by using methods that do not require that the verifying party operate or maintain their own key infrastructure. The private key is typically stored on a hardware device, such as a USB key or a TPM on the user’s device, and a cryptographic protocol is defined to allow servers to validate identities depending on these keys.
WebAuthn is a newer approach to cryptographic authentication that commonly uses operating system features and hardware keys to verify identity.
Multi-Factor Authentication (MFA)
Multi-Factor Authentication (MFA) requires users to provide more than one form of identification to access a system. Each form of identification is referred to as a factor and can fall under three categories: knowledge or something you know (e.g., a password), possession or something you have (e.g., a physical token or a mobile device) and inherence or something you are (e.g., biometric data like fingerprints).
MFA combines two or more of these factors to increase security. For example, a user may be required to enter a password (something they know) and use a physical token (something they have) to gain access to a system. Alternatively, users may be asked to use their fingerprint (something they are) and enter a one-time password (something they have) sent to their mobile phone.
Some common examples of MFA include biometric authentication (such as fingerprints or facial recognition), one-time passwords (OTP) sent via SMS or a mobile app, smart cards, physical tokens, and push notifications to a mobile device. Overall, MFA provides an extra layer of security that can significantly reduce the risk of unauthorised access to a system.
Using multiple factors makes it more difficult for attackers to gain unauthorised access to a system, even if they obtain one of the factors (such as a password). Some factors (e.g., cryptographic keys) additionally support phishing-resistant methods like scoped credentials. These are designed to work only on the intended system and cannot be used elsewhere, preventing phishing attacks where attackers attempt to trick users into providing their log-in credentials.
Implementation options
The implementation of authentication is application-dependent and varies based on business considerations. Three main methods to implement authentication are per-system authentication, dedicated authentication services, and Single Sign-On (SSO) and federated identity.
Per-system authentication
Per-system authentication is where applications manage their own authentication, authentication methods, and user database. This approach can be simpler for developers because it does not require knowledge of the application’s environment and is more straightforward for small organisations because no additional infrastructure is needed. However, it can be challenging to scale as it requires managing user databases across many systems and enforcing policies. Furthermore, users needing access to multiple systems may need help navigating this authentication method.
Dedicated authentication services
Dedicated authentication services are a popular method in which a centralised service is responsible for authenticating users, and various applications can delegate authentication to this service. This approach avoids the challenges of managing users centrally and ensuring consistent security practices across multiple applications, leading to a better experience both for system administrators and users. Additionally, using dedicated authentication services reduces the attack surface area that comes with individual applications needing to implement authentication.
Various dedicated authentication services are available, ranging from commercial options like Okta and Azure Active Directory to open-source solutions like Keycloak and FreeIPA. These services typically provide features such as multi-factor authentication, user management, and access controls and can integrate with various applications using standards like OpenID Connect and SAML 2.0.
Single Sign-On (SSO) and federated identity
Single Sign-On (SSO) and federated identity are similar and sometimes synonymous with dedicated authentication services. The difference is that SSO typically refers to the widespread use of a central authentication service within an organisation. On the other hand, a federated identity allows users to access systems across different organisations using a single set of credentials.
SSO and federated identity may be combined. For example, user management may be entirely outsourced (using an external provider with their own user database), and likewise, organisations may make their authentication service available to other external systems. An example is social media log-in, which allows independent services to delegate validation of users’ identities to a social media network.
These methods are more convenient for users since they only need to remember one set of credentials but they might require more infrastructure. However, the benefits of SSO and federated identity will typically greatly outweigh the additional infrastructure required, as they provide a better user experience and improve security.
Authorisation
Authorisation is the process of granting or denying access to a resource. It determines what a user can do or what resources they can access once they have been authenticated and plays a critical role in securing resources and ensuring that only authorised parties have access to sensitive information or functionality.
Authorisation strategies
As for authentication, there are several ways to implement authorisation, and the best strategy is highly contextual, depending on the environment, business needs and nature of the systems in question. Some of the more common strategies are discussed below.
Role-Based Access Control (RBAC)
Role-Based Access Control (RBAC) is a widely used authorisation strategy that involves assigning roles to users based on their responsibilities or job functions. Each role is associated with a set of permissions that define what resources a user can access or what actions they can perform. This approach is particularly useful in organisations with many users because it simplifies management and scalability.
For example, consider a curling club management application that has different roles, such as players, coaches, and administrators. Players can view their team’s schedules and update their availability for upcoming games, while coaches can also view player statistics and performance metrics. Administrators can manage user accounts but cannot access player-specific data or modify game results. Using RBAC, the application can ensure that each user can access only the information and functions relevant to their role within the club.
Policy-Based Access Control (PBAC)
Policy-Based Access Control (PBAC) is an authorisation strategy that uses policies to govern access. Policies are rules that define what actions a user can perform based on their attributes, such as job title, department, or location. This approach provides greater granularity than RBAC and offers more flexibility. However, it can be more complex to manage.
A travel agency could use PBAC to control access to their booking system. For instance, they could have policies such as ‘Only travel agents with a certain level of certification can book international flights’ or ‘Only users in the sales department can offer discounts to customers’.
Attribute-Based Access Control (ABAC)
Attribute-Based Access Control (ABAC) is an authorisation strategy that uses attributes to determine access. Attributes can be any characteristic that can be used to identify users, such as user role, job title, department, location, time of day, and more. ABAC is highly flexible and can accommodate complex environments and scenarios, making it a popular choice for many organisations.
For instance, consider a tattoo parlour that uses ABAC to grant access to its online booking system. The system may allow customers with a minimum age of 18 years and those with valid identification to book an appointment.
Context-Aware Access Control (CAAC)
Context-Aware Access Control is an authorisation strategy that uses various contextual factors to grant or deny access to resources. The factors may include the user’s location, device, network, time of day, and activity history. By considering these contextual factors, the system can detect anomalous user behaviour and prevent potential cyber-attacks or data breaches. This strategy is often used with machine learning to help identify unlikely behaviours or represent high-risk scenarios.
For example, a grocery store might use context-aware access control to prevent unauthorised access to sensitive information and protect the store’s business operations by ensuring that only authorised personnel can access the inventory management system. The system may allow employees to access the system only during business hours, from the store’s Wi-Fi network, using a company-issued device. If an employee tries to access the system from outside the store or at an unusual time, the system can deny access or trigger an additional authentication step, such as a one-time password or biometric verification.
Access Control Lists (ACLs)
Access Control Lists (ACLs) are a commonly used authorisation strategy in which a list of users and the resources they are allowed to access is created. ACLs are typically applied to individual files or directories in a system, making them effective in managing access to specific resources rather than entire systems. This approach is well-suited for small-scale organisations where access to resources is limited to a few users or groups of users.
ACLs are often used for individual files or directories in a system.
For instance, ACLs can be applied to patient records to control access in a doctor’s practice to ensure that only authorised personnel have access to patient information, which is critical in maintaining patient confidentiality and complying with legal regulations. The doctor, nurses and receptionist may have different access levels, with the attending doctor having full access, other doctors having read-only access, the nurses having access to certain information, and the receptionist having no access.
Implementing authorisation
After choosing an authorisation strategy, the next step is implementing it in the relevant systems.
Similar to authentication, authorisation can be handled internally by each application through internal rules, or it can be delegated to an external service, which may be internally managed or outsourced.
Implementing authorisation can be complex, particularly in large and distributed systems. It requires careful consideration of the system’s security requirements, as well as the needs of the users and applications that will be accessing the system.
Internal rules
One approach to implementing authorisation in an application is by using internal rules. This method involves creating rules directly within the application and determining which users are granted access to specific resources. This approach suits small organisations with limited resources or simple systems requiring less infrastructure. However, as the size and complexity of an organisation’s IT environment grow, the management of internal rules becomes increasingly complex, time-consuming, and error-prone.
While the benefits of implementing internal rules include simplified management and implementation without needing external services, there are drawbacks. The risk of inconsistent or poorly enforced internal rules is a significant concern that can lead to security vulnerabilities. As such, organisations need to periodically review and update their internal practices to ensure that they align with the organisation’s security needs.
Examples of internal rules include row-based security, which restricts access to specific rows within a database, and ‘Gates’ in frameworks like Laravel, which enable developers to define custom authorisation logic.
Delegated authorisation
Delegated authorisation is the practice of delegating authorisation decisions to a purpose-built authorisation server rather than having each application manage its own rules. This server administers and enforces authorisation policies across multiple applications, services, and resources.
When applications require access to protected resources or data, they must request authorisation from the server. The server evaluates the request based on the authorisation policies in place, and either approves or denies it. This approach simplifies the management of authorisation policies across multiple applications and provides a centralised point of control and visibility over access to resources.
Delegated authorisation also helps enforce a zero-trust security model, where all access requests must be authenticated and authorised, regardless of the user, application or request origin. Zero-trust models can, in turn, reduce the risk of data breaches and other security incidents.
Examples of delegated authorisation protocols include OAuth 2.0 and SAML 2.0. These widely adopted protocols provide a framework for delegating authorisation decisions to an external server.
Delegation authorisation patterns
API gateways are an example of a pattern that can manage authorisation. Acting as a layer between the user and the application, an API gateway handles both authentication and authorisation. API gateways can control access to specific resources within an application or multiple applications. Examples of such services include Kong Gateway and Apache APISIX.
Query-based services are another example of a pattern for managing authorisation. These offer a service that applications can query to determine whether to allow or block access to a resource or operation. An example of this approach is using ORY Keto, an implementation of Google Zanzibar.
Conclusion
In conclusion, Identity and Access Management (IAM) is a crucial aspect of modern business operations. IAM ensures that the correct users have access to the right resources, which is essential for security, compliance, and productivity. There are many different authentication and authorisation strategies, each with its benefits and drawbacks. Organisations must carefully choose the strategy that best fits their needs and implement them correctly to maximise effectiveness. Implementing IAM can improve an organisation’s security posture, reduce the risk of data breaches, and increase operational efficiency by supporting business needs.
Top comments (0)