Authentication is the act of showing proof of the user's identity. A user is asked to login to the server by providing a username and a password. The server compares the username and password with the username and password stored on the server. The user's credentials are typically stored in a database file on the server which can be anything from a simple text file to a SQL database.
The Barracuda Application Server (Lua API and/or C/C++ API) and the Barracuda Web Server (C/C++ API) decouples the authentication logic from the actual web pages. You can think of the authentication management as an umbrella that covers all or a subpart of your web application. The decoupling makes it easier to prevent security mistakes when designing applications that require authentication and authorization. The following provides a general introduction to authentication and authorization. You can navigate directly to the Lua documentation or C/C++ documentation if you are already familiar with the concept of authentication and authorization.
This document provides a high-level overview of authentication and details how to use the server’s built-in authentication logic or create your own. It explains how to use an HttpDir - Virtual File System node to implement an umbrella of security across a set of pages. The guide covers multiple authentication types, including Basic, Digest, and Form-based, enabling flexible and secure access control for your web applications. See the example Single Sign On for how to create a custom authenticator.
The HTTP protocol defines a simple framework for access authentication schemes. The assumption is that a certain group of pages, usually referred to as a protected realm or just a realm, should only be accessible to certain people who are able to provide credentials if challenged by the server.
HTTP defines two official authentication protocols: Basic Authentication and Digest Authentication. If an HTTP client such as a web browser requests a page that is part of a protected realm, the server challenges the user by returning a 401 unauthorized response message. The response includes a WWW-Authenticate header which can be set to either basic or digest authentication.
The main differences between basic and digest authentication are:
Security considerations:
Basic authentication is not considered to be a secure method of user authentication unless used in conjunction with SSL/TLS. Most modern browsers support digest authentication, but you may run into problems using digest authentication when working with non browser clients such as some HTTP client libraries.
In the Barracuda Server, an authenticated user is associated with a session object that is automatically created when the user authenticates. The user is automatically logged out when the session expires.
Most HTTP clients using either basic or digest authentication remember the username and password. This means that when the session expires on the server, the client automatically re-authenticates when the server sends a 401 challenge response. Using the standard HTTP authentication schemes pose a security risk, as it can be difficult to logout a user. For example, a browser using HTTP authentication typically requires that the user exits the browser to logout. A WebDAV client such as Web Folders or the WebDAV mini redirector in Windows cannot be logged out without the user rebooting the client (i.e. Windows).
When using a non-browser client such as a WebDAV client or Web Services, it is required to use a HTTP authentication scheme. However, one can also use HTML form based authentication when using a browser as a client.
The two main reasons for not using HTTP authentication when using a browser:
Basic and Digest authentication are controlled by the browser and make it impossible for the web-designer to design their own "look and feel" login interface. Consequently, most sites today use their own form-based login. The advantage of form-based authentication is that it allows one to write custom login and error pages. The pages you create are responsible for transmitting the username and password to the web-server.
When using form based authentication, the form data is sent as URL-encoded data in cleartext over the network. Form based authentication is not considered a secure method of user authentication unless used in conjunction with SSL/TLS. It is, however, possible to include JavaScript code that encrypts the form data before sending it to the server, thus avoiding having to use SSL.
The Barracuda Server supports basic, digest, and form based authentication. The server enables you to interact with these objects such as providing you with an easy integration to a user and password database.
The Barracuda Server supports the following authenticator types:
The Lua "default" authenticator, which is called "Authenticator" on the C side, makes it possible to use a mixed environment for authentication. Standard Web-Pages can use form based authentication, and AJAX calls can use either Digest or Basic authentication. The default is form based authentication. The client can request the authentication type by setting the HTTP header Authenticator or PrefAuth to either "digest" or "basic".
The default authenticator defaults to Digest authentication if:
The HTTP specification defines a mechanism in which the browser keeps track of the user's credentials in a realm. The browser can accept more than one realm from a server, thus providing a basic means of authorizing users.
All directories installed in the Virtual File System (VFS) can be associated with an authenticator. Each directory can have its own authenticator. For example, a WebDAV directory can use the WebDAV authenticator, and a "resource reader" can use the default authenticator. Several directories can share the same user database, but it is also possible to have multiple user databases such as one user database for each directory.
A login tracker can be associated with an authenticator as an optional security enhancement. A login tracker keeps track of failed and successful logins and their IP addresses.
A login tracker prevents dictionary and brute force attacks. A dictionary attack consists of trying "every word in the dictionary" as a possible username - password combination. A weak password may be easily cracked if the authenticator is not keeping track of the number of failed logins. This is where the login tracker comes to the rescue. The login tracker keeps a configurable size ram database of the users attempting to login. The user can be banned if too many login attempts are made.
A login tracker can be associated with an authenticator created by Lua code, but the actual login tracker code must be initialized by the C/C++ startup code. A C/C++ developer can either create a customized login tracker, by using the provided login tracker API's, or use the default login tracker. The default login tracker adds Lua bindings for fetching login tracker information.
It is possible to create a basic means of authorizing users by providing multiple authenticators in the Virtual File System. Authorizing by using multiple authenticators may be sufficient for basic applications, but most applications will require a more fine grained authorization mechanism.
In addition to authenticating users, the Barracuda Server also makes it possible to authorize the user. Authorizing a user takes place after the user is authenticated. The Barracuda Server authorizes the user for each resource accessed.
For each resource accessed, the authorizer can check if the user has access rights to perform the requested operation. The operations that can be classified by the authorizer are the HTTP method types. The HTTP protocol defines a number of methods such as GET, POST, PUT, etc.. For example, the user may have access to read a resource (GET), but not write to the resource (PUT).
If you don't need to interface with an existing user database and plan to store a user database in local persistent storage, we recommend using the JSON-encoded authenticator database created with ba.create.jsonuser(). For Xedge or the Mako Server, we strongly recommend using the TPM-protected version, which securely encrypts the user database. Refer to the TPM API and ba.tpm.jsonuser() for more details.
HTTP
Session Cookie
Basic Authentication
Digest Authentication