The `SignKeyError` enum will also be used by the request handler for
signing SSH user certificates. Thus, I am moving it to its own module
where it can be accessed from both places.
The `sshca::ca::sign_cert` function has been renamed to
`sign_host_cert`, reflecting that it creates SSH host certificates. A
new `sign_user_cert` function is now available to sign SSH user
certificates.
The second major feature for SSHCA will be the ability to sign SSH
certificates for users. Naturally, users will need to prove their
identity to the server in order for it to issue certificates for them.
To implement that, we will use OpenID Connect Identity Tokens. Users
will obtain a token from an Identity Provider and include it in their
request to the SSHCA server. If the token is valid and issued by a
trusted provider, the server will sign the user's keys.
The `openidconnect` crate provides everything we need to validate OIDC
ID tokens. It supports fetching the OpenID Provider Configuration in
order to retrieve the signing keys. These keys are then used to
verify the signature of a token; other token metadata are verified as
well, including issuer, audience, and expiration.
To avoid making an HTTP request to the OIDC IdP for every request, the
provider configuration is cached for an hour after each lookup.
Clients, such as the `sshca` CLI utility, can use the *GET
/user/oidc-config* HTTP path operation to fetch the SSHCA server's
OpenID Connect client configuration. The can use the information
returned to initiate a login process with the IdP and obtain the
identity token to submit to the SSHCA server.
In preparation for adding a separate authorization strategy for client
requests, I have moved the implementation of the authorization strategy
for host requests in to the `server::host` module.
dustin/sshca/pipeline/head This commit looks goodDetails
When this repository was split from the original *dustin/sshca*
repository, the CI pipeline was not imported. It wouldn't have mattered
if it had been, since it wouldn't have worked, anyway, given the path
changes.
I realized that allowing hosts to request certificates for arbitrary
aliases sort of defeats the purpose of the authentication process. If a
host successfully authenticates, there would be nothing stopping it from
requesting a certificate for another host. I will have to come up with
a different way of specifying aliases. Probably something like a JSON
map containing pre-assigned aliases for hosts that will need them.
Since hosts have multiple keys that they will want to have signed, they
will need to make multiple requests, either sequentially or in parallel.
Since each request must be authenticated individually, this would result
in a libvirt connection and lookup for each one. To avoid this
overhead, the server will now cache machine IDs in memory for 60
seconds.
Dustin