On Fri, 2020-06-05 at 11:13 +0200, Martin Pitt wrote:
Hello Dinesh,
Dinesh Prasanth Moluguwan Krishnamoorthy [2020-06-03 20:17 -0400]:
> I’m part of Dogtag PKI open-source project [1]. Our team strives to
> provide
> enterprise-class open-source Public Key Infrastructure (PKI) [2].
FTR, Simon Kobyda (CCed) is working on a Cockpit page for managing
certificates
[1]. There may be some overlap here, so perhaps you can meet and
exchange some
ideas.
This sounds interesting. Is this module of yours (as I guess from email
subject) mainly oriented for Smart Cards? What use cases does it look
to solve?
The module I'm working on is so far oriented about functionalities
provided by certmonger. It provides UI to functionalities such
requesting and tracking certificate, importing preexisting certificate
& key and renewing and resubmiting it.
It can request certificate from CA configured to certmonger like IPA.
The module so far doesn't have hard set limitations so it can be
expanded (for example outside of scope of just certmonger) if we find
some overlap.
> 1. According to [3] Cockpit seems to require the host to join
the
> IdM
> domain in order to authenticate PKI users into Cockpit using client
> cert
> auth. Is it possible to use client cert auth without joining a
> domain? Will
> that require major changes in Cockpit?
To be precise, Cockpit calls sssd to map a given certificate from TLS
client
cert auth to a user [2], with FindByCertificate().
This doesn't *inherently* require IdM. It's just (1) the only way how
I got
that sssd lookup mechanism to actually work, and (2) it generally
makes sense
to maintain this cert→user mapping centrally.
Allegedly it is possible to configure sssd to do this mapping with
local
certificates [2]. I played around with that a few weeks ago, as that
would be a
very interesting use case, but I didn't manage to get it working --
apparently
the FindByCertificate() sssd method only works with IdM, not with
these local
certificates. Making that work may be an interesting project.
So this all hinges on sssd -- if that can map a certificate, you can
log into
Cockpit. Cockpit itself would need no modifications for backends
other than
FreeIPA.
> 2. Suppose the user has been authenticated into Cockpit using a
> client cert
> as described in #1, is it possible for Cockpit to use the same
> client
> certificate auth to access PKI server? Or do we need to use a
> different
> auth mechanism?
As Fraser already pointed out, cockpit's web server doesn't have the
private
key that the browser end was using to authenticate, so that doesn't
work.
Does it have to be TLS client cert auth, or would kerberos work as
well? We
are currently designing that so that we can "forward" (or rather,
convert/transcend) the initial client cert auth to a kerberos ticket,
so that
cockpit can use that to further authenticate to services like sudo or
ssh.
Structurally that's very similar, but it would require the PKI server
to accept
delegated (S4U) kerberos tickets.
Martin
[1]
https://github.com/skobyda/cockpit-certificates
[2]
https://docs.pagure.org/SSSD.sssd/design_pages/lookup_users_by_certificat...
[3]
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...
[4]
https://projects.engineering.redhat.com/browse/COCKPIT-542 -- RH
internal only