In my first post here in this security blog series, I explained how we do threat analysis and how we map potential security threats to software architecture. With this second post, I would like to share with you a more technical view of security. Get ready to roll your sleeves up for this hands-on session on securing an Internet of Things (IoT) application.

The first thing I would like to introduce is how to secure a document server. Please refer to the following illustration:

Secure content server

Access to a content database over an HTTP server from a single-sign-on (SSO) application

In our particular case this server is used to serve specific human readable documents. But it could also be used to gain access to other files such as java script files or specific dlls. So in an IoT context, any client out there could use this infrastructure to get secure access to files on this server. If we are talking about the Internet of Things, each thing would have to log in only once to gain access to the content database.

I’m going to explain this architecture based on our specific solution. In our case the server holds various documents of high economic value, though it is accessible over the internet. For a better understanding, the following background is helpful. Of course, only authorized persons should have access to the document server. Since the whole client application is single–sign-on, there is no option for an additional username-password dialog in order to secure certain documents when loaded from the server. The document from the server is accessed via the client’s software, which already has a username-password authentication mechanism in place. Since the document server is a pure HTTP server (Apache), a web application service is in any case not an option for user authentication.

How best to secure such an architecture?

We have realized several security gates. First of all, we put in place basic security for the communication channel by applying SSL. But this is pretty obvious. Additionally, we implemented a special username-password authentication. It is linked to a valid key that is generated within the application – a necessary step, since the content server is agnostic of the user logged in to our client. As a result, a combination of username and key is used for authorization, with the key representing the password. To prevent hijacking of the user’s identity, of course the key is encrypted using a hashing algorithm. Username and hashed key are stored in a separate database – with read access only for the document server. Database access from the document server is done using the mod_authn_dbd module in the Apache server. See the configuration in place:

# core authentication and mod_auth_basic configuration for mod_authn_dbd
 AuthType Basic
 AuthName "YourName"
 AuthBasicProvider dbd

# core authorization configuration
 Require valid-user

# mod_authn_dbd SQL query to authenticate a user

The user is specified for database authorization first by using the AuthName parameter, and second by specifying the sql statement to select the hashed key (password) from the database. The username that was passed to the document server is used as a parameter. If the returned key matches the key that was passed to the document server during the request, the user is allowed to download the requested document. For more details about mod_authn_dbd, please visit

Now it’s your turn: Which details of realization are you interested in learning more about?

About The Author

Thorsten Bux

As Bachelor of Science in Media and Master of Science in Application Architecture I started at Bosch Software Innovations as software developer in 2009. Currently I'm project leader for various Internet of Things (IoT) projects. I am strongly involved in the possibilities of ubiquitous computing and the IoT.

9 Responses

  1. Jamal Sutton

    The document root directory under which the current script is executing, as defined in the server’s configuration file.

  2. Brian Taylor

    The Laboratory for Computer Science Research has set up a Web-based Distributed Authoring and Versioning (WebDAV) server. The server is set up to allow remote access to all of users’s files stored on CS public File servers (Fac/Res/Grad/UG/iLab/FilerTemp) using a WebDAV client on your computer and mobile devices such as the iPhone, iPod, iPad, Android Phone and Black Berry.

  3. Roscoe Bates

    column to check and indicate to the HTTP client (browser) if the browser can use a previously cached version of the document. This reduces network traffic and improves server performance.

  4. Pearlie Valenzuela

    Requiring authentication defends against invalid users directly accessing the repository, but does not guard the privacy of valid users’ network activity. See the section called “Protecting network traffic with SSL” for how to configure your server to support SSL encryption, which can provide that extra layer of protection.

  5. Thorsten Bux

    Hi Jamal,

    sorry for my late response. I read your comment several times but I could not figure out what you mean.
    Is you comment an actual question?
    It would be great of you could rephrase it for me.

  6. Thorsten Bux

    Hi Roscoe,
    I like your suggestion on how to improve the performance using such a dirty flag. We actually used a client written in Adobe Flex. This client does such a check on his own using the checksum of the document from the cache.
    Your idea would require a bit more back-end logic but would be really good for thin clients.

  7. Thorsten Bux

    Hi Pearlie,

    thanks for your comment. You are right a SSL protected connection is needed. Otherwise the content could be intercepted. For me that was pretty obvious, that is why I just mentioned it in one short sentence in the article.

  8. Emily V. Short

    Because of the way that Basic authentication is specified, your username and password must be verified every time you request a document from the server. This is even if you’re reloading the same page, and for every image on the page (if they come from a protected directory). As you can imagine, this slows things down a little. The amount that it slows things down is proportional to the size of the password file, because it has to open up that file, and go down the list of users until it gets to your name. And it has to do this every time a page is loaded.

  9. Thorsten Bux

    Hi Emily,

    you are right that the verification has to take place for every document and every image. We have to chosen this kind of architecture because it was mandatory to provide the documents using a pure HTTP-Server. However we made performance tests to evaluate the response time for the documents and it was always acceptable.
    The actual access time of the password was also pretty good. That is the case because the password is accessed from an Oracle database and not from a file. So this speeds up things again.


Leave a Reply

Your email address will not be published.