I recently hosted an Ask Me Anything webinar on authentication and authorization in Varnish. The number of interesting questions we received confirmed that authentication and authorization is a subject that many people are interested in and want to know more about.
This blog post is follow-up from the webinar to provide answers for the most asked questions.
What’s the difference between authentication and authorization?
A user can’t be authorized unless he or she is authenticated.
A good way to frame the difference in tangible, everyday terms: Imagine you have just landed in a foreign country. You’ll first have to go through passport control and authenticate yourself. Basically you’ll have to prove, with a form of identification, that you are who you say you are. Once you have authenticated yourself, the person who has checked your identity will authorize or deny access to that specific country.
The same logic applies to authentication and authorization for HTTP requests, hence Varnish.
How do authentication and authorization work?
Usually, in an architecture where Varnish is present, the authentication part is left to an auth server, which is in charge of generating unique IDs for each end user requesting content.
These unique IDs will then be used to authenticate and authorize the user.
Varnish is useful mostly for the authorization part because, with its flexible and powerful VCL, we are able to check if the authenticated user is indeed authorized to get the requested content. This check happens by running crosschecks among different headers in VCL.
Do we need a separate authentication server?
More than one question came in asking if Varnish is capable of doing authentication, or if it is mandatory to have an authentication server as well.
Through VCL and the help of the digest VMOD Varnish can act as authentication server and generate the unique ID the client will have to present for any subsequent request.
We usually suggest that you let each piece of architecture do what it does best, meaning that most of the time it is better to have a separate authentication server.
Varnish can also communicate with any other third-party service as long as the exchange happens on an HTTP connection because Varnish doesn’t natively understand any other protocol.
Does Varnish work with Lightweight Directory Access Protocol (LDAP)?
Varnish understands and speaks HTTP only; therefore, there is no native support for LDAP or any other protocol.
A Varnish module would be the solution to this: the idea is to have a VMOD that acts as a layer between the LDAP and the HTTP protocols. Basically it would help to translate from one protocol to another and have an API accessible from VCL.
There is a VMOD on Github, which is a good starting point if you wish to write your own VMOD. Please be advised that it needs proper testing before you can be fully comfortable with it.
Is it possible to turn Varnish into an authentication portal?
Varnish, other than caching, can be used as a shield for your application, and it can in fact act as an authentication portal.
Consider this diagram. As you can see no request can be forwarded to the caching layer or the web application unless it is authenticated. No malicious requests will be able to attack your web server if they can’t bypass the authentication layer.
A very simple example of how authentication can work in VCL:
sub vcl_recv {
unset req.http.authstatus;
if (req.http.signature) {
set req.http.sig-verf = digest.hmac_sha256("key", req.http.host);
if (req.http.sig-verf == req.http.signature) {
set req.http.authstatus = "ok";
}
}
}
In sub vcl_recv we check that the signature header(unique id) presented by the client matches the signature verification header generated using the digest VMOD. This is a very simple example of how auth works in Varnish, but you don’t really need much more than this to have it working in your real production environment.
We covered more topics during the webinar, so we encourage you to watch it on demand, and if you still have questions, reach out to us if you want to know more.