Draft: Resolve "Allow users to customize their JWT sub claim (MVC)"
-
Please check this box if this contribution uses AI-generated content (including content generated by GitLab Duo features) as outlined in the GitLab DCO & CLA
What does this MR do and why?
This MR adds a new attribute to projects, named ci_id_token_sub_claim_components
. Project admins can change the value of ci_id_token_sub_claim_components
to produce tokens with more or less detailed sub
claims.
The default value of ci_id_token_sub_claim_components
is ["project_path", "ref_type", "ref"]
. Each element of ci_id_token_sub_claim_components
must name a custom JWT claim produced by GitLab, and the first element must be project_path
.
JWTs created for id_tokens
in CI now use this config to create the sub
claim on the token. Each element of ci_id_token_sub_claim_components
is formatted into <claim_name>:<claim_value>
, joined with :
. For the default value this will result in sub
claims that reproduce the current fixed format, which looks like project_path:agroup/bgroup/myproject:ref_type:tag:ref:v4.2.0
. Custom formatting and static values aren't permitted.
MR acceptance checklist
Issues that need to be addressed:
- Tests
- Documentation
- Improving validation of
ci_id_token_sub_claim_components
at PUT time
How to set up and validate locally
Testing token production:
- Update a project's
ci_id_token_sub_claim_components
value withPUT /projects/:id
- Run a build that has id_tokens configured
- Echo the token (
echo $TOKEN | base64
or it will be masked) - base64d and verify
Testing relying parties:
- Obtain a public IP, DNS name, and real (not self-signed) TLS cert for your instance
- Configure the relying party correctly based on the DNS name from step 1 and customized
sub
claim - Do the steps in "Testing token production" except using the token rather than just printing it
Related to #360592 (closed)