Offload Authentication with iRules

As the applications being driven by webservers become more and more complex, Applications Developers are always looking for ways to increase efficiency or do away with unneeded processing time. One of the ways that I believe that Applications can do that is by making use of an intelligent network infrastructure. Assuming the network that is delivering the applications is an intelligent, application aware one, there are many things that Developers can do to help offload some of the work their code would normally have the web server processing to the network level.

One such thing that can be offloaded in many cases, is authentication. By leaving the heavy lifting of ensuring only authorized users are acessing the application(s) in question to the network, the web server is free to use its processing power to deliver the application it's hosting faster and more reliably. This is especially true in highly taxed environments.

The example below shows one way in which this can be done. This example uses an HTTP cookie to store authentication information for each user, which is a common practice for many applications. It is getting the data to be stored, I.E. whether or not a user is properly authenticated, by enlisting the authentication server already in place on this hypothetical network. In this specific example, that authentication system is a Radius system, but the iRule works equally well with LDAP, tacacs, etc.

If the authentication attempt is successful, a cookie will be sent to client with the appropriate data to be stored. The next time that client tries to access the application, the AUTH cookie is present and valid, so the client will be passed immediately without being re-checked for authentication.

If it is not succesful, well, then you can decide what experience that user should have by altering the code in the "AUTH_FAILURE" section, or leave the standard 401 error message that stands there now.

In this example, the cookie name, password, domain should be properly modified for your environment.

This code comes from the DevCentral iRules CodeShare where you can find many useful iRules examples, not to mention post your own to share with the community. Just another great example of how with iRules, you can... 😉

when CLIENT_ACCEPTED {
        set authinsck 0
        set forceauth 1
        set ckname BIGXAUTH
        set ckpass 1xxx5678
        set ckvalue [IP::client_addr]
        set ckdomain .y.z
        set asid [AUTH::start pam default_radius]
}
when HTTP_REQUEST {
        if {[HTTP::cookie exists $ckname]} {
                HTTP::cookie decrypt $ckname $ckpass 128
                if {[HTTP::cookie value $ckname] eq $ckvalue} {
                        set forceauth 0
                }
                HTTP::cookie remove $ckname
        }
        if {$forceauth eq 1} {
                AUTH::username_credential $asid [HTTP::username]
                AUTH::password_credential $asid [HTTP::password]
                AUTH::authenticate $asid
                HTTP::collect
        }
}
when HTTP_RESPONSE {
        if {$authinsck eq 1} {
                HTTP::cookie insert name $ckname value $ckvalue path / domain $ckdomain
                HTTP::cookie secure $ckname enable
                HTTP::cookie encrypt $ckname $ckpass 128
        }
}
when AUTH_SUCCESS {
        if {$asid eq [AUTH::last_event_session_id]} {
                set authinsck 1
                HTTP::release
        }
}
when AUTH_FAILURE {
   if {$asid eq [AUTH::last_event_session_id]} {
           HTTP::respond 401 "WWW-Authenticate" "Basic realm=\"\""
   }
}
when AUTH_WANTCREDENTIAL {
   if {$asid eq [AUTH::last_event_session_id]} {
           HTTP::respond 401 "WWW-Authenticate" "Basic realm=\"\""
   }
}
when AUTH_ERROR {
   if {$asid eq [AUTH::last_event_session_id]} {
                HTTP::respond 401
   }
}