concept: certificates: authentication
work with /validate/check
The certificate token can either act like a challenge response token or like a time based token.
The user tries to authenticate but triggers a challenge. The challenge is sent to the token and signed with the private key. The signature is returned and can be verified by privacyIDEA.
The signature can act as parameter pass in the normal validate/check request.
Being e.g. implemented as an app in a smartphone, the private key needs to be stored in the smartphone. This can also be used offline, since offline only the public key needs to be stored at the computer.
If there is no challenge response, the certificate token can sign e.g. the timestamp with its private key and send this as a single request to privacyIDEA. privacyIDEA can verify the signature of the timestamp.
We need to use a moving factor like the time to avoid replay attacks. The token could also make up additional data to be signed, but this alone would be prone to replay attacks.
Authentication is usually performed against the application. But maybe it could also be performed against privacyIDEA by adding an additional controller
which is only accessible with the correct client certificate. In apache we could setup an on-directory-verification:
SSLCACertificatePath <location /validate/certcheck> SSLVerifyClient require <location>
SSLCACertificatePath would contain all CAs managed by privacyIDEA.
The user then could find a credential behind this link, that he could only use, when he had a client cert. Then he could use this credential to authenticate to an non-client-certificate-aware application using this credential, which would be checked against privacyIDEA. (Many API calls)