Open paul-snively opened 2 years ago
maraino
commented
2 years ago @paul-snively right now, you can configure an OIDC provisioner on step-ca and get certificates for your persona with your email on them.
That draft looks to me as an attempt of standarize a similar flow over the ACME protocol. The support for ACME clients of that protocol might take some time.
dopey
commented
2 years ago Hey @paul-snively :wave: Thanks for opening this issue!
We've actually thrown this idea around internally before. Eventually, we'd love for all of our provisioners to be supported through ACME. However, as @maraino mentioned, we don't see much value in integrating this flow before more of the popular clients support it. If we're the only ones that support it in the short term, then it's not much different than just using an OIDC provisioner.
I've added this to our triage so we can discuss and prioritize internally. Will let you know here if there are any updates.
Cheers :beers:
Hello!
Issue details
In my opinion, step-ca has an opportunity to significantly advance the goal of Zero-Trust Authentication by extending its already-excellent support for OIDC provisioning to support for draft-biggs-acme-sso-01, thereby enabling supported ACME clients to provide simple and seamless OIDC-to-X.509 authentication.
Why is this needed?
ACME and step-ca have done wonders in reducing the historic friction of issuing and deploying X.509 certificates, specifically encouraging wider adoption of mTLS authentication. In parallel, the SPIFFE project has similarly begun to provide wide infrastructure support for Zero-Trust Architecture, a goal also near and dear to SmallStep's heart. Like much X.509-based infrastructure, however, SPIFFE seems to focus primarily on node-to-node and workload-to-workload authentication, essentially ignoring end-user authentication. step-ca with draft-biggs-acme-sso-01 support could potentially help close this gap by providing the flow for end-user-facing systems to participate in a standard OIDC authentication flow exactly as they do today, but with the end result being the system's acquisition of an X.509 leaf certificate. Presumably for the use-cases I have mind, additional steps that are out of scope for this enhancement suggestion would then include:
The particular use-case I have in mind includes mapping roles all the way from the OIDC identity token to roles defined in PostgreSQL, and using SPIFFE/SPIRE to provide X.509 certificates to PostgreSQL for authentication as in this spiffe-helper example, resulting in an RBAC solution for data in PostgreSQL all the way from OIDC login to connecting to PostgreSQL at all, and from there to what data that role in PostgreSQL has access to.