Comment 1 Alexander Zeijlon 2025-02-11 09:13:52 CET

Turns out we already have a mechanism for remembering the user certificate selection, but right now we ignore the trigger of auto login if there are more than one certificate listed in the client (after filtering has been done).

We can tweak this behavior a bit, such that auto login will trigger either if there is only one certificate present, or if the chosen certificate is already stored in the client config. The latter occurs when a certificate is being used, when clicking "connect".

This means that the behavior is unchanged when there is only one certificate present, but when there is more than one, we will not trigger auto login if the certificate is not already recognized.

Comment 2 Alexander Zeijlon 2025-02-11 09:16:51 CET

Right now we don't have a mechanism for remembering default certificates for multiple cards, the variable "CERTIFICATE=<some fingerprint>" only stores the latest certificate used.

We may want to look at adding a bit more handling here in the future, to make things a bit more convenient in scenarios where multiple users share e.g. a workstation or terminal.

Comment 7 Alexander Zeijlon 2025-02-11 13:49:23 CET

> MUST:
> * Users should be able to log in automatically using a smart card when more
>   than one certificate is listed in the client.
Auto-login will trigger if there is a "default" certificate stored in the client config (this is stored when you click connect, first time using a cert.). If there is nothing stored, the client will not auto-login, but instead wait for the user to make a choice.

> SHOULD:
> * The client should not attempt to log in automatically if a default
>   certificate has not been stored for the used smart card.
In this case, the client waits for the user to make a choice.

> * The client should be able to handle default certificates on a per-card-basis.
This has been broken out into a separate bug, See bug 8516.

> EXTRA:
> * The smart card options dialog should be easily accessible from the main
>   window when smart card authentication is enabled.
The goal of this criterion was to keep options "shallow", such that you don't have to look for settings relevant for your auth method in sub-sub-sub-menus. This was skipped for now, to not risk making the GUI feel inconsistent.

> * The client should be able to provide more detailed smart card information
>   when requested by the user.
A variation on this criterion was broken out into a separate bug. See bug 8517.

Comment 8 Adam Halim 2025-02-17 16:17:02 CET

Tested client build 3810 on Fedora 40, macOS 15 and Windows 11.

Could verify that auto-login works as described in comment #7:

When using a smart card with multiple certificates, auto-login will be triggered if you've used the certificate for the previous connection. If you switch smart card, but don't log in, and then switch back, you will still auto-login. This is a nice convenience compared to how it worked before.

> MUST:
> ✅ Users should be able to log in automatically using a smart card when more 
>    than one certificate is listed in the client.
Indeed, if a certificate was used for the previous connection, it will now be used to automatically log in even if there are multiple certificates on the smart card.
> SHOULD:
> ✅ The client should not attempt to log in automatically if a default 
>    certificate not been stored for the used smart card.
> ❌ The client should be able to handle default certificates on a per-card-basis.
If a default certificate has not been stored (or if there is no match between the stored and the current card), you won't get an automatic login. As mentioned, this does unfortunately not work on a per-card basis.
> EXTRA:
> ❌ The smart card options dialog should be easily accessible from the main 
>    window when smart card authentication is enabled.
> ❌ The client should be able to provide more detailed smart card information 
>    when requested by the user.
The reasoning in comment #7 regarding fair.

Closing.