diff --git a/docs/deploying-identity-provider.md b/docs/deploying-identity-provider.md index 5dde067ce..213b53f48 100644 --- a/docs/deploying-identity-provider.md +++ b/docs/deploying-identity-provider.md @@ -3,7 +3,7 @@ This document details how a client or service that wants to integrate with Fulcio can stand up a minimally viable identity provider to offer non-interactive signing, where the client or service exchanges a user's identity token for a Fulcio certificate. -Identity providers should follow the security requirements outlined in [New IDP Requirements](https://github.com/sigstore/fulcio/blob/main/docs/new-idp-requirements.md) as well. +Identity providers should follow the security requirements outlined in [New IDP Requirements](new-idp-requirements.md) as well. ## Background & Motivation @@ -21,8 +21,7 @@ If a service wants to implement an integration with Sigstore, typically a client If a service wants to minimize user authentication to reduce friction while signing and has a way to represent a unique user identity, the service could implement a minimally viable OIDC identity provider. The provider would not look like a typical provider that exchanges credentials for a token. The provider could simply generate an identity token for a user that is already authenticated and provide this token to Fulcio (which has allowlisted the provider) or a Sigstore client during artifact signing. The provider would only need to expose the well-known endpoint and verification keys to the internet if the service is signing on behalf of the user. If the user is performing signing in a client rather than through a service, then the token signer would need to be exposed to the user as an authenticated endpoint that exchanges a credential for an identity token. -Diagram: -![][image1] +![Diagram outlining identity provider signing workflow](img/OIDC-provider-sigstore.png) ## Implementation @@ -72,5 +71,3 @@ The provider will need to be added to Fulcio, following the [integration guide]( 1) Sending a certificate signing request to Fulcio to issue a certificate. The easiest way would be to use [Cosign](https://github.com/sigstore/cosign) or [sigstore-python's](https://github.com/sigstore/sigstore-python) CLI, e.g. `cosign sign-blob README.md --bundle cosign.bundle --identity-token --fulcio-url --tlog-upload=false`. You can also construct the request following the [proto spec](https://github.com/sigstore/fulcio/blob/main/fulcio.proto). With Cosign, you can inspect the bundle output and verify the certificate content, e.g. `cat cosign.bundle | jq -r .cert | base64 -d | openssl x509 -text -noout`. Verify that `X509v3 Subject Alternative Name` matches the identity and `1.3.6.1.4.1.57264.1.1` matches the identity provider URL. After adding the provider, Sigstore maintainers will deploy the updated configuration to the staging environment, which can be tested against following [this guide](https://docs.sigstore.dev/system\_config/public\_deployment/\#staging-instance). After you've verified the issued certificate matches what is expected, the configuration will be deployed to the production environment. - -[image1]: