Authentication establishes who a caller is. Authorization determines which resources that caller may access. For an engineering platform, the hard part is not simply signing developers in; it is giving them the right access across many tools and infrastructure capabilities without making them request each permission separately. section 4.3.3 section 8.5
Make the development team the primary authorization unit. Onboard a team once, let its members manage membership, and use that membership to grant access within the team’s platform boundaries. This turns a recurring access-request process into part of the platform’s self-service experience. Individual users still authenticate, but their team membership determines their platform access. section 7.3.1 section 8.5
Separate the identity and access decisions before integrating every system:
- Use a corporate identity source or single sign-on integration to authenticate users. Do not assume that authenticating someone also establishes every permission they need. section 7.3.1 section 8.5
- Choose where teams and membership are maintained. GitHub teams are one option when developers can manage their membership there; a platform teams API can instead maintain an authoritative customer-team database. section 7.3.1 section 8.5
- Connect each resource to that team model. Use a tool’s native team integration where available, and add synchronization for tools that lack it. Keep platform infrastructure access in scope, not just SaaS access. section 7.3.1 section 8.5
From sign-in to platform access
One implementation uses GitHub for team membership and an identity-provider integration for the control plane. After authentication, the integration obtains the user’s GitHub teams and returns a secure means of accessing infrastructure or custom APIs. CircleCI can connect permissions directly to GitHub teams; other tools may need a custom synchronization API. As the platform grows, a teams API can maintain cluster RoleBindings and publish team-sync events for other integrations. section 7.3.1 section 8.5
Figure 7.8 For Epetech, we would like our IDP service to have built-in or easily configurable means of integrating with GitHub, requiring authentication through whatever means we have set up in GitHub. As a result of (1) successful authentication, we want the IDP to (2) get the list of all teams the user is a member of in our GitHub organization. Finally, we want to (3) return to the user a secure means of accessing the platform infrastructure or custom API resources.
The flow shows the boundary between authenticating a user, retrieving team membership, and providing access to platform resources. section 7.3.1
Start with the membership source and integrations that support self-service now, then add adapters as platform capabilities expand. Check the result from a developer’s perspective: joining a team should provide the access needed for that team’s work, without a sequence of separate requests. Detailed identity-provider configuration and implementation examples depend on the chosen systems. section 7.3.1 section 8.5
