Concourse CI
Published in

Concourse CI

Oh, Auth

As most of you know we’ve been working hard on introducing Users into Concourse. Today, I’m excited to share with you some of the changes we’ve made for an upcoming release of Concourse.

In the old world, you used to log in as a team:

Now you log in as a user:

You can do this using external auth providers:

Or logging in as a local Concourse user:

How did we manage to accomplish this magic? With the power of dex!

In this new model:

  • We rely on dex to fetch the user’s identity and group affiliations from the external auth provider.
  • We then take this information and cross reference against all Concourse teams to establish team memberships for the user.
  • Team owners can whitelist external users and groups with the fly set-team command.

What this doesn’t fix:

  • We still don’t have an easy way for people to identify what users/groups are currently whitelisted for a team. This should be something that we can add to the fly teams command in the future (PRs welcome), but in the mean time you can always check the database ;).
  • We also aren’t implementing auditing or RBAC just yet…

…but its a good start!

Now, let’s dive into some of the technical changes that might affect your continuous thing doing.

ATC Startup

When you start up the ATC you will need to provide configuration information (i.e. client_id, client_secret, etc.) for ALL auth providers that you want to use. Up to this point, each team would have to configure their own providers, now the startup information will be shared across teams.

If you want to use the GitHub provider, you will need to provide:

atc ...
--github-client-id client-123
--github-client-secret 1234567890
--main-team-github-group my-org:my-team

Note that the configuration of the main team is slightly different now too.

Fly Set Team

Since providers are now configured at startup, the fly set-team command has gotten a whole lot simpler.

You used to configure teams with all the provider information:

fly ...
--github-auth-client-id client-123
--github-auth-client-secret 1234567890
--github-auth-user my-github-login
--github-auth-team my-org/my-team ← Note the slash “/”

Now you simply whitelist a bunch of users and groups:

fly ...
--github-user my-github-login
--github-team my-org:my-team ← Note the colon “:”

Yeah, sorry we changed the delimiter from a slash to a colon, but that’s what dex uses, so we went with it.

Bearer Tokens

We’ve updated our bearer tokens to include the user’s identity and ALL their team memberships. Including their identity will enable us to do auditing down the road. And having multiple teams in the token lets us update our APIs to return a list of ALL resources visible to a user, not just those for a specific team.

So the decoded token used to look like this:

“isAdmin”: true,
“teamName”: “main”

And now it looks like this:

“sub”: “CgcxMDcyMjMzEgZnaXRodWI”,
“is_admin”: true,
“email”: “”,
“name”: “Some User”,
“user_id”: “1072233”,
“user_name”: “my-github-login”,
“teams”: [“main”]

No Auth

In the past, you could use the--no-really-i-dont-want-any-authflag to disable auth for your team. This would allow access to anyone without having to provide credentials.

In the new world, you can’t do this. We don’t allow access without credentials, and teams can no longer be open to the public. You can, however, whitelist all authenticated users in the system using the --allow-all-users flag when setting up your team.

Fly Actions

The Fly experience does not change in our new auth system. You will still need to provide a target, which includes the team that you are operating under for team-specific actions (such as fly set-pipeline, etc.).

Exposed pipelines

The flow of setting and accessing exposed pipelines will remain unchanged. Exposed pipelines will still be visible to the public, and do not require a user to be logged in.

No provider left behind… sort of

For this track of work, we still need to implement some missing providers (dex calls them connectors) for external auth systems. We’re hoping to have feature parity with the old providers, but we want to understand your use cases for needing them first.

For example, Bitbucket Server may be problematic since it still relies on OAuth1. Now that we have more auth options (hey we have an LDAP connector now), would current BitBucket users be willing to switch over to something else? Let us know in GH issue #1888.


For those who want to get caught up on the discussion, you can check out the GitHub issues:

If you have any questions or concerns about the work that’s being done, feel free to drop a comment on those issues, or reach out to us on our usual channels.




The Continuous Thing Do-er

Recommended from Medium

How to Add a Default Value to an Existing Column in MySQL

Service Registry Pattern — Netflix Eureka Server With Steeltoe & .NetCore & PCF

How To Import JSON From S3 to PostgreSQL on RDS

Deploying a React + NodeJS Application with Docker

This Is Natural Supplement : PhytAge Labs Tinnitus 911

How to create a static website using Jekyll

Exploring Python Decorators: Part I

Droid Turbo [XT1254] quark — Resurrection Remix — 7.1.2

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Joshua Winters

Joshua Winters

More from Medium

OAuth 2.0 Custom Application Enablement

Why Automated Testing is MUST with EaaS

How to access another super domain url in Cypress while “chromeWebSecurity” is turned on

Set up allure server store automation report