Bug 8511 - No way to select default smart card certificate
Summary: No way to select default smart card certificate
Status: RESOLVED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.19.0
Assignee: Alexander Zeijlon
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-02-05 11:14 CET by Alexander Zeijlon
Modified: 2025-02-11 13:49 CET (History)
0 users

See Also:
Acceptance Criteria:
MUST: * Users should be able to log in automatically using a smart card when more than one certificate is listed in the client. SHOULD: * The client should not attempt to log in automatically if a default certificate has not been stored for the used smart card. * The client should be able to handle default certificates 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.


Attachments

Description Alexander Zeijlon cendio 2025-02-05 11:14:07 CET
There currently is no way of selecting a default certificate if you have more than one available on the smart card you are using.

This makes it a bit cumbersome to configure the client, e.g. if you want to be able to log in using one of many credentials on the smart card instead of a Linux username.

Right now we have the ability to apply a filter, but this is a bit technical and is likely not easy to use for end users.
Comment 1 Alexander Zeijlon cendio 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 cendio 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 cendio 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.

Note You need to log in before you can comment on or make changes to this bug.