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.