Home > Design Patterns > Brokered Authentication
Brokered Authentication

Brokered Authentication (Hogg, Smith, Chong, Hollander, Kozaczynski, Brader, Delgado, Taylor, Wall, Slater, Imran, Cibraro, Cunningham)

How can a service efficiently verify consumer credentials if the consumer and service do not trust each other or if the consumer requires access to multiple services?

Problem

Requiring the use of Direct Authentication can be impractical or even impossible when consumers and services do not trust each other or when consumers are required to access multiple services as part of the same runtime activity.

Solution

An authentication broker with a centralized identity store assumes the responsibility for authenticating the consumer and issuing a token that the consumer can use to access the service.

Application

An authentication broker product introduced into the inventory architecture carries out the intermediary authentication and issuance of temporary credentials using technologies such as X.509 certificates or Kerberos, SAML, or SecPAL tokens.

Impacts

This pattern can establish a potential single point of failure and a central breach point that, if compromised, could jeopardize an entire service inventory.

Architecture

Inventory, Composition, Service
Brokered Authentication: The consumer submits a request with credentials to the authentication broker (1), which the broker authenticates against a central identity store (2). The broker then responds with a token (3) that the consumer can use to access Services A, B, and C (4), none of which require their own identity store.

The consumer submits a request with credentials to the authentication broker (1), which the broker authenticates against a central identity store (2). The broker then responds with a token (3) that the consumer can use to access Services A, B, and C (4), none of which require their own identity store.