The DreamFactory Services Platform (DSP) was designed from the beginning to be a very secure way for an enterprise customer to host mobile applications. This blog post covers security benefits on the server side and at the client, and towards the end we discuss the advantages of our user roles and permissions system.
.png?t=1527092313664&width=230&height=153&name=mobile-security_(2).png)
From the server side, you can install a DSP on your own cloud computer or data center. The DSP software package includes a complete LAMP Stack with PHP and a dedicated MySQL database that can be installed on any Linux virtual machine. This allows a company to use the same deployment and management practices for a DSP that they are already using for other applications. They can monitor usage, make backups, control cost, configure firewalls, and deploy applications with familiar tools and systems.
The open source nature of the DSP code base is also designed for security. An open source product has “many eyes” on the code base. We have signed up for third party security audits as well. DreamFactory Software has a team of engineers adding new features and looking for security problems on a regular basis. The latest version of the software is available from us at various cloud marketplaces. Since we are not hosting your application, there is no risk of DreamFactory losing your data. You do not need to worry about how we manage our data center, or how we keep your data separate from other customers.
There are aspects of the service architecture that also lend themselves to security. The service architecture has a single point of entry, so all service calls pass through this gateway. We have written the code in the latest version of PHP, the most widely used web programming framework in the world. The use of PHP helps with issues like buffer overrun attacks. The SQL interface completely decomposes and recomposes all query strings to prevent SQL injection attacks as well.
When a user signs on to a DSP they receive a session ID, which is securely managed as a browser cookie in an HTML5 application, or as a transient local variable in a native application. All network transactions are conducted over HTTPS, thus adding the security capabilities of SSL/TLS to standard HTTP communications. The DSP also implements cross-origin resource sharing (CORS) support and a white list that controls which domains can use the platform. This enables any website or domain to use the platform services if desired. By default CORS support is turned off and the services are only available from the originating host.
The DSP service interface enables automated or manual data synchronization with other databases or external partners as needed. A special user role could be created for the DSP that grants access only to required database objects. This allows an enterprise to construct a “data firewall” where sensitive data can be moved in or out of the DSP as needed. This data is exposed to mobile users, so even if the DSP database is compromised, there would be no way to gain access to the master database.
From the client side, each DSP comes with a complete and comprehensive services palette. This makes your mobile application somewhat future proof: there is no need to re-engineer the backend services for every new feature at the client. Our user management features are also very extensive. Single sign-on, user roles, guest users, open registration, password resets, email services, email templates, and password hashing are all carefully implemented.
One special security feature for users is that administrative updates to user roles and permissions are instantly reflected in the current session. For example, if a user is inactivated his session becomes invalid immediately. This provides a more secure environment for people entering or leaving the company and for lost devices or security breaches.
Each DSP also contains some high level security features for controlling which users see which data, services, and applications. This is very useful for segmenting the user base with different roles. The information that a sales or marketing person might see can be different from a project manager or company executive. This capability implements a higher level of security that prevents accidental data loss or disclosure of sensitive information.
Multiple applications can be hosted on a single DSP, and the administrator can create user roles to control which users see which applications. For example, a project manager would see a Gantt chart application, individual contributors would see a project calendar, and executives would see a report generator. The entire suite of visible applications can be adjusted based on appropriate user interest and role.
User roles also control what database objects are visible. This enables people to use the same application in different ways. For example, some people might see all data as read only, while others have the rights to create or delete data. The application can detect these permissions for a particular object at runtime and make various options available or inactive as needed. This capability also allows information to be hidden from certain groups. For example, individual sales people might not have access to salary information, while this data might be available for managers or executives.
Roles have the ability to enable or disable individual services as well. This controls access to 3rd party services that have been integrated with the DSP. One popular service is BLOB storage, these are binary documents stored locally on the DSP server or remotely in S3 or Azure. Each service can specify the external credentials to the service and also the access root of the folder tree. This enables each user role fine grained access to multiple document repositories.
The services have another useful capability. Various URL parameters and HTTP headers can be specified in the service object. This information is entered by an administrator and securely stored on the DSP server. Once the user enters their single sign-on credentials, they have controlled access to these external services as enabled by their user role. This capability removes the need for the client application at runtime to store any master credentials to external services. Another benefit of this architecture is that external services can be activated, deactivated, or redirected without changing client software.