Since the advent of FileMaker® Server 7 in 2004, FileMaker developers have been able to employ External Server Authentication for controlling Identity and Access Management to FileMaker files when hosted by FileMaker Server. Yet, either from lack of knowledge or from incorrect assumptions about the process, many do not employ this powerful option.

First, a little background information might be useful to further understanding of this process. Most developers are aware that a FileMaker file can contain multiple Accounts and that each individual Account is attached to a given Privilege Set. The Account, together with its password, serves to determine who is accessing the file and that the person accessing is who he or she claims to be. Who are you, and are you actually whom you claim to be? Once authenticated, the user is admitted to the file with the privileges defined in the Privilege Set associated with the Account.

When a system contains one or two Accounts and maybe only a couple of files, this construct of Accounts and Privileges is reasonably easy to manage. But for many users across many files, management is far more complex. This has lead some developers to construct ersatz log-on and security systems of varying degrees of complexity in an attempt to manage the system. I have seen literally scores of these over the past seven years. Almost completely without exception, they have proved highly vulnerable, easy to defeat, and susceptible to manipulation. They detract from, and damage, security in the files where they are used.

External Server Authentication allows us to remove the Accounts and passwords from the FileMaker file and place those Accounts and passwords either on a Domain Controller or directly on the FileMaker Server machine itself. Accounts on the server are placed into Groups, each of which can contain many Accounts. In the FileMaker files themselves, instead of individual Accounts, developers can create identically named Groups and attach each to an individual Privilege Set. These Groups must exactly match those created on the server.

When a user seeks access to a file hosted by FileMaker Server where External Server Authentication is employed, FileMaker Server queries the server (either itself or the Domain Controller) to determine the authenticity of the Account. If the Account is deemed valid, then the user is connected to the FileMaker file with the correct set of privileges. FileMaker Server matches the Group name in the file to the Group name on the server that houses the Account to determine what that set of Privileges should be. This process works to authenticate users connecting by FileMaker Pro clients as well as by Instant Web Publishing and by Custom Web Publishing.

This process works with Active Directory on Windows Server, with Open Directory on Macintosh Server, and with local security groups on either platform, although in slightly different ways. However, contrary to popular belief, it does not work with generic LDAP server connections. Part of the FileMaker Server Administration Console has a configuration panel for LDAP. This has nothing at all to do with External Server Authentication. Additionally, and again contrary to popular belief, a Domain Controller is not required to make External Server Authentication work. The external Groups can be on the FileMaker Server itself.

So why use External Server Authentication? What are its capabilities? What are its benefits? What are its advantages? There are a number of these.

1. Use of External Server Authentication dramatically simplifies Account management, especially for many users across multiple files. Once the system is set up correctly, the Account name and password need be entered only one time and in only one place. It does not have to be entered individually in each file. For a system with 25 users and 15 files, that would be 375 separate entries in individual files, versus 25 entries in one place with External Server Authentication. The likelihood for error is dramatically reduced.

2. When using External Server Authentication and updating an existing FileMaker solution, the developer does not have to worry about reconciliation of Accounts and passwords added or deleted since the prior update. This is very helpful, especially when using The Separation Model™ construct. Accounts are not in the files, including UI and logic files. So there is nothing there that changes when a older version of a file is swapped out for a newer one.

3. External Server Authentication takes advantage of the security system that an IT department has already established in either a small organization or a large one. FileMaker developers can thereby leverage the usefulness and power of these assets. FileMaker developers and DBA’s are freed of the burden of managing Identity and Access Management by utilizing assets already in place.

4. In some circumstances, developers can take advantage of the power, usefulness, and convenience of Single SignOn, (SSO) also called Single Source LogOn. In such a system, once a user is authenticated by the Domain Controller for access to network assets such as file servers, printers, etc., that same authentication can be passed seamlessly to FileMaker Server. The user is then not required to enter additional credentials to access the FileMaker files. Users need to remember only one set of credentials; they are therefore thought not to be as likely to write their credentials down somewhere and leave them where they can be discovered. SSO works from Windows OS workstations to FileMaker Server running on a Windows OS Server. It does not work in any other configuration of Operating Systems; however, it can be emulated on Macintosh OS workstations by use of the KeyChain. Inappropriate KeyChain use can itself be a problem; such misuse can be managed. That is a topic perhaps for a future Blog posting here.

5. External Server Authentication, when used with a Domain Controller, can extend the scope of tools for Credentials Lifecycle Management. Length and complexity of passwords are better controlled. The same is true for blocking the repetitive use of the same password. Additionally Domain Controllers can manage the permissible days and times and locations of log-ons. Additionally, Domain Controllers can prevent simultaneous log-ons with the same credentials. External Server Authentication thus expands the range of Identity and Access Management controls beyond those found in the native FileMaker file itself.

There are a number of different configuration scenarios for External Server Authentication depending on the specific mix of Operating Systems in place among FileMaker Server machines, user workstations, and Domain Controllers. This topic is covered in vast detail in a White Paper I co-authored with FileMaker Server world class expert Wim Decorte. That paper, Server External Authentication, was last updated for FileMaker® Server 9 in 2008. However it contains information still pertinent and useful for FileMaker® Server 11.

To recap, External Server Authentication offers FileMaker developers and DBA’s as well as IT managers flexibility, ease of Account management, and utilization of a range of IT created security assets. It should be a core part of every FileMaker developer’s arsenal.