Closed Jeroen-Van-Loocke closed 6 years ago
Hello Jeroen,
Thank you for reporting this issue. I can reproduce it on my system here, I'll do some logging and see who's causing the de-authenticate.
Wkr, Frederik
On Thu, Jan 25, 2018 at 3:07 PM, Jeroen-Van-Loocke <notifications@github.com
wrote:
I have a Java application that uses a HttpsURLConnection (TLS) connection with the Authentication certificate from the eid, using the X509KeyManager class. We use PKCS11 from the beidpkcs11.dll library to do this. When a first request is done (httpsConnection.getOutputStream()) the user gets prompted to enter his pin code. The user should only get a popup to enter his pin once. After that the user is authenticated and should not be prompted again to authenticate. Recently (a few months ago) this behavior has changed.
- A connection is setup
- A request is done and the user gets prompted for a pin.
- The user enters his pin and authenticates
- All further requests are handled without problem
- The user opens another program or site (mijndossier.rrn.fgov.be for example) that also uses the eid to authenticate.
- User enters his pin and authenticates
- The next request done in our application now again asks for the pin to authenticate.
- After that all request are handled without problem
- ...
It seems that when another application or process uses the Authentication certificate from the eid our authentication is lost. In the past this was not an issue. When another application uses the Signing certificate or when the pin is tested in the eID-Viewer there is no issue. This only happens when authenticating. Could this be due to an Windows update for the MS smartcard minidriver that causes the "deauthenticate" function to be called unwanted? We had a similar problem in the past and it was fixed by an override of the "deauthenticate" function in the eid-middleware. At first it seemed to only happen with Windows 7 but now we can also reproduce this on Windows 10.
This can be reproduced creating a https connection with the authentication certificate. When a first request is done and the user is authenticated, go to another application that uses eid authentication and authenticate. Do another request after that and you should be prompted again for the pin.
Tested using:
- eID Middleware 4.2.8 (build 3252)
- eID Middleware 4.1.20 (build 1779)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Fedict/eid-mw/issues/64, or mute the thread https://github.com/notifications/unsubscribe-auth/ADhcJNr8rISakLhhtePdhAi5P8YKSkJJks5tOIqdgaJpZM4Rs5ks .
Hello Frederik,
Thank you for the quick response. I hope you can find the cause and find a way to fix it.
Kind regards, Jeroen Van Loocke
Hello Jeroen,
I've been looking at the logs and indeed, chrome.exe and CredentialUIBroker.exe (when user authenticating himself using Edge) are calling our de-authenticate function afterwards, effectively reversing the effect of the authentication. So next time PIN will be required again. It is unclear to me if the browsers changed their behaviour recently, but our minidriver is working as intended.
The similar problem (in 2012) you mentioned was about not having this de-authentication function in the minidriver, which caused the card to be reset by the base CSP (see minidriver manual: https://msdn.microsoft.com/en-us/library/windows/hardware/dn468713(v=vs.85).aspx ) But since then, the de-authenticate function has always been present in our minidrivers.
Wkr, Frederik
On Mon, Jan 29, 2018 at 7:43 AM, Jeroen-Van-Loocke <notifications@github.com
wrote:
Hello Frederik,
Thank you for the quick response. I hope you can find the cause and fix it.
Kind regards, Jeroen Van Loocke
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Fedict/eid-mw/issues/64#issuecomment-361153762, or mute the thread https://github.com/notifications/unsubscribe-auth/ADhcJIEmKceE1MOCOsn2XdegfAw5lonmks5tPWiMgaJpZM4Rs5ks .
Hello Frederik
Ok, thank you. I have tested this and indeed Edge and Chrome will do a deauthenticate before they do an authenticate. Firefox not, because there you have to use your (Fedict) Add-on.
So it seems that the only solution is to use Firefox to prevent a deauthenticate. I guess Chrome and Edge have there reasons (Probably security) for first calling the deauthenticate function.
Kind regards, Jeroen Van Loocke
I have a Java application that uses a HttpsURLConnection (TLS) connection with the Authentication certificate from the eid, using the X509KeyManager class. We use PKCS11 from the beidpkcs11.dll library to do this. When a first request is done (httpsConnection.getOutputStream()) the user gets prompted to enter his pin code. The user should only get a popup to enter his pin once. After that the user is authenticated and should not be prompted again to authenticate. Recently (a few months ago) this behavior has changed.
It seems that when another application or process uses the Authentication certificate from the eid our authentication is lost. In the past this was not an issue. When another application uses the Signing certificate or when the pin is tested in the eID-Viewer there is no issue. This only happens when authenticating. Could this be due to an Windows update for the MS smartcard minidriver that causes the "CardDeauthenticateEx " function to be called unwanted? We had a similar problem in the past and it was fixed by an override of the "CardDeauthenticateEx " function in the eid-middleware. (There is also a CardDeauthenticate function) At first it seemed to only happen with Windows 7 but now we can also reproduce this on Windows 10.
This can be reproduced creating a https connection with the authentication certificate. When a first request is done and the user is authenticated, go to another application that uses eid authentication and authenticate. Do another request after that and you should be prompted again for the pin.
Tested using: