GoZync3

Security

These are the notes for GoZync 3. Docs for the latest version of GoZync--GoZync 4--can be found here. GoZync 4 is a free upgrade and is highly recommended (hint: it's faster).

Authentication

Local files (Files on your iPhone or iPad)

It is up to you to decide if you want to require users to authenticate in to your mobile file on their iOS device. Many users will choose to use an auto-enter account and password so local users won't be asked to authenticate each time they open the mobile file. This makes more sense in synced files than others because a) the file often doesn't have any/much data in it, b) you can instruct users to secure the device with strong passwords, instead of securing the file, and c) the local file has no account information (no access) for the hosted files.

If you're concerned about theft of the mobile device, check out the Remote Wipe available here: http://www.apple.com/ipad/built-in-apps/find-my-ipad.html Note that you can also turn off "simple passcodes" in your iPhone or iPad's settings to use longer, more secure device passwords.

If you do choose to require authentication in the local file, users will be asked to authenticate when they:

Open the file.

After downloading new data from the server.

After downloading a new version of the mobile file.

and After sending a batch of records to the server.

Users will also be asked to authenticate each time they return to an open local file (such as after switching away to another app, or after closing their iPad) unless you use the fmreauthenticate extended privilege to control when users will be required to reauthenticate after not using FileMaker Go for a specified period of time. You'll likely want to add this to the privilege set in effect on your iOS Devices.

Our Recommendations: Your Mobile Files

So here are our recommendations for securing your mobile files (you do this to GoZyncMobile as well if you wish).

Secure your iOS device with a passcode.

Create an upon opening script in your file that uses Get ( ApplicationVersion ) to test if the user is on FMGo or FMPro. Run this script with Allow User Abort Off.

If they are on Pro, call the relogin script step with NO options so they need an account to use the file.

If they are on Go, call the relogin script step using an account that lets them do their work but is NOT shared with the hosted solution.

Use the fmreauthenticate extended privilege to control when users will be required to reauthenticate after not using FileMaker Go for a specified period of time. See FileMaker's Go Development Guide for more details.

When users go to sync they will be asked to log in to GoZyncHosted, and will then do so using an accounts shared with the hosted files... (see the next section)

Hosted Files

When it comes to your hosted files, your mobile file will actually first connect to an intermediary file: GoZyncHosted (here is a map of how all this work). When "pushing" this is the only file that opens. When "pulling" or "round-tripping", both GoZyncHosted and your mothership file are opened.

When the remote file hits the GoZyncHosted, you should ask for the user to authenticate. This means you should add user accounts to GoZyncHosted (GZH). GZH then sends its contents to the main solution either as part of a pull or round trip (in which case a user authenticates into your main solution) or as a script schedule, which is itself run under an authenticated account. (Learn more about automated processing.)

If you choose to require authentication in GoZyncHosted, users will be asked to authenticate:

Before downloading a new version of the mobile file.

Before downloading new data from the server.

and Before sending data to the server.

You can also use "file protection" (introduced in FileMaker 11) between the remote and intermediary files if you'd like, and/or between intermediary and the main solution.

Our Recommendations: GoZyncHosted

Though each deployment will have to consider their unique security requirements, the following recommendations offer the best user experience for working your local GoZync file.

Require authentication into the intermediary file, GoZyncHosted (GZH).

The accounts users employ to open GZH don't need to be the same as those in your your main solution if all you're doing is pushing. Though GZH will need at least one shared account... the one used by the server-side script processing your inbox automatically. If you're processing by hand, you'll simply be asked to authenticate into your solution when you process your first InBox record.

In most cases, however, you'll be pushing, pulling, and round-tripping, so the accounts created in GZH should be the same as those used in your mothership solution. This will also enable you to know *who* is syncing so you can use GoZync's scripts to filter records being pulled down.

Enterprise customers: MDM

For larger customers, Apple has a suite of Mobile Device Management (MDM) applications to help secure devices, push profile changes, pull applications and monitor password compliance. This can help more thoroughly secure your iOS devices. Learn more here: http://www.apple.com/iphone/business/integration/mdm/