My team has been trying to get Smartcard Authentication to work with Webkit2gtk-4.1. However we are unable to do so due to missing functions. Does Webkit2gtk-4.1 plan to support smartcards in the ear future?
I am not sure, if this is the right place to log this ticket, if there is any other place to request features. Please let me know
Hi, this is already supported. See here for an example.
However, do note that it won’t work in flatpak unless you give the app inappropriate static permissions, because there is no PKCS #11 portal yet. That’s where help would be welcome.
@mcatanzaro Thank you for sharing the example, In the example shared above for “epiphany” browser, Does the smart-card authentication support on Ubuntu/debian environments?
We reached out to canonical team about Smart Card Authentication support, Apparently smart card authentication will not work on Ubuntu Desktop Environment due to an open issue with GnuTLS standard on glib Fails certificate authentication with GnuTLS (#198) · Issues · GNOME / glib-networking · GitLab.
And yet, the Epiphany merge request is tested and known to work, so that bug cannot affect everyone.
Hi @mcatanzaro
Currently we’re not getting an authenticate signal from the WebKit with the scheme: ClientCertificatePinRequested. It is during this signal where we pass the PIN associated with the certificate using which we sign the nonce and complete the authentication.
Since this is yet to be added by the WebKit, we came up with a workaround where we’re passing the pin-value that we retrieve from the customer to the Private Key’s URI and pass it when the initial authenticate signal with the Scheme: ClientCertificateRequested is requested by the webkit. Something like this:
const char* cert_uri = “pkcs11:model=<model>;manufacturer=<manufacturer>;token=<value>;type=cert”;
const char* pk_uri = “pkcs11:model=<model>;manufacturer=<manufacturer>;token=<value>;type=private?pin-value=<PIN_VALUE>“;
GTlsCertificate *tls_cert;
tls_cert = g_tls_certificate_new_from_pkcs11_uris(cert_uri, pkey_uri, &error);
WebKitCredential* credential = webkit_credential_new_for_certificate(tls_cert, WEBKIT_CREDENTIAL_PERSISTENCE_FOR_SESSION);
webkit_authentication_request_authenticate(authentication, credential);
On using this approach we’re successfully able to perform authentication without having to wait for the second authenticate signal with the scheme: ClientCertificatePinRequested
Do you see any concerns / security issues with this approach?
Hm, I don’t think there would be any security concerns to doing things that way. That’s certainly not how the API is supposed to work, but if it works, it shouldn’t hurt?
That said, you should definitely be receiving the WebKitWebView::authenticate signal when a PIN is requested. We know that should work because there is a screenshot of it working in the Epiphany merge request that I linked to up above. It looks like what Epiphany expects is (1) an initial authentication request with scheme WEBKIT_AUTHENTICATION_SCHEME_CLIENT_CERTIFICATE_REQUESTED, and then (2) a follow-up authentication request with scheme WEBKIT_AUTHENTICATION_SCHEME_CLIENT_CERTIFICATE_PIN_REQUESTED. But I’m not sure how anybody could be expected to know this, because it doesn’t seem to be documented anywhere that I can see. It’s a little weird that two requests are required.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.