Skip to content

concept: certificates: authentication

Cornelius Kölbel edited this page May 3, 2015 · 2 revisions

Authentication

work with /validate/check

The certificate token can either act like a challenge response token or like a time based token.

Challenge Response

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.

Time based

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.

Old ideas

Authentication is usually performed against the application. But maybe it could also be performed against privacyIDEA by adding an additional controller

/validate/certcheck

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>

(see https://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslverifyclient)

The 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)

You can’t perform that action at this time.