Forum Discussion
Kevin_Stewart
Feb 14, 2013Employee
Validation and authentication are still two different things. You've successfully validated a certificate by way of checking (at a minimum) validity dates and trust. To authenticate, or rather "assert" the identity of a user via their certificate, there are a number of ways to approach this. The easiest is probably with X509. Inside a certificate is a bundle of (text) data called X509 (or at least information arranged by the X509 standard). At a minimum there are values for subject, issuer, validity dates, and serial number. But there can also be Subject Alternative Names (email addresses, UPNs, etc.), certificate policies (what kind of cert it is - software certificate, smartcard, etc.), key usage, OCSP/CRLDP revocation URLs, and many more. These X509 values are all accessible via iRules using the X509:: commands (https://devcentral.f5.com/wiki/iRules.X509.ashx). So to get the certificate subject:
[X509::subject [SSL::cert 0]]
You can then very easily create a data group of acceptable certificate subjects and use a quick iRule in the CLIENTSSL_CLIENTCERT event to allow or block specific users/certs:
when CLIENTSSL_CLIENTCERT {
if { [SSL::cert count] > 0 } {
if { not { [class match [X509::subject [SSL::cert 0]] equals cert_data_group] ) } {
client certificate (subject) not in the data group - log and drop
log local0. "User presented a certificate ([X509::subject [SSL::cert 0]]) that is not in the data group - rejecting"
reject
}
}
The above is a whitelist example. You can also use other values in the certificate, as mentioned earlier.