戻る
-
タイトル
Smartcard users have to re-authenticate with their smartcard every few minutes. -
説明
When a user authenticates to SPS using a x.509 smartcard, they are forced to re-authenticate every few minutes.
-
原因
By Design:
When a user opens an SPS session, 15 TCP connections are created and session details are stored in two cookies. After a few minutes the TCP connections are renewed and new ones created. SPS requires that these are re-validated by re-entering the smartcard PIN.
-
対策
Workaround:
The workaround for now is to hit cancel a few times and the user gets no more PIN requests.
Resolution:
Preventing subsequent PIN requests while using smartcard based logon is extremely difficult, almost impossible. The reason behind that is every new HTTPS connection starts with a TLS 1.2 or 1.3 handshake. Assuming that TLS handshake was successful, HTTP request data may follow, and client may present an authentication cookie in its HTTP request - but only after TLS handshake was done.
The web server is unable to separate authenticated and unauthenticated HTTPS requests before TLS handshake was done, because already authenticated clients are identified by their cookies, and cookies can be sent only after a TLS handshake.
Because of TLS standards, the one and only opportunity for the webserver to verify a client certificate happens during the TLS handshake, it cannot be done after it turned out that client has no cookie, therefore the web server always has to ask for a client certificate when a new HTTPS connection is made.
If the server turned off client certificate verification after a client was successfully authenticated, and it would not ask for subsequent client certificates, then a new client would not be able to present its smartcard certificate, therefore new clients would not be able to logon with a certificate.
To overcome this design limitation, and prevent subsequent PIN requests, two methods are suggested:
Method 1
Using smartcard PIN caching, which can be done at client side. For more details see https://learn.microsoft.com/en-us/windows/security/identity-protection/smart-cards/smart-card-architecture#pin-caching
Method 2
Using a separate identity provider service, which is independent from SPS.
Starting with SPS version 7.1, it is possible to use SAML2 login workflow with an external identity provider, like OneLogin (https://www.onelogin.com/). In this scenario the identity provider would authenticate clients with a smartcard, and SPS would use this identity provider to verify users. This way SPS does not need to ask the smartcard certificate.