We're looking at ways to give our delivery teams a seamless integration between Concourse and some of our other workflow and deployment tools (the first of which is an instance of CloudFoundry).

As part of that, we'd like to make all authentication and authorization decisions outside of Concourse, and have it accept an assertion by our system that a user is logged in and permitted to access a given team.

For now we'd like to use CloudFoundry UAA as the authentication source, and we'd like to automatically provision a Concourse team for each CloudFoundry space.

Our proposal is to:

1. Add flags to atc that allow it to accept signed tokens minted by an external source in addition to its own signing key.
2. Add createTeamIfNotExists claim to a signed token, which atc will recognize and automatically provision a team if it doesn't exist.
3. Add emailAddress fields to claims, and have atc use this for any audit logging for actions taken by that user.
4. Add ability for fly command to accept target properties JSON from an environment variable, if no target is set on the command.

The objective of (1) is to be able to separate our authorization decisions from the CI system (which from a security point of view, is remote code execution as a service), so that users do not have to pass powerful credentials to Concourse (such as the cloud_controller.read UAA scope, which in addition to reading of space membership, also allows for reading of sensitive application credentials).

The objective of (2) is to simplify provisioning - avoid another system needing an admin account on Concourse to provision teams, and creation of tooling to keep these in sync with CF.

The objective of (3) is self-explanatory.

The objective of (4) is to allow creating of a cf CLI plugin so that fly can be invoked by our delivery teams as easily as cf fly pipelines where our plugin will automatically perform an SSO dance based on the current cf target the result of which is a JWT that is ready to be sent directly as an Authorization header to atc.

We have a prototype of this working in our environment, and we'd like to see how much of this would be useful to rest of the community.

Creating this issue to tie together a number of pull requests that I'll begin submitting for consideration. I'll also add links to the source for the cf plugin and authorization server as can show how it all ties together.