Hello team,
I’m part of Dogtag PKI open-source project [1]. Our team strives to provide enterprise-class open-source Public Key Infrastructure (PKI) [2].
Dogtag PKI server is a Java web application running on Tomcat. Currently, we have a stand-alone Java AWT client tool called pkiconsole to access PKI services on the server. PKI users are authenticated using client certificates stored in LDAP. These users only exist in LDAP, they are not users on the host itself.
We are trying to convert pkiconsole into a web application. We had a chance to look at Cockpit from a very high-level and have some questions. I’m reaching out to the members of the Cockpit team, before we could make a concrete decision on whether Cockpit is a perfect choice for us.
The questions are:
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?
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?
Regards, The PKI Team
[1] https://github.com/dogtagpki/pki
[2] https://www.dogtagpki.org/wiki/PKI_Main_Page
[3] https://cockpit-project.org/guide/latest/cert-authentication
On Wed, Jun 03, 2020 at 08:17:39PM -0400, Dinesh Prasanth Moluguwan Krishnamoorthy wrote:
Hello team,
I’m part of Dogtag PKI open-source project [1]. Our team strives to provide enterprise-class open-source Public Key Infrastructure (PKI) [2].
Dogtag PKI server is a Java web application running on Tomcat. Currently, we have a stand-alone Java AWT client tool called pkiconsole to access PKI services on the server. PKI users are authenticated using client certificates stored in LDAP. These users only exist in LDAP, they are not users on the host itself.
We are trying to convert pkiconsole into a web application. We had a chance to look at Cockpit from a very high-level and have some questions. I’m reaching out to the members of the Cockpit team, before we could make a concrete decision on whether Cockpit is a perfect choice for us.
The questions are:
- 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?
At a glance at the linked doc, it looks like Cockpit is using mod_lookup_identity certmap capability or something similar for user cert authn. Therefore to work directly for Dogtag users I think it is more than just configuration; something would need to be built.
- 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?
How would this even work? Cockpit does not have the user's private key.
Or Cockpit would need a highly privileged agent credential and access control around its use. Danger! We had quite a few CVEs in FreeIPA because of this kind of privilege separation violation.
Or some new mechanism like a signed "endorsement" from Cockpit that user "alice" requests to do operation X, with ACL enforcement staying in Dogtag (where it belongs).
Anything is possible, but only some approaches are secure. I like the idea of Cockpit using a proxy credential. But the only mechanism we have for that is GSS-API/Kerberos, which takes us full circle back to the requirement for a full-fledge IDM environment.
Cheers, Fraser
Regards, The PKI Team
[1] https://github.com/dogtagpki/pki
[2] https://www.dogtagpki.org/wiki/PKI_Main_Page
[3] https://cockpit-project.org/guide/latest/cert-authentication
Pki-devel mailing list Pki-devel@redhat.com https://www.redhat.com/mailman/listinfo/pki-devel
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.
- 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.
- 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.h... [3] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm... [4] https://projects.engineering.redhat.com/browse/COCKPIT-542 -- RH internal only
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.
- 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.
- 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.h... [3] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm... [4] https://projects.engineering.redhat.com/browse/COCKPIT-542 -- RH internal only
Hello team,
We discussed the possibility of using Cockpit in Dogtag PKI with our whole
team (including Devs, QEs, CEE, POs and PMs). It seems that the proposed
solutions by Martin and Simon seem to require major architectural changes to
Dogtag PKI product itself, which, as Fraser pointed out, circles back to the
requirement of full-fledged IDM environment.
So, as of now, we have decided to use the PatternFly and ReactJS directly to
design our web interface (to stay as close to the cockpit design as possible).
Regards,
--Dinesh
On Mon, Jun 8, 2020 at 8:36 AM Simon Kobyda skobyda@redhat.com wrote:
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.
- 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.
- 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
https://docs.pagure.org/SSSD.sssd/design_pages/lookup_users_by_certificate.h...
[3]
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm...
[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-leave@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.fedorahoste...
cockpit-devel@lists.fedorahosted.org
-
Dinesh Prasanth Moluguwan Krishnamoorthy -
Fraser Tweedale -
Martin Pitt -
Simon Kobyda