A device control Web-Server such as the Barracuda Embedded Web-Server is an ideal platform for building management consoles for embedded devices. The ubiquitous HTTP protocol, backed up by the Internet infrastructure, makes it possible to control and supervise a device in real time from basically anywhere.
We have a small demo program, which is a multi-user secure web based file manager. We suggest that you download and try this demo program. The demo program is a Windows NT/XP executable.
A device that is constantly connected to the internet needs to be protected from being used by unauthorized users. Internet security can be divided into the following categories.
The web-infrastructure has well defined API's for all of the above security mechanisms. The Barracuda Web-Server implements and makes it very easy setup a protection mechanism for your embedded device. All browsers today implement the above security types. Thus, by piggybacking on the well defined web-security mechanisms, your device can be configured with advanced security control in no time.
It is needless to say that the above security mechanism would be very hard and time consuming to implement if you use a proprietary protocol for controlling your device.
It is suggested that you read the Introduction to Barracuda whitepaper before continuing with this whitepaper.
Eavesdropping and modification of data is prevented by using a Secure Socket Connection (SSL). SSL is the recommended method for protecting sensitive information.
Creating a secure socket listener object is similar to how we created an insecure socket listener object in the device control white paper.
A detailed explanation of how to use and initialize the SSL engine is outside the scope of this article. Please see our SharkSSL stack for more information.
The HTTP protocol has support for two authentication mechanisms, Basic Authentication and Digest Authentication. The Barracuda Web-Server has support for Basic and Digest Authentication. The Web-Server also supports form based login.
Basic and Digest Authentication sends a HTTP challenge command to the browser. The browser will then open a pop-up window, where the user can enter a user name and a password.
A weakness in the Basic and Digest Authentication mechanism is that the server cannot customize the login pop-up window, thus both Basic and Digest Authentication is considered to be less user-friendly. It is today more common to use FORM based login in conjunction with SSL and this is also our recommended login method.
Basic, Digest and Form based logins in the Barracuda Web-Server are implemented by using a persistent session object. Many other embedded web-servers do not have persistent session handling, thus they do not give you FORM based login as an option since FORM based login requires persistent session handling.
One must have an understanding of principals and roles for understanding how the authorization mechanism works. A principal basically identifies an entity that can interact or perform work in a system. It can be a person, company - just about anything in fact.
A role groups certain actions together, and we can then specify certain principals having particular roles, thus giving those principals clearance to perform the action.
This is similar to a concept of users and groups in a UNIX system, where users are generally people that may access the system, and groups represent the position that users can hold. For example, a company system may have a user called Allen Smith, who belongs to the group, human resources.
Thus an authenticated user might not have clearance to perform certain actions. The authentication and/or authorization process may be seen as:
Authentication and authorization is performed on a directory level in the web-server. A user might first be asked to login when descending into a directory branch. When the user has successfully been authenticated, the user's principal is checked with the directory node's role. If the user is part of the role, the user is allowed to access the directory. A directory hierarchy can be setup to be more restrictive as the user is descending into the sub-directories thus the user might be denied access further down the directory hierarchy.
We must first explain how the virtual file system works before we can further discuss how to use the security mechanism in the web-server.
We briefly mentioned the virtual file system in the device control white paper, where we explained that HttpDir is the directory node and HttpPage is the page node. An instance of the HttpDir class can contain sub-directories and/or pages and this is how the directory hierarchy in Barracuda works.
One of the unique features of the HttpDir class is that its functionality can be overloaded, thus by inheriting from the HttpDir class, one can implement unique features for each directory node. Barracuda comes with a number of pre-defined classes that inherit from the HttpDir class.
Two very useful classes, which inherit from HttpDir are:Now let us assume that the Smith family wants to setup a web-server with a family picture album and with a number of archived documents. The archived documents will not be changed, so the Smith family decides to zip the archived documents into a zip file. New pictures might be added to the album when available so a zip file is not a good solution. The Smith family decides to use a DiskDir for reading the photo album.
The Barracuda virtual file system is set up with a root directory node. The root directory is setup with one instance of the DiskDir class and one instance of the ZipDir class.
A browser requesting documents from the server will see the various HttpDir nodes in the virtual file system as a coherent directory tree. From the clients perspective, the virtual file system can bee seen as the following:
For example, an URL such as http://Smith.com/pictures/p1.jpg makes the DiskDir object search its root path for p1.jpg. The root path is setup when the DiskDir object is created. It could be, for example, "c:\Documents and Settings\users\My Documents\"My Pictures" if run on a Windows machine.
For the above directory structure, a security manager is constructed such that only family members can access the "ArchivedDoc" and the "private" directory. The "picture" directory is for public access. The security manager is also setup such that only James is allowed to access the "James" directory and James mother and father are the only ones that can access the "MomAndDad" directory. We will discuss how to install a security manager later.
A virtual directory structure can consist of many HttpDir instances and of specialized types that sub-class and overload the functionality in the HttpDir class.
A virtual directory structure can be created manually as we did in the device control white-paper or be automatically created by the powerful host tools that come with the Barracuda Web-Server.
We used the CSP compiler in the CSP tag language white-paper for compiling the hangman game. What we did not explain is that the data file produced by the CSP compiler contains information about the relative path to the page. You can think of this data file as an object file. The CSP linker links all these data files together, calculates the internal offset positions and produces two files.
The possibilities with the virtual file system are almost endless. In this article, we have limited ourselves to covering only the basics.
The Barracuda security manager is a collection of a number of classes. It should be no surprise that the security functionality is installed in the virtual file system and that a specialized version of the HttpDir type overloads the base functionality by adding authentication and authorization to the directory node. The sub-classed HttpDir class is called AuthenticateDir. The AuthenticateDir class is just a few lines of code. All of the security related logic is kept in a number of classes that is referenced by AuthenticateDir.
The AuthenticateDir service function:
The AuthenticateDir class can easily be extended to perform customized security checks. For example, one could bypass the security manager if the request is from the local network or prevent certain domains from even accessing the directory.
One could also create a simple filter that denies the request if the request is not using a secure channel (SSL). The service function could either send back a response message that the client must use a secure channel, or the service function could automatically redirect the client to a secure channel.
Web-security is a complex and important topic. This article has given you an introduction to the Barracuda security mechanism and the virtual file system. The Barracuda security mechanism models the security mechanism in J2EE, though in a simplified form. Many good books can be found that cover web-security and especially the J2EE security mechanisms. We also discussed the benefit of using a custom FORM login instead of using Basic or Digest HTTP authentication. Our BarracudaDrive web file manager Windows demo has an example of a customized FORM login, which clearly demonstrates the user friendliness of a customized login.