Support issuing client certificates using only sub OIDC id token field

[erwbgy]

What would you like to be added

Currently the OIDC id token JWT must have an Email field otherwise it is not considered to be an OIDC token: https://github.com/smallstep/cli/blob/master/token/parse.go#L76. While email is one of the standard claims, it is not required to be present (and in our case is not) and we would like certificates to be issued based only on the sub field, which is mandatory and present in all id tokens.

Interestingly https://github.com/smallstep/cli/blob/master/utils/cautils/certificate_flow.go#L275 where the CSR is created already has the email address as optional. But the requirement for OIDC tokens to have email addresses is hardcoded in a few other places.

Why this is needed

There are OIDC clients that are not people so don't have email addresses and it should still be possible to issue client certificates for them.

In addition email addresses are not always good identifiers - https://openid.net/specs/openid-connect-core-1_0.html#ClaimStability says:

The sub (subject) and iss (issuer) Claims, used together, are the only Claims that an RP can rely upon as a stable identifier for the End-User, since the sub Claim MUST be locally unique and never reassigned within the Issuer for a particular End-User, as described in Section 2. Therefore, the only guaranteed unique identifier for a given End-User is the combination of the iss Claim and the sub Claim.

All other Claims carry no such guarantees across different issuers in terms of stability over time or uniqueness across users, and Issuers are permitted to apply local restrictions and policies. For instance, an Issuer MAY re-use an email Claim Value across different End-Users at different points in time, and the claimed email address for a given End-User MAY change over time. Therefore, other Claims such as email, phone_number, and preferred_username and MUST NOT be used as unique identifiers for the End-User.

It should be possible to use any compliant OIDC provider with Step CA.

[maraino]

@erwbgy: in the CA, the current OIDC provisioner right now only provides identities to people (an email SAN) after they do the OAuth2.0 flow.

In your case, it looks like your clients are machines, right? Are they doing an OAuth2.0 flow that returns an id_token parameter? Or do you just have a JWT token?

If they just get a JWT token, it should work, more or less like the GCP provisioner works, where the metadata server provides a JWT token signed by Google.

Are you using any well-known cloud provider that generates those tokens, or are they an in-house implementation? In any case, I think we're open to creating a different type of provisioner for scenarios like yours (or perhaps adapt the oidc one, if it makes more sense).

Can you provide a detailed flow of how do your clients get the token, and some examples of those tokens?

How are the public keys provided, which format? Most common cases are directly from JWK like this or indirectly using a discovery document linking to a JWK like this.

[erwbgy]

The clients are system users, application users or people and they use the OpenID Connect Implicit Flow to get an id token from an on-prem idP from a well known vendor - for example:

{
  "sub": "jbloggs",
  "aud": "myapp",
  "jti": "ubUNVlISAQifTD57QGzHkp",
  "iss": "https://idp.mydomain.com",
  "iat": 1589790336,
  "exp": 1589876736,
  "nonce": "bcaf03a1-f55e-4657-a4d7-63622953e888",
  "at_hash": "jI3b1aLAa2Eyle9b4tnysA"
}

As an example, the clients can currently use their id tokens to authenticate to Kubernetes which extracts the sub and iss fields from the id token to create a user iss#sub - for example https://idp.mydomain.com#jbloggs. We'd like Step CA to issue client certificates with Subject: iss#sub (eg. Subject: https://idp.mydomain.com#jbloggs) from these same id tokens.

[maraino]

Just to be precise, the cert would have:

Subject: CN=https://idp.mydomain.com#jbloggs

and of course:

X509v3 Subject Alternative Name:
   URI: https://idp.mydomain.com#jbloggs

[maraino]

If we add support to this, we would not start the implicit flow, at least initially, and you should pass the token explicitly step ca certificate --token xxx ...

[erwbgy]

Yes, agreed about the Subject and using --token is what we had in mind as well.

[erwbgy]

Thinking about this some more, perhaps we should make setting the Subject and SANs for client certificates more generic to avoid similar requests in future for something slightly different. Otherwise someone else might ask for something like Subject: CN=iss/aud#iss or to include additional fields like O in the subject and yet another provisioner would be required.

My proposal is to add a --token-subject command-line option which takes a string "<SANExtension> <format> <claims>" with the default being "email CN=%s email" which would result in a CSR populated with the email claim from the token as "Subject: CN=email" and "SAN: email:email" just like today.

But users could specify --token-subject="URI CN=%s#%s iss sub" to get a CSR populated with the iss and sub claims from the token as "Subject: CN=iss#sub" and "SAN: URI:<CN value>". For example from the id token above: "Subject: CN=https://idp.mydomain.com#jbloggs" and "SAN: X509v3 Subject Alternative Name: URI: https://idp.mydomain.com#jbloggs".

Another user could specify --token-subject="URI CN=%s/%s#%s iss aud sub" to get a CSR populated from the iss, aud and sub claims from the token as "Subject: CN=iss/aud#sub" and SAN: URI:<CN value>". For example from the id token above: "Subject: CN=https://idp.mydomain.com/myapp#jbloggs" and "SAN: X509v3 Subject Alternative Name: URI: https://idp.mydomain.com/myapp#jbloggs".

This would also allow users to set values other than CN in the Subject, such as O for the groups used by Kubernetes client certificates. For example --token-subject="URI CN=%s#%s,O=%s iss sub aud" could be used to get a CSR populated with the iss, sub and aud claims from the token as "Subject: CN=iss#sub,O=aud" and "SAN: URI:<CN value>". For example from the id token above: "Subject: CN=https://idp.mydomain.com#jbloggs,O=myapp" and "SAN: X509v3 Subject Alternative Name: URI: https://idp.mydomain.com#jbloggs".

[mmalone]

Interesting proposal. It feels like this is starting to overlap with smallstep/cli#110.

One issue though: getting the right CN & SANs into the CSR is only half the battle. The CA also needs to authorize the certificate request. If you're gonna add org to the CN, for example, you'll presumably want to restrict who's allowed to request a cert with a particular org. That being the case, perhaps this shouldn't be a command-line flag at all? Perhaps it should be configured at the CA?

I'm also reluctant to invent an ad-hoc domain-specific language for this one command. I'd prefer to use our existing policy language. Unfortunately, that would turn this into a bigger project.

[erwbgy]

This could definitely be done a different way but even if a JSON format like zcertificate is used there will still need to be a way to request that fields from the id token be used in the CSR.

Rather than a new command-line parameter, perhaps this could be done by specifying a new id-token profile, something like:

$ step certificate create "%s#%s,O=%s iss sub aud" foo.crt foo.key \
    --profile id-token --token ... --san "%s iss"

Support for URI SANs will be required but that looks to be a small change.

Yes, there will definitely need to some changes to the OIDC Provisioner on the CA side to control what attributes in the CSR a user is allowed to request and when an id token is used it would also need to validate that the CSR fields match the id token fields, rather than just the hardcoded email field today. Admins will need to be identified by the subject rather than assuming it is an email.

I've never really thought of printf as a DSL but I suppose it is :-) It is not clear what you mean by your existing policy language though.

[dopey]

@maraino is this "done" now that cert-flexibility has been released?

[maraino]

Yes, for X.509 certificate the OIDC provisioner now does not require the email address, it is only required for SSH certificates.

By default, it will create a Email SAN with the email address if exists and an URI SAN like schema://issuer.url#sub if the issuer is an URL, i.e https://accounts.google.com#1234567890 but the behavior can be changed with certificate templates. One example can be:

{
	"subject": {{ toJson .Subject }},
	"dnsNames": ["{{ .Token.sub }}"],
{{- if typeIs "*rsa.PublicKey" .Insecure.CR.PublicKey }}
	"keyUsage": ["keyEncipherment", "digitalSignature"],
{{- else }}
	"keyUsage": ["digitalSignature"],
{{- end }}
	"extKeyUsage": ["serverAuth", "clientAuth"]
}