To facilitate enterprise authentication gateways (non-oauth) we would like to tell Coder which user has been authenticated along with some details about the type of authentication via a header applied to the proxied gateway request. A scenario where this is useful might be for organizations using Envoy with a custom authentication plugin, where all requests go through Envoy. Envoy will authenticate the request and then forward the request to Coder running on a localhost port.

This is a variation to#5705

Proposal

Add an argument,--allow-external-api-authentication tocoder server That would get passed to a newAllowExternalAPIAuthentication bool field inExtractAPIKeyConfig.

Then in theExtractAPIKey middleware, if enabled, look for the header defined below to look-up the user viaGetUserByEmailOrUsername and validate keys returned fromGetAPIKeysByUserID database API. If the header is not present it would fall back to callAPITokenFromRequest using the current logic.

Header

Coder-Authorization: Basic Field=Value[, Field=Value]...

Known Fields:

• Username=user
• UserEmail=user@example.com
• ActiveSession=token-type
• TokenName=name

TheUsername orUserEmail field would be required and used to fetch the user viaGetUserByEmailOrUsername to identify the Coder user.

Then eitherActiveSession orTokenName would be required to identify the existing key (returned fromGetAPIKeysByUserID) to use. IfActiveSession is used, only look for non-expired keys of the specified token type ("oidc", "password", etc) with an empty token name. Alternately ifTokenName is used, callGetAPIKeyByName to fetch and validate the key.

Optionally, if stronger assurances are required, we could expand theCoder-Authorization header beyond theBasic type to allow for validation. Similar to theAWS auth headers we could facilitate signatures using a shared secret, for example:

Coder-Authorization: HMAC-SHA256 UserEmail=user@example.com, ActiveSession=oidc, SignedHeaders=header1;header2, Signature=xyz

Note thatBasic will work for my requirements, but I think the design can be expanded if you have customers with different/stronger guarantees here.

There will be a few additional error cases that I think we can handle with the "Detail" content on theSignedOutErrorMessage error

• User not found (user does not exist in database, or has deleted=true set)
• Token not found (whenTokenName is specified)
• No active session (whenActiveSession specified and no keys found of token-type)