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. > 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_certificate.html [3] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_authselect_on_a_red_hat_enterprise_linux_host/configuring-and-importing-local-certificates-to-a-smart-card_using_authselect_on_a_red_hat_enterprise_linux_host [4] https://projects.engineering.redhat.com/browse/COCKPIT-542 -- RH internal only _______________________________________________ cockpit-devel mailing list -- cockpit-devel@lists.fedorahosted.org To unsubscribe send an email to cockpit-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/cockpit-devel@lists.fedorahosted.org
