liveBook · Manning

Identity provider

As explained in Effective Platform Engineering

An identity provider is a system that authenticates entities and supplies identity or authorization information to relying applications and services.

An identity provider (IDP) connects authentication to the identity and authorization information that platform services need. For an engineering platform, it should act as a secure intermediary, not the sole source of truth: other systems can authenticate users and maintain team membership, while the IDP assembles the claims needed to access platform resources. section 4.3.3

Keep platform customer identity separate from cloud infrastructure identity. Developers should reach infrastructure through the platform control plane; the platform provisions resources for their teams rather than handing developers broad cloud permissions. The useful default permission boundary is team membership: adding someone to a team should give them access to that team's platform and developer resources without a series of manual requests. section 4.4 section 4.3.3

An incremental integration pattern is:

  • Use corporate single sign-on to authenticate users, then choose where teams can manage membership. GitHub teams are one option when the development tool already provides a self-service experience. section 7.3.1
  • Connect tools to that membership information where possible. CircleCI can use GitHub team permissions; tools without native support may need an API that synchronizes membership. section 7.3.1
  • Configure the IDP to obtain team information after authentication and issue verifiable credentials for platform infrastructure and custom APIs. Manage production IDP configuration in code. section 7.3.1 section 7.3.2

Accessing team resources from a terminal

A developer starts a CLI login from a laptop. Because a terminal cannot handle the whole browser interaction, the flow uses OAuth 2.0 device authorization. The developer authenticates through GitHub and authorizes the device. The IDP retrieves the developer's GitHub organization teams and creates a verifiable JSON Web Token with team membership as a claim. The CLI can then obtain credentials for platform resources. Auth0 is one SaaS IDP option for this setup. section 7.3.2 section 7.5

Figure 7.9 In this authentication and authorization flow, the IDP acts just as a secure go-between. The user must authenticate through GitHub and grant their device authorization to receive a JSON Web Token.
A screenshot of a computer

AI-generated content may be incorrect.

Follow the handoff between GitHub authentication, device authorization and IDP-issued credentials; the IDP is the go-between, not the authentication source. section 7.3.2

Single sign-on is a starting point, not the whole onboarding system. Automate the remaining integrations so a team can manage membership once and receive consistent access across its tools and platform resources. section 4.4 section 7.3.1

How Effective Platform Engineering covers it

How deep it goes
Explains the intermediary design and a device-authorization flow, but defers a complete comparison of membership implementations.
Examples
Uses GitHub teams, CircleCI permissions, an Auth0 configuration exercise and a CLI device-login flow.
What it assumes
Assumes familiarity with development tools and infrastructure access while explaining why terminals need a device-authorization flow.
What you can do after
Operate/configure it by connecting authentication to team claims and issuing credentials for CLI access to platform resources.
How it connects
Links single sign-on, role-based access control, team membership, OAuth 2.0, OpenID Connect and the Kubernetes control plane.

Also explained in

Compare how 12 books explain identity provider →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Effective Platform Engineering. The section links point to the parts of the book it draws on.