Comment

Answers to Security Inquiry in AppTree Release 5.5

We recently received several secruity questions from a prospect located in Canada. We thoguht they asked some great questions about security in AppTree version 5.5 and wanted to share them here:

QUESTION 1) Where is the cloud-hosted (or vendor-hosted) system located geographically? In Canada, the US, or elsewhere? If backups of the system and/or data are stored in at a different site, where is that site located? These questions are necessary as Nova Scotia has privacy legislation (PIIDPA) governing the transfer of personal information outside of Canada.

We use Heroku, a Salesforce app platform, to host our AppTree Cloud. Heroku is hosted on Amazon EC2. Currently, Heroku supports Amazon EC2 US and European regions meaning that the physical infrastructure used for the EC2 Elastic Compute cloud is located in the US or Europe.

More about Heroku: https://www.heroku.com/platform

More about Heroku data center regions: https://devcenter.heroku.com/articles/regions

We use Amazon S3 for file storage. S3 is also on Amazon EC2. EC2 started offering a Canadian region just a few months a go so we can now host our S3 bucket on any region including Canada.

More about EC2 regions here: https://aws.amazon.com/about-aws/global-infrastructure/

Our AppTree Cloud does not store customer data so therefore we do not backup customer data or store any customer data on media or cloud storage. When a mobile device requests data, the request for data goes through the AppTree Cloud on Heroku, to the AppTree Connector which is usually on the customer’s network, then the connector responds with the requested data which travels back through the AppTree Cloud on Heroku and then to the mobile device. So, encrypted data transmits through the AppTree Cloud but is not stored, logged or written to a filesystem and therefore never backed up.

Our AppTree Cloud does store configuration and meta data about our applications in clustered Postgres databases hosted at Heroku. We use Heroku tools to backup these repositories.

Our use of S3 is for short term cache only. We do not back up the data on S3 because it’s not primary storage and losing the data will have no effect on the app other than it has to re-cache the data. The type of data written to S3 is limited to cached lists and attachments. A few examples of this type of data are a list of work order status values or a photo of an asset that a user has taken using their mobile device. The S3 file storage access is by encrypted API key and data is transmitted to/from S3 via HTTPS/TLS 1.2. If customers have sensitive data they do not want to be written to our S3 bucket, they should make sure the list data is not marked as cached. Non-cahced lists bypass S3 and go directly from the AppTree Connector, through the AppTree Cloud and deposited on the mobile clients.

The best way to comply with privacy regulations would be to not include personal identifying information in the data being used in the mobile apps.

QUESTION 2) Can the mobile app be configured to support authentication using the institution's on-premise directory and/or single sign-on (SSO)? i.e. users would log in to the app using their NetID and password. Dalhousie uses Active Directory and supports ADFS, CAS, and Shibboleth as SSO mechanisms.

Yes, we have direct support for CAS, Shibboleth and LDAP. When configured for external authentication through CAS or Shibboleth, the user is redirected directly from their mobile device to Shibb/CAS and then back to mobile. The authentication route doesn’t pass through the AppTree Cloud.

QUESTION 3) Is the data encrypted:

a. In transit between the end user device (ie the mobile app) and the cloud-hosted system (e.g. HTTPS) (this is usually considered "must-have")

Yes, 100% of all transmissions are HTTPS/TLS 1.2 encrypted.

b. At rest within the cloud-hosted system (i.e. database encryption) (this is usually considered "nice-to-have")

We do not store data on our AppTree Cloud. We do store data on the mobile devices. The data on the mobile devices is encrypted at rest.

AppTree mobile clients use Realm Mobile Database.

https://realm.io/products/realm-mobile-database/

QUESTION 4) A couple of questions specifically for AppTree, based on their architecture diagram:

a. Can the SDK/app server be hosted by the vendor instead of on-premise by the institution?

Yes, we can host the SDK. We use Toronto based hosting center Clarity for our Canadian customers.

http://www.claritywebhosting.com

However, for best performance and optimal security, we recommend deploying the AppTree Connector/SDK on the customer’s network.

b. Is data encrypted in transit between the cloud-hosted system and the institution's on-premise SDK/app server? E.g. HTTPS. (This would be a must-have)

Yes, 100% of all transmissions are HTTPS/TLS 1.2 encrypted.

When installing the AppTree Connector on the customer’s network, a ’secret’ key is generated. This secret has to be registered with the AppTree Cloud and then the connector will only communicate with the cloud. We ask our customers to block access to the AppTree Connector at the firewall to everything except the static IP addresses we provide for our AppTree Cloud. Between the firewall, the HTTPS in-transit encryption and the use of a secret API key, access to the AppTree Connector is kept secure.

c. Are there any other software requirements for the SDK/app server, aside from the web server software (i.e. Tomcat or WebLogic, and presumably a Java JRE and a database JDBC driver)? Any other third-party components that would require separate licensing?

No web server is required. Everything is self contained in the AppTree Connector, including the HTTPS server and the JDBC connection pool. The only thing we need on the server is Java JDK 8.

Our AppTree Connector is built using the Play Framework.

https://www.playframework.com

Comment

Comment

AppTree Revolution OS and Device Compatibility

AppTree Revolution OS and Device Compatibility

This post has Operating System and Device compatibility information for AppTree Revolution's Enterprise App Platform.

You can run AppTree Mobile apps on Android and iOS Devices. See below for more specific compatibility information.

Android Devices

Release 5 supports Android 4.3 or higher.

There are over 12,000 unique Android devices and we are not able to test on each device. We do inventory the most commonly used Android devices including the Samsung Galaxy line of phones and tablets and the Google Nexus devices. If you have an Android device you want to standardize on, we strongly suggest you purchase a single unit and do your initial testing on that device to ensure it’s a good platform for AppTree. If you do select a device, please let us know which make and model and we will attempt to add it to our device library for QA purposes.

iOS Devices

Release 5 supports iOS 8.2 or higher.

Any iOS device purchased in the last 2 years will work very with our software. We do not recommend you use the software with older iPod touches because the camera quality on these devices can make barcode scanning difficult. Some older Apple devices, such as the iPhone3GS and iPhone4 are not fully compatible. The iPhone4S and later devices are compatible with Release 5. The original iPad version 1 is not compatible. The iPad2 is mostly compatible, but some models do not have a rear facing camera making scanning difficult. We recommend the iPhone5 or later, iPad3 or later and the Generation 5 or later iPod Touch devices.

Refer to this document for specific device compatibility:

https://www.apple.com/ios/whats-new/#compatibility

Compatibility Chart






AppTree Revolution iOS Android Notes
Release 3 iOS6.x to iOS8.x 2.3 and 4.0 Release 3 is NOT compatible with iOS9 or Android 5
Release 4 iOS7.x to iOS9.x 4.0 and higher (API 14+) Release 5 is compatible with iOS9 and Android 5
Release 5 iOS8.2 and Higher 4.3 and higher (API 18+) &nbsp


Future Client Support

In 2016, we will be releasing a web client so you can run your R5 mobile apps in a web browser. The primary purpose for this is desktop use, however the web client will be fully responsive so you can use it on mobile device browsers to expand support beyond the native iOS and Android clients.

Microsoft has announced that Windows 10 will support native Android apps. It is our intention, once Windows 10 for mobile is released, to certify our Android client for that OS so you can run our apps natively on the latest Windows mobile devices.

Similarly, BlackBerry 10.2 has announced support for Android 4.2.2 Jelly Bean apps. As soon as BlackBerry extends support to 4.3 or Android 5, our intention is to certify AppTree Revolution R5 on that OS.

Comment

Comment

AppTree Revolution Release 5 Architecture & Deployment Options

AppTree Revolution Release 5 Architecture & Deployment Options

To better understand the changes in the Release 5 architecture, we’ll first revisit how the previous Release 4 is deployed.

Release 4 Deployment Options

In Release 4 and earlier, AppTree Software’s app platform was available as an on-premise enterprise software package. It consisted of an application server, web services and custom APIs to communicate with existing enterprise software, and a database schema that was placed in the customer’s existing enterprise database.

There were three common configurations depending on customer security requirements:

a. Customer could install the AppTree Revolution app server in their DMZ and allow connections from the public internet. R4 Public Internet

b. Customer could install the AppTree Revolution app server in a secure segment of their network and install a VPN client on each mobile device. R4 VPN

c. Customer could install the AppTree Revolution app server in a secure segment of their network and require that mobile clients only connect from a secure wifi access point that was within the secure network. R4 WiFi

In most cases, AppTree Revolution customers had to compromise between access and security. In some cases, use of the platform was heavily restricted in order to comply with existing security mandates at a given customer site.

Security and the Release 5 Architecture

Release 5 was redesigned to offer additional deployment options. While it can still be installed on-premise and run completely on customer owned & supported hardware and networks in configurations similar to R4, the new R5 platform can now be run in the ‘cloud’.

This is a significant improvement form a security perspective. The customer no longer has to expose their network to the public internet in order for mobile devices to access R5 apps from cellular data networks and non-secure Wi-Fi networks. In Release 5, AppTree Revolution Cloud can be used to allow access to your users from public networks, but restrict access to your network to just a single secure point of entry form a single source. R5 Architecture

Another significant improvement in the R5 architecture is separating the AppTree Revolution configuration data from your enterprise software database. AppTree Revolution uses Oracle Corporation’s Secure Cloud Database Services for our metadata repository. This means that the R5 application server never has to connect directly to your database. All connections to your data can be made through your web services and APIs, giving you an additional layer of control and security. In addition to the deployment architecture, R5 has been re-engineered to be more secure at the platform level:

  • We encrypt traffic end-to-end between the mobile clients and the app server.
  • We prevent our mobile clients for launching on rooted or jail broken devices. This is to stop a hacker from installing software on the mobile client to read packets being sent to and from the application before they are encrypted by the transport layer.
  • We use a ‘morphing’ API key system so that in the event that the device security is compromised and network traffic is decoded, the internal API key used to communicate with the server is only valid for a single call. As soon as it’s viewed, it’s already expired and a new API key is use.
  • We do not store user credentials on the mobile device. In previous releases, we stored user credentials in the ‘keychain’ on the device. Even though this was encrypted, it was still a potential security threat in the event the keychain was hacked. In Release 5, we generate an encrypted token and that the only thing related to the session credentials that stored on the device.
  • We use code obfuscation practices so that if the compiled application is cracked open using application development tools, the global variables are disguised to avoid leaving hints about how the app communicates.

AppTree Revolution complies with the best practices and recommendations described in detail by the The Open Web Application Security Project (OWASP). More information about these practices can be found at www.owasp.org.

To ensure our security measures are working as intended, we have the app platform penetration tested by a respected and internationally recognized security lab. We then continually update and improve our security mechanisms based on their feedback and changes in exploits and hacking techniques.

Comment

Comment

AppTree ♥ Dart.

We at AppTree Software are in love with Dart. It's allowed us to take traditionally non-web programmers, including myself, and make them productive in the web world.

I'm a native mobile developer for iOS and Android, Javascript is is not my strong suit. When we decided to embark on a big web project, I started looking for options. I probably did a Hello World app in 5 different web technologies, but when I came across Dart, and specifically AngularDart, it felt very familiar. It's modern, has a great toolset, supports the latest web standards, and most importantly allows you to build a web application like I would build a mobile application.

To give you some background, we’ve built an app platform that lets users build enterprise mobile apps without coding. We’ve been referring to it as the ‘Squarespace for enterprise mobile’ . Our app builder, written in Dart, allows you to point to a web service or database, it figures out what its capabilities are, and then you can start creating features in your mobile app without doing any coding. This includes mapping, calendars, creating and updating records, searching, barcode reading, attachments, and some enterprise specific widgets for things like time entry, inventory, dispatching & scheduling. It’s 100% configurable by the user. When you publish your app, you end up with native apps, that work off-line, and can run on any Android or iOS device.

See a sneak peak of the AppTree Builder here.

We are now adding a 3rd client, we call "AppTree Anywhere", so you can run the applications you built in any web browser. We are using AngularDart as the technology behind our builder and the Anywhere client. Rather than take the approach of creating an HTML app that can run on mobile, using Dart, we are taking mobile apps and running them on the web.

Working in Dart is fast. We wrote the initial working version in 3 weeks, showed it to some customers, and based on their feedback rewrote the entire project in another 3 weeks. Since then, we left the "just get something to show" phase and have been building out the production product. It’s moving really fast.

We hired a developer, just out of school, who only knew Java and some C++. She was able to pick up Dart within a month and start contributing. AppTree Software is moving to Portland in the coming months and we're looking for Dart developers in the Portland area.

Lastly, I'd like to thank everyone on the Dart team for the great work they are doing. The language and toolset they are providing is letting our team do things we would not be able to with another technology. I couldn’t agree more with Dennis Khvostionov’s recent post about Dart enabling small teams to do more:

http://news.dartlang.org/2015/03/dart-for-entire-web.html

We encourage everyone out there to seriously consider Dart for any web projects and we look forward to meeting some more Dartisans at the upcoming Dart Developer Summit

Comment

Comment

AppTree Revolution Release 4

AppTree Software Announces Release 4

In March 2015, we will deliver AppTree Revolution Release 4. R4 has new features, general improvements and bug fixes. Upgrading to Release 4 is not required, but we do recommend it. Release 4 has security improvements that make an already secure application platform even better.

To help you plan for R4, I’ve described the new features. Many of these will immediately start working for you once you upgrade. Some may require additional configuration. I’ve marked the new features with an asterisk if they have some additional steps before you can take advantage of the new feature.

What’s New in R4

Security Enhancements

In R4, users will not be able to run AppTree apps on ‘jail broken’ or ‘rooted’ devices. The reason for this is that these devices may have hacked software that can be used to inspect the communication between the app and the back-end application server. While this alone is not enough to compromise your app, it’s still not something we want potential hackers to be able to do . We’ve obfuscated the Android source code to prevent reverse engineering or to expose global variable data. We’ve implemented a sophisticated morphing API key system so the token needed to access the app server changes continually. This will prevent, even hacked devices, from intercepting API keys that could be used to compromise your app server. We’ve improved the session level security and we’ve added configuration application timeouts.

Slow Network / No Network Improvements

We’ve improved the app behavior when accessing it on a slow network or where network coverage is bad or non-existent. Prior to R4, the app would check for configuration updates and try to re-initialize every time it detected a change in the network state. This caused problems for users and disrupted the flow of the app. We changed our approach to this for a better user experience.

Built-in Problem Reporting

Any user can ‘shake’ their device to take an instant screen shot of whatever is happening in the app, annotate the image, and push a button to submit a problem report. No more taking screen shots manually and figuring out how to get them off the device.

Improved Barcode Scanning

We’ve removed the in-line scanner form the inspections widget in favor of a full screen scanner. This makes the app less sensitive to distance form the barcode. We’ve improved the integration with external handheld scanners. For instance, if you have a part request or maintenance issue feature, you can now add parts to an order by pulling the trigger on the scanner. No need to tap ‘Add Parts’ and then tap the parts field to initiate a search. You can now increment the part quantity by scanning multiple times.

Labor Approval and Timecard Improvements

We’ve added a new indicator on the calendar view of the timecard to show both regular and overtime hours right on the calendar. For each time entry, we are clearly showing the status of the approval routing. We identify which entries are new, which are pending approval, which are approved and which have been rejected.

Support for AutoCAD XREF Documents

If you have our CAD viewer enabled, you can now view XREF documents where you have a set of drawings related to each other and want to view them as one layered drawing.

Future Dates for Labor Entry

You can now configure the time card to allow future charges against some work orders. For instance, you can configure certain Stanford Work Orders, used for leave, to be charged in advance.

Inspection, Inventory and Audit Tools

We’ve completed re-designed the inspection widget that is commonly used for conducing physical inventory, audits and inspections. You can now assign areas to inspect/inventory to specific individuals so that only they can view those locations. This will help with Utility Reading features where you want to pre-assign the meter reading route or Inventory Control features where you want to assign specific shelving unites to specific employees for counting parts. You can also more easily see what has been counted, inspected or read, what you still need to do, and whether you’ve had any exceptions. You can also stop working a route, save it, and it can easily be re-assigned to someone else.

Scheduler and Dispatcher

The new daily scheduling and dispatching tool will be included in R4. This will allow you to quickly assign work to your employees, specify the day you want it done and the order you’d like it completed in. You can bulk schedule groups of work orders to individuals and even assign multiple work orders to multiple technicians at the same time. For each employee, you can browse their daily schedule and quickly make adjustments. You can also view your work orders and other resources on an interactive map.

NOTE: Scheduler available on iOS iPad Only

Other R4 Stuff:

A user can now tap on a notification to open that record directly in the mobile app.

You can display QR Codes on forms for mobile to mobile scanning.

You can now tap on a map to add a pin. Previously, you could only mark your current location.

We’ve added a new form field type for mutually exclusive responses like ‘Accept’ and ‘Reject’.

We’ve made performance improvements to the apps in general. Forms load faster, buttons are more responsive, app initializes faster.

And finally we’ve made many bug fixes.

How to Get R4

Just ask! Once we release R4, I’ll send out another announcement. You can submit a request to our help desk to schedule an upgrade. There are new features described above that may require additional services to implement.

Comment