OIDC enhancement: Support for additional OIDC subjects

[haydentherapper]

Background

As discussed in rubygems/rfcs#37, there is a desire to specify other values in OIDC tokens besides emails, SPIFFE IDs, or Github OIDC subjects. RubyGems is proposing using the profile URI as the subject of the OIDC token. As other IDPs integrate with Fulcio, subjects could also simply be usernames without any domain.

Integration with IDPs can be done with Dex or directly through Fulcio's list of OIDC issuers. For this issue, I will focus on the latter. There are benefits to integrating directly with Fulcio, primarily automation.

I propose that we add support for two types of domain-scoped subjects:

1. URIs that contain a domain and user identifier
2. Usernames along with a domain for which the username is valid

Details

We will add new Types for each of these flows.

Type: uri

OIDC tokens must have a subject with the following structure: domain/user-identifier

For example, consider RubyGems profiles. For https://rubygems.org/profiles/username, the domain is https://rubygems.org and the user identifier is profiles/username. We will require that the issuer URL host (where the openid configuration is hosted) matches the domain specified in the token. It is up to the client to interpret the user identifier.

Issued certificates will include the subject as a URI subject alternative name, URI:domain/user-identifer.

Example configuration, assuming RubyGems sets up the IDP at /auth:

"https://rubygems.org": {
      "IssuerURL": "https://rubygems.org/auth",
      "ClientID": "sigstore",
      "Type": "uri"
    },

Type: user-with-domain (name WIP)

OIDC tokens must have a subject without a domain, for example a username or a user ID. As part of configuring the OIDC issuer, a domain will be specified. Like with uri, we will require that the issuer URL host matches the domain specified in the configuration.

Issued certificates will include the subject as an email subject alternative name. Fuclio will concatenate the subject and domain specified in the config, EMAIL:username@domain.

Example configuration:

"https://rubygems.org": {
      "IssuerURL": "https://rubygems.org/auth",
      "ClientID": "sigstore",
      "Domain": "rubygems.org"
      "Type": "user-with-domain"
    },

Domain verification

Requiring that the issuer URL matches the domain specified in the token or configuration will mitigate the risk of a misconfigured IDP issuing tokens scoped to other domains. For example, if another trusted IDP attempted to issue a token with a subject of https://rubygems.org/profiles/user, on verification, Fulcio will only use the configuration named https://rubygems.org.

For a future improvement, we can use a domain verification system like ACME to verify that a requester who wants to add an OIDC IDP to Fulcio has control over that domain.

[haydentherapper]

cc @rochlefebvre @jchestershopify @di

[di]

I'm curious how 'noreply' email addresses would fit into this, e.g. GitHub's <username>@users.noreply.github.com emails. For user-with-domain, does the domain have to match exactly, or could it be a subdomain? Do we make the assumption that the email is routable, or just that it's unique?

[haydentherapper]

For user-with-domain, does the domain have to match exactly, or could it be a subdomain?

Good question! Some initial thoughts:

• A profile might be accessible on a different subdomain than the authentication service, such as accounts.rubygems.org/auth vs rubygems.org/profiles/....
• I don't want to assume that there will only be one profile service per domain. Possibly a domain allows subdomains to run their own services.
• For that same reason, we can't assume one IDP per domain.

We will allow the configuration key to contain a subdomain, and Domain to either be the same subdomain or a domain without a subdomain. For an automated setup, we should require proof that the requester adding the IDP to Fulcio has access to both the subdomain and domain. Without an automated setup, we should be cautious when allowing a configuration with different values.

For uri types, let's add a Domain configuration field too. We can do the same checks of ownership for the domains, and also we'll use this to check that the domain/subdomain in the profile URI matches the configuration.

Do we make the assumption that the email is routable, or just that it's unique?

Just that it's unique, not routable. This just provides a way for IDPs that only issue tokens for usernames to get domain-scoped certificates.

[haydentherapper]

Beginning work on this.