Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Token fixes #412

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Token fixes #412

wants to merge 4 commits into from

Conversation

jku
Copy link
Member

@jku jku commented Oct 22, 2024

I'm not too confident with rust or this code base yet so advice is welcome: I can see there are many ways to implement something like the "signing identity" here but I don't think I have a feel for best practices yet...

Summary

Support more types of OIDC tokens -- specifically support the "Sub" field used as the signing identity by some issuers.

  • Make email optional when parsing JWT (e.g. GitHub actions does not use it)
  • Add IdentityToken.identity field: this is the identity claim that we believe Fulcio uses for this issuer
  • Fix the bundle signing so it uses the new identity field
  • Add tests with two tokens (interactive and GHA)

Note that signing with a "Sub" identity now works (the CSR will use the email OID for everything as before but apparently that works: sigstore-python does that too) in places like Github actions but there are no tests yet.

My plan after this is to:

  • Add the "ultimate issuer" claim into IdentityToken: this finally makes it visible who is really signing. See https://github.com/jku/sigstore-rs/tree/token-add-issuer-claim for this if interested
  • add a test that runs on GH actions: manually fetch the token and test if signing works (see 9f50501)
  • a bit longer term, search for a https://github.com/di/id style project for rust or write one if that does not exist (I think this model worked great for sigstore-python)

... but these are currently not part of this PR.

Fixes #413

@jku jku force-pushed the token-fixes branch 2 times, most recently from ba0ed7b to 73597db Compare October 22, 2024 08:48
src/oauth/token.rs Outdated Show resolved Hide resolved
* Make email optional when parsing JWT (e.g. GitHub actions does not use it)
* Add IdentityToken.identity field: this is the identity claim that we
  believe Fulcio uses for this issuer
* Fix the bundle signing so it uses the new identity field
* Add test with a GitHub Actions token

Note that signing with a Sub claim is still not supported but we're now
a bit closer.

Signed-off-by: Jussi Kukkonen <[email protected]>
src/bundle/sign.rs Outdated Show resolved Hide resolved
Apparently Fulcio does not care about the CSR subject: just claim
everything is an email.

https://github.com/sigstore/fulcio/blob/main/fulcio.proto#L106

Signed-off-by: Jussi Kukkonen <[email protected]>
@jku jku marked this pull request as ready for review October 23, 2024 11:55
@jku jku marked this pull request as draft October 23, 2024 16:50
@jku

This comment was marked as outdated.

src/oauth/token.rs Outdated Show resolved Hide resolved
Comment on lines 109 to 131
let identity = match claims.iss.as_str() {
"https://accounts.google.com"
| "https://oauth2.sigstore.dev/auth"
| "https://oauth2.sigstage.dev/auth" => {
if let Some(email) = claims.email.as_ref() {
Identity::Email(email.clone())
} else {
return Err(SigstoreError::IdentityTokenError(
"Email claim not found in JWT".into(),
));
}
}
_ => {
if let Some(sub) = claims.sub.as_ref() {
Identity::Sub(sub.clone())
} else {
return Err(SigstoreError::IdentityTokenError(
"Sub claim not found in JWT".into(),
));
}
}
};

This comment was marked as resolved.

@jku
Copy link
Member Author

jku commented Oct 23, 2024

I'm making this a draft again: I made a quick test to try how far the signing on github goes but fulcio does not seem to like the identity token -- I'll figure out if the issue is something in this PR or not before making this ready for review.

Back to ready for review: the IdentityToken is fine, I just messed up GitHubs token-request-token handling in my test.

Speaking of that, I can add add my test for signing-in-a-github-workflow in this PR too, I just figured it does not need to be here. Let me know if you have opinions

@jku jku marked this pull request as ready for review October 24, 2024 07:09
We don't judge the claims that OIDC provider makes (apart from some
compatibility checks): make this clear in the API and docs.

Signed-off-by: Jussi Kukkonen <[email protected]>
@jku
Copy link
Member Author

jku commented Oct 24, 2024

Latest commit makes it clear that identity claim comes from the OIDC JWT.

Let me know if you feel strongly about the solution here: I can make identity_claim a method in Claims as @tnytown suggested if there are strong opinions -- I didn't do it yet since I felt doing the validation at try_from() time is useful.

Copy link
Contributor

@tnytown tnytown left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks for entertaining my review!

@jku
Copy link
Member Author

jku commented Oct 29, 2024

FYI in case you'd rather see a more complete picture:

assert_eq!(identity_token.claims.email, None);
assert_eq!(
identity_token.claims.sub,
Some(String::from("repo:sigstore-conformance/extremely-dangerous-public-oidc-beacon:ref:refs/heads/main"))
Copy link
Member Author

@jku jku Oct 31, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm going to double check if this is correct: It is the token "sub" field... but it does not seem to be what "bundle verify" uses for --identity

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess that's just how it works? When we ask for the certificate we have no idea what the actual certificate subject is going to be as it's not the identity claim in the OIDC token... I really hope I'm just tired and that's not true

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, I found the identity handling bits in fulcio and can confirm: before we get the certificate we ultimately do not know who we are signing as... exposing the token identity here is still useful since it happens to match the signing identity in the interactive case but it's unfortunately not as useful as I hoped.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

IdentityToken: Only "email" identity is supported
2 participants