debian-forge-composer/docs/news/unreleased/api-oauth2-support.md
sanne 4a057bf3d5 auth: OpenID/OAUth2 middleware
2 configurations for the listeners are now possible:
- enableJWT=false with client ssl auth
- enableJWT=true with https

Actual verification of the tokens is handled by
https://github.com/openshift-online/ocm-sdk-go.

An authentication handler is run as the top level handler, before any
routing is done. Routes which do not require authentication should be
listed as exceptions.

Authentication can be restricted using an ACL file which allows
filtering based on JWT claims. For more information see the inline
comments in ocm-sdk/authentication.

As an added quirk the `-v` flag for the osbuild-composer executable was
changed to `-verbose` to avoid flag collision with glog which declares
the `-v` flag in the package `init()` function. The ocm-sdk depends on
glog and pulls it in.
2021-09-04 02:48:52 +02:00

2.1 KiB

Composer-api and worker-api: OAuth2 support

Adding OAuth2 support to composer means both the composer-api and worker-api are now able to authenticate clients using the JWT set in the "Authorization" HTTP header. This was added with Red Hat Single Sign-On in mind, but would work for other OAuth2 providers as well (potentially with minor changes).

Workflow

  1. A client makes a request to https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token using their offline token.

  2. sso.redhat.com would respond with an access_token which is valid for a certain period.

  3. This access_token can be set in the "Authorization" HTTP header: "Authorization: Bearer access_token".

  4. Composer verifies the token against the certificates returned by https://^Co.redhat.com/auth/realms/redhat-external/protocol/openid-connect/certs.

Configuration

Using openshift-online/ocm-sdk composer-api now supports oauth2 authentication. To this end there's 4 new config options for the Worker and Composer API:

  • EnableJWT: Enable or disable OAuth2 authentication.
  • JWTKeysURL: Location where the certs used to verify the JWT tokens are served.
  • JWTKeysCA: Path to the CA which should be used when retrieving the certs (optional).
  • JWTACLFile: Path to a yaml file containing a series of pattern match rules against the claims contained within the JWT (optional).

ACL claims pattern matching format

The ACLFile should contain a list of claims and their required pattern in yaml format. Note that a claim with a specific name can only be specified once. So if for instance a required pattern for the email claim is listed twice, only one will pattern will be applied.

The pattern is verified using the golang regexp package, and follows the RE2 syntax.

Example:

- claim: email
  pattern: ^.*@redhat\.com$
- claim: sub
  pattern: ^f:b3f7b485-7184-43c8-8169-37bd6d1fe4aa:myuser$
- claim: account_number
  pattern: ^(1000|1001|1002)$
- claim: account_id
  pattern: ^(5000|5005)$