F5 iRules Data Plane Programmability > 3. Securing your application with iRules > 3.1. Securing your Applications with iRules Labs Source | Edit on

3.1.4. Lab 4 - Client Certificate Inspection¶

3.1.4.1. Scenario:¶

Your company uses smart cards for two-factor authentication. Users access different resources from a single url and need to be given access to those resources based on the properties of a client certificate. Users have physical smart cards and software-based client certificates and authentication decisions will need to be made based on certificate attributes.

3.1.4.2. Requirements:¶

BIG-IP LTM, web server, client browser, SSL server and client certificates

To meet the business’s objectives while still maintaining a strong security policy, an iRule solution must meet the following requirements:

inspect certificate attribute to give access to correct resource

3.1.4.3. Certificates:¶

Certificates and keys are provided for you in the lab, but here are test certificates and private keys.

CA certificate (f5test.local)

Server certificate (www.f5test.local)

Server private key

Client certificate (user@f5test.local)

Client private key

3.1.4.4. Baseline Testing:¶

Prior to defining a solution, validate that users do not have the correct access.

From the client work station, ensure you have access:

curl -kv https://www.f5test.local.
You should have full access to the url.

3.1.4.5. The iRule¶

F5 iRules have complete access to the x509 properties of a client certificate during that authentication and can look at the attribute of the certificate to make decisions.

when RULE_INIT {
    set static::debug 1
}
when CLIENTSSL_CLIENTCERT {
    # Example subject:
    # C=US, O=f5test.local, OU=User Certificate, CN=user/emailAddress=user@f5test.local
    set subject_dn [X509::subject [SSL::cert 0]]
    if { $subject_dn != "" } {
        if { $static::debug } { log "Client Certificate received: $subject_dn" }
    }
}
when HTTP_REQUEST {
    if { [HTTP::uri] starts_with "/" } {
        if { $subject_dn contains "CN=user.f5test.local" } {
            HTTP::uri /headers.php
        } else {
            reject
        }
    }
}

3.1.4.6. Analysis¶

The above iRule inspects the x509 subject value in the client’s certificate and makes an access decision based on that value. In this very simple example, a specific set of users may access different corporate resources hosted behind the same VIP.

3.1.4.7. Testing¶

On the BIG-IP, go to Local Traffic->Profiles->SSL->Client. In the Client Authentication section of the client SSL profile Lab4_Clientssl, set Client Certificate to Require, assign f5test.local to the Trusted Certificate Authorities option, and click Update.
Test accessing the URL https://www.f5test.local from the client. First do not include the client certificate:

curl -vk https://www.f5test.local
You should receive a failed handshake error. Try again, but include the certificate:

curl -vk --cert /etc/ssl/certs/f5test.pem https://www.f5test.local
You should now be able to pass through to the application.

In the Resources section of the f5test_local virtual, add the Lab4 irule.
Watch the log file on the BIG-IP:

tail -f /var/log/ltm
Access the URL again from the client:

curl -vk --cert /etc/ssl/certs/f5test.pem https://www.f5test.local
You should now get a different response page. Notice the Client Certificate log message on the BIG-IP.

Previous Next