Backport to 18.2 of Add job project claims to CI ID Tokens

What does this MR do and why?

• This MR is a Backport of this MR to 18.3

• Please look at the Original MR for detailed context

• Backport runbook

• To solve this issue

• In this commit we patched a security vulnerability related to CI ID tokens for Merge Request Pipelines originating from forked projects but running inside target project

• Before the security patch was made, we had project_ related claims like project_id:, project_path:, namespace_id:, namespace_path: which ALWAYS returned the project inside which the build and it's pipeline is running.

• The security vulnerability was patched by updating the value of these project_ related claims to refer to the forked project and NOT the target project, if the pipeline is of a Merge Request originating from forked projects EVEN it's pipeline is running inside target project.

• Because of the change above, now we have a situation wherein there is no reliable way from the JWT payload to tell inside which project the pipeline and job ran. In the specific case of Merge Request Pipelines originating from forked projects but running inside target project, the project_ related claims DO NOT refer to the actual project inside which the pipeline ran, but rather it refers to the source project of the Merge Request. This inconsistency is causing the problem mentioned in this point. i.e. there is no reliable way from the JWT payload to tell inside which project the pipeline and job ran

• To solve this, we need to add a new set of claims called job_project_ claims - job_project_id:, job_project_path:, job_namespace_id:, job_namespace_path:. These 4 additional claims will always reliably have the values corresponding to the project in which the pipeline is created WITHOUT any exception.

• Only for the specific case of Merge Request Pipelines originating from forked projects but running inside target project, the values of job_project_ claims differ from the corresponding values of project_ claims. For all other cases, the project (Read as source_project) and target_project are one and the same

• Also, need to update the existing doc on ID token payload

• Add 4 new claims to CI ID Tokens - job_project_id:, job_project_path:, job_namespace_id:, job_namespace_path: such that it always returns the values corresponding to the project inside which the CI job ran.

• Only for the specific case of Merge Request Pipelines originating from forked projects but running inside target project, the values of job_project_ claims differ from the corresponding values of project_ claims. For all other cases, the values of target_project_ claims will match the corresponding values of project_ claims.

• Update our docs on CI ID Tokens payload. Add information on the newly added claims and extra information on existing claims which were lacking.

• Refactor - Rename ProjectTokenClaims to UserProjectTokenClaims as it has both user and project claims. The main public method is split into two sub methods user_claims and project_claims as in our new use case, we only need the subset of project_claims without the user_claims,

Screenshots

Before	After

References

• Issue
• Security vulnerability issue
• Security vulnerability patch MR
• Customer raised issue on regression made by the patch

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• This MR is backporting a bug fix, documentation update, or spec fix, previously merged in the default branch.
• The MR that fixed the bug on the default branch has been deployed to GitLab.com (not applicable for documentation or spec changes).
• The MR title is descriptive (e.g. "Backport of 'title of default branch MR'"). This is important, since the title will be copied to the patch blog post.
• Required labels have been applied to this merge request
  • severity label and bug subtype labels (if applicable)
  • If this MR fixes a bug that affects customers, the customer label has been applied.
• Set the milestone of the merge request to match the target backport branch version.
• This MR has been approved by a maintainer (only one approval is required).
• Ensure the e2e:test-on-omnibus-ee job has either succeeded or been approved by a Software Engineer in Test.

Note to the merge request author and maintainer

If you have questions about the patch release process, please:

• Refer to the patch release runbook for engineers and maintainers for guidance.
• Ask questions on the #releases Slack channel (internal only).
• Once the backport has been merged, the commit changes will be automatically deployed to a release environment that can be used for manual validation. See after merging runbook for details.