config: Add IBM OIDC provider

[stefanberger]

Summary

This PR adds IBM's OIDC provider to the list of providers.

Closes: #1891

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 49.03%. Comparing base (cf238ac) to head (b260846).
Report is 285 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1892      +/-   ##
==========================================
- Coverage   57.93%   49.03%   -8.90%     
==========================================
  Files          50       70      +20     
  Lines        3119     5204    +2085     
==========================================
+ Hits         1807     2552     +745     
- Misses       1154     2417    +1263     
- Partials      158      235      +77     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[stefanberger]

Thanks for merging. Is this going to become available via --staging? And when would it become usable?

[haydentherapper]

It's now out in staging. Please verify and we'll push it through to prod!

[stefanberger]

It worked with our JWT:

$ python -m sigstore --staging sign --identity-token ${token} --overwrite hashes.py
audience: sigstore  ['sigstore', 'ba38bfc2-894f-4365-9ef5-72ea59e01af9']

Using ephemeral certificate:
-----BEGIN CERTIFICATE-----
MIIC4zCCAmigAwIBAgIUVrFRU4ZQ7Y5plMZCiL37e4yFYgcwCgYIKoZIzj0EAwMw
NzEVMBMGA1UEChMMc2lnc3RvcmUuZGV2MR4wHAYDVQQDExVzaWdzdG9yZS1pbnRl
cm1lZGlhdGUwHhcNMjUwMTIxMjIxOTU4WhcNMjUwMTIxMjIyOTU4WjAAMFkwEwYH
KoZIzj0CAQYIKoZIzj0DAQcDQgAEcDIIpgIVYY+9kVjW1ZixiTFBgQCJKtPhLAXy
alu5Rwn+GhAP91UrMwIMyF85CC33oUw76ExQiDBFguUCZXJc1qOCAYcwggGDMA4G
A1UdDwEB/wQEAwIHgDATBgNVHSUEDDAKBggrBgEFBQcDAzAdBgNVHQ4EFgQUvAsz
kIqXWUWam4Bz9qX9orBeC+cwHwYDVR0jBBgwFoAUcYYwphR8Ym/599b0BRp/X//r
b6wwIAYDVR0RAQH/BBYwFIESc3RlZmFuYkB1cy5pYm0uY29tMDQGCisGAQQBg78w
AQEEJmh0dHBzOi8vc2lnc3RvcmUudmVyaWZ5LmlibS5jb20vb2F1dGgyMDYGCisG
AQQBg78wAQgEKAwmaHR0cHM6Ly9zaWdzdG9yZS52ZXJpZnkuaWJtLmNvbS9vYXV0
aDIwgYsGCisGAQQB1nkCBAIEfQR7AHkAdwArMLzcaIjJ4uHYJiledB9IOTGWAvKc
M8teQ0D+sqyGegAAAZSK83YXAAAEAwBIMEYCIQC9El7vYR2gAP6ajGfqZzd0QDMg
RbK0/0hTOLzy1l+iwQIhAKUkVNp3tpvX6tQmxR+9ksaloGbhJmger3AD5cMf0GGi
MAoGCCqGSM49BAMDA2kAMGYCMQDkjCfQgxfqo9a49DoxIm9RbH3LLr5Quh3lIAIK
HWBrpIQKJC0Nd6AijIq5G/CdRr4CMQC4mzFRXYhhMZHx5fSZvI4nLHLSvtIrerXq
XnQ//DgeYNeMtlduuK+fvkGhPwPs+3Q=
-----END CERTIFICATE-----

Transparency log entry created at index: 36945684
MEUCIQCf/p5PbHDiSpIIqsjMGPpF4tYjdHQVTi/UmmwQfpASSwIgTvg/ELxSSDqu7Gh6GanKkJuvwo52WlLFzr1AgzShQC4=
Sigstore bundle written to hashes.py.sigstore.json

[bobcallaway]

@stefanberger how did you obtain the JWT? I tried to at least start the OIDC flow with cosign, which complains that the endpoint does not support PKCE (which we require in our clients). I notice your test above obtains the id token out of band, so I am curious what use case you're trying to support?

[stefanberger]

@stefanberger how did you obtain the JWT? I tried to at least start the OIDC flow with cosign, which complains that the endpoint does not support PKCE (which we require in our clients). I notice your test above obtains the id token out of band, so I am curious what use case you're trying to support?

We have our own tool to get the JWT from our server. One use case is interactive signing. Another one would be automated signing with client_secret.

[bobcallaway]

@stefanberger how did you obtain the JWT? I tried to at least start the OIDC flow with cosign, which complains that the endpoint does not support PKCE (which we require in our clients). I notice your test above obtains the id token out of band, so I am curious what use case you're trying to support?

We have our own tool to get the JWT from our server. One use case is interactive signing. Another one would be automated signing with client_secret.

Is there a reason you aren't using cosign or one of our other language SDKs?

[stefanberger]

Is there a reason you aren't using cosign or one of our other language SDKs?

No, there was no particular reason. It required enablement of PKCE and other changes. I am currently trying to figure out how to deal with an error related to the redirect_url urn:ietf:wg:oauth:2.0:oob, but this here works:

$ cosign sign --fulcio-url https://fulcio.sigstage.dev --rekor-url https://rekor.sigstage.dev --oidc-issuer https://sigstore.verify.ibm.com/oauth2 --oidc-client-id ba38bfc2-894f-4365-9ef5-72ea59e01af9 -y cosign
[...]
Go to the following link in a browser:

         https://sigstore.verify.ibm.com/oauth2/authorize?access_type=online&client_id=ba38bfc2-894f-4365-9ef5-72ea59e01af9&code_challenge=mlLPxYlCg2pQS4g75GMson-Fxx_20LJAwkHVtKl1aYo&code_challenge_method=S256&nonce=2rzxKYJGlXq13fWSQsR7i0qFHWV&redirect_uri=urn%3Aietf%3Awg%3Aoauth%3A2.0%3Aoob&response_type=code&scope=openid+email&state=2rzxKZGobe6MXQVaCyWikpVlXZf
Enter verification code:

[stefanberger]

@bobcallaway: @vivshankar and I have been discussing the redirect_url urn:ietf:wg:oauth:2.0:oob and whether that one could be replaced with a concrete URI/URL via the --oidc-redirect-url option. Right now this option has no effect and actually tries to start a listener on the address provided there. Also, is urn:ietf:wg:oauth:2.0:oob part of the standard?

[stefanberger]

Is there a reason you aren't using cosign or one of our other language SDKs?

@bobcallaway, actually, there is a reason. Support for the IBM identity server is currently in staging. With --staging on sigstore tools I can now sign and verify. I cannot use cosign even like this when passing the staging servers on the command line, not even trying to use the IBM identity server:

cosign sign-blob --fulcio-url  https://fulcio.sigstage.dev --rekor-url   https://rekor.sigstage.dev test
Using payload from: test
Generating ephemeral keys...
Retrieving signed certificate...

	The sigstore service, hosted by sigstore a Series of LF Projects, LLC, is provided pursuant to the Hosted Project Tools Terms of Use, available at https://lfprojects.org/policies/hosted-project-tools-terms-of-use/.
	Note that if your submission includes personal data associated with this signed artifact, it will be part of an immutable record.
	This may include the email address associated with the account with which you authenticate your contractual Agreement.
	This information will be used for signing this artifact and will be stored in public transparency logs and cannot be removed later, and is subject to the Immutable Record notice at https://lfprojects.org/policies/hosted-project-tools-immutable-records/.

By typing 'y', you attest that (1) you are not submitting the personal data of any other person; and (2) you understand and agree to the statement and the Agreement terms at the URLs listed above.
Are you sure you would like to continue? [y/N] y
Your browser will now be opened to:
https://oauth2.sigstore.dev/auth/auth?access_type=online&client_id=sigstore&code_challenge=9Pl-MZA3R2GUqfkAqtp2YmkDAr7Ud9vQuNeWEhvGpEo&code_challenge_method=S256&nonce=2s2RLgrKFazXIKR59NTiIY3aIYn&redirect_uri=http%3A%2F%2Flocalhost%3A35995%2Fauth%2Fcallback&response_type=code&scope=openid+email&state=2s2RLe9MQWOGrpuC6A09ez3BTNJ
Error: signing test: getting key from Fulcio: retrieving cert: POST https://fulcio.sigstage.dev/api/v1/signingCert returned 400 Bad Request: "{\"code\":3,\"message\":\"There was an error processing the identity token\",\"details\":[]}"
main.go:74: error during command execution: signing test: getting key from Fulcio: retrieving cert: POST https://fulcio.sigstage.dev/api/v1/signingCert returned 400 Bad Request: "{\"code\":3,\"message\":\"There was an error processing the identity token\",\"details\":[]}"

[bobcallaway]

the staging instance also requires you to add --oidc-issuer=https://oauth2.sigstage.dev/auth as we don't support prod tokens being accepted in staging AFAIK

[stefanberger]

Now I am at the same point as with the IBM oidc issuer in this case:

$ cosign sign-blob --fulcio-url  https://fulcio.sigstage.dev --rekor-url   https://rekor.sigstage.dev --oidc-issuer https://oauth2.sigstage.dev/auth  test
Using payload from: test
Generating ephemeral keys...
Retrieving signed certificate...

	The sigstore service, hosted by sigstore a Series of LF Projects, LLC, is provided pursuant to the Hosted Project Tools Terms of Use, available at https://lfprojects.org/policies/hosted-project-tools-terms-of-use/.
	Note that if your submission includes personal data associated with this signed artifact, it will be part of an immutable record.
	This may include the email address associated with the account with which you authenticate your contractual Agreement.
	This information will be used for signing this artifact and will be stored in public transparency logs and cannot be removed later, and is subject to the Immutable Record notice at https://lfprojects.org/policies/hosted-project-tools-immutable-records/.

By typing 'y', you attest that (1) you are not submitting the personal data of any other person; and (2) you understand and agree to the statement and the Agreement terms at the URLs listed above.
Are you sure you would like to continue? [y/N] y
Your browser will now be opened to:
https://oauth2.sigstage.dev/auth/auth?access_type=online&client_id=sigstore&code_challenge=GH2p5Jwoomy4KwUl1RTC3eObU2X-XjvlZCCgr33YASQ&code_challenge_method=S256&nonce=2s2VMOqojKBrd1OcGSr8yFSHs0t&redirect_uri=http%3A%2F%2Flocalhost%3A43699%2Fauth%2Fcallback&response_type=code&scope=openid+email&state=2s2VMKZYFW7t4SWMrU6r6EbsY52
Error: signing test: getting key from Fulcio: verifying SCT: ctfe public key not found for payload. Check your TUF root (see cosign initialize) or set a custom key with env var SIGSTORE_CT_LOG_PUBLIC_KEY_FILE
main.go:74: error during command execution: signing test: getting key from Fulcio: verifying SCT: ctfe public key not found for payload. Check your TUF root (see cosign initialize) or set a custom key with env var SIGSTORE_CT_LOG_PUBLIC_KEY_FILE