Distributed Application Architecture Patterns

9.1 Identity provider & Federated Identity

Centralise authentication to reduce the attack surface

This pattern is based on Identity Provider by Delessy et al. [150] and Rotem-Gal-Oz [13, p. 91], Federated Identity by Delessy et al. [150] and Microsoft [151], and Access Token by Richardson [20, p. 354, 152].

9.1.1 Context

Services need to verify the authorisation of requests. Implementing this in each service can lead to the following problems, each decreasing the system’s security.

  1. Code duplication increases the attack surface, as each service needs to implement the same logic

  2. Users may need to manage multiple identities, which reduces usability and increases password fatigue1

  3. Added complexity in user management and access control leads to more potential security vulnerabilities

9.1.2 Solution

Implement or employ an Identity Provider to centralise authentication and authorisation. Once a user is authenticated, the identity provider issues an access token that can be used to verify the user’s identity or more granular permissions (see fig. 25). This token can be either:

  1. Opaque – to verify the authenticity of the token, the service must query the identity provider to check the token’s validity

  2. Transparent – the token is cryptographically signed, allowing the service to verify the token’s authenticity independently

Figure 25: Identity Provider & Federated Identity

The client can retrieve the token from the identity provider directly, or a gateway can facilitate communication (see § 5.3). The identity provider can transitively trust other providers, allowing for single sign-on across multiple services (also called a federated identity).

9.1.3 Potential issues

Using a single identity provider can lead to a single point of failure, both in terms of security and availability. This risk can be lowered by using federated identity providers, but this, in turn, results in the trade-off of increasing the chance of failure and having to trust multiple, possibly external, providers.

Implementing authorisation in a gateway naively without tokens can lead to the Confused Deputy Problem. A Confused Deputy is a specific type of privilege escalation attack where an intermediary is tricked into performing actions on behalf of an attacker [156, 157]. This can happen as downstream services do not verify the authorisation of requests. Due to this implicit trust, an attacker would only need to trick a single service in a call chain to get access to unauthorised data. [3, p. 380]

9.1.4 Example

ExampleEshop offers an employee discount program. To access this program, employees need to log in using their company email address, but this account also needs to be tracked and terminated when the employee leaves the company. However, they do not want to store the whole employee identity database in the eshop, as this would introduce a security risk. Instead, they deploy two identity providers in a federation. The public and private parts of the system use their own providers, but the public one trusts the private one, which allows it access to the employee’s name, email and affiliation.

9.1.5 Further reading

  1. Password fatigue is a widely used term to describe the heavy cognitive load of managing multiple passwords resulting in relaxed security practices [153, 154, 155]↩︎