The final part of my series on Design Considerations When Building Cross Platform Applications has finally come with one of the most critical components that’s commonly underestimated and/or ignored until the end of the software development lifecycle (SDLC): security. In fact, a common misperception of application security is skewed to either the server or application side of the platform rather than looking at the entire platform and securing everything. There are three core components to keep in mind when building out a mobile application and platform: authentication (including authorization), communication and data. The natural thought for a developer is to be concerned with the authentication component because that’s the area the user sees via a login page, but I’m going to outline why the other areas of security may cause more pain in the evolution of the application in the long run.
Authentication and Authorization
By default, any technical or non-technical user realizes that some magic occurs when an application is started and he/she has to enter credentials to inform the app who the user is and what he/she can do or see within the application. This component consists of authenticating a user (making sure the identity represented by the username and password is confirmed to be an active user) and authorization. Authentication can take on many variations depending on the type of application being built and the types of systems that may need to be integrated. For example, in the most common scenario, a user can use a username and password on a simple login screen. Upon sending that data back to a server, the platform will validate the user and provide a valid/ invalid reply to inform the application that the user can or cannot use the application. Unfortunately when working in the enterprise space, that is WAY too simple. Users not only need to be validated, but they also need to be given roles which inform the application which parts of the application can be used by this user and to what extent. Identity protocols like WS-Federation and SAML can provide a means by which this information can be sent to the application directly via a claim. Of course, with this approach comes additional complexity in the implementation that includes setting up a trust from the application to the identity provider and potentially redirecting a user to a separate web page to login before he/she can use the app. Because our focus is on mobile applications, the launching of a web page outside or inside the application can have a detrimental effect to the user’s experience.
Authorization comes into play when data is returned back to the application in the form of roles or claims. In many cases this level of detail is embedded within a token sent from the auth server. Authorization is the mechanism used by applications and services to determine what a user can do within the context of the application. Some common scenarios mirror the privileges commonly found on a file system: read-only, read-write and full access. Some applications will introduce additional types of roles to provide levels of privilege based on the type of user accessing the application. For instance, there are cases where a company may provide an administration console to manage users and components within a system. There would likely be several types of roles available to the company hosting the application as well as to the external customers of the application. Internally, there would be SuperAdmin, Admin and ReadOnly roles provided to various people for a variety of reasons dictated by the business. Then on the external side, there may only be two simple roles of Admin and User that may or may not map directly to the roles utilized for the internal users.
The second area of security that is often overlooked while building applications is how information is transmitted to and from the application. In most cases, a simple mechanism of using SSL to protect the data being transmitted can be sufficient as it conceals the data being sent to and from the server. However there are cases where additional measures may be required to ensure that the message being sent to the server is valid and from the appropriate sending party. One example would be submitting data to a server that reflects a user’s performance metrics. With a common browser and some basic technical acumen, a user can alter the message being sent to the server to enhance their scores or submit a false score for another user. This can be overcome by several mechanisms depending on the how much of a concern this issue may be. One mechanism that can be put in place involves adding a key to the message that is time-based and built using an algorithm only known to the server accepting the messages and the application sending them. While this does provide some level of security in the transmission of the data, a user could still figure out the algorithm and modify the messages anyway. The next method would be to encrypt data using a shared private key on the server and the application. This is a method that seems a lot like the prior method, but adds a level of complexity as it will be much more difficult for the average user to hack. There are other approaches that can go to deeper levels of encryption, callbacks and other methods, but for the purpose of this post I have only laid out a couple.
Lastly, data security is a huge issue when dealing with all types of applications, but it’s even more important in the mobile space where users may be able to bring their own devices into a corporate environment. Applications commonly use local storage on a device to maintain a level of stateful information that can be accessed in the app at various points during use. In most cases, there is a basic level of security that can be applied to that data by using built-in encryption mechanisms provided by the mobile operating systems (OS). While this is a decent approach, there may be instances where a device falls into the wrong hands and a hacker can get the data off of the device using common development tools. As a result, a new industry is booming around mobile device management (MDM) to control the software installed on devices and the data that may be stored on the devices. These tools act as the “traffic cops” that have the ability to manage the installation and uninstallation of software by pushing information to the devices to perform actions such as install, uninstall or disable. In some corporations, an MDM is required for a user to connect to any system within the corporate network. This is a the primary reason that the Blackberry was dominant in enterprise mobility for years because of the Blackberry Enterprise Server (BES) that provided a middle man in all data requests to/from the device. The MDM takes over the functionality for the BES on iOS, Android and in some cases, Windows Phone devices. It allows IT to control any interaction with their corporate controlled devices.
In the end, it’s necessary to think of security when building mobile applications because there are many ways hackers can deem your application vulnerable at any point of interaction. I have outlined several different areas that can be secured while building out the applications, but there are always ways to dig deeper when it comes to security. One of the biggest tradeoffs when building a secure application is to determine what level of security is really required. A development team can spend more time building hurdles for a hacker than actually building out functionality in the application, leaving a secure, but useless application. As an architect and lead developer it has been important for me to create a balance that makes our applications both secure, user-friendly and useful to the end user. In the case of Connections and mLevel, we have been able to apply these standards and provide secure mobile applications that can be used safely in the enterprise space.