I am pleased to have as co-author of this BLOG posting the renown and exceptionally highly regarded “developer’s developer” Wim Decorte.

FileMaker, Inc. recently published a FileMaker How To article entitled Replicating an External Authentication Environment for Development authored by developers at Skeleton Key in St. Louis, Missouri.

A copy of the Skeleton Key article can be found on their website here:

http://www.skeletonkey.com/blog/replicate_an_externally_authenticated_production_environment

This is an interesting paper, and it deserves a review by FileMaker developers, both independent and corporate. It reminds us that servers do have local Security Groups and Accounts. In fact, such Groups and Accounts are widely used for External Server Authentication purposes in a variety of small to medium sized enterprises as well as in workgroups of larger ones. The fact that FileMaker External Authentication can work with local accounts and groups in the OS on the FileMaker Server machine itself is often overlooked, so the article serves a good purpose in this respect.

Notwithstanding this, however, we have significant concerns and reservations about the underlying premise of this paper as well as some of the specific techniques it recommends and describes. We have elected to share these with the FileMaker developer community because of the official FileMaker, Inc. imprimatur on this paper and because of our genuine respect for the developer team at Skeleton Key. Developers will see and read this paper, authored by a well-known and respected company and issued by FileMaker, Inc., and perhaps not be aware of a number of additional considerations.

The paper states at the outset its principal purpose (emphasis supplied):

Imagine you are an outside developer for a large company. You are building a mission-critical FileMaker system – a large solution with several different privilege sets that require careful testing and tuning. Their IT team has mandated that FileMaker Server must authenticate users externally. You want to make sure the solution’s security setup will work well with multiple users and that once deployed it will properly interact with the customer’s Active or Open Directory environment. As their dedicated developer you have been given access to the company’s FileMaker Server and files, but as an outside consultant you do not have access to make changes to their network directory or services. How can you fully configure and test the security of your FileMaker system before the actual deployment in their production environment?

In our view this underlying assumption of the paper is invalid. There is no need to construct a system of External Accounts to “…fully configure and test…” the system’s security. The effect of restrictions held in privilege sets can be tested with regular internal FileMaker accounts.

The only reason to set up a system of External Authentication would be test the mechanics of the authentication process, not the restrictions of a user’s role.

The paper’s underlying assumption and the subsequent recommendations confuse and conflate Identity and Access Management (who are you?) with Role Based Privileges (what are you allowed to do?). Through its Privilege Set definitions, FileMaker Pro enforces a set of conditions for each Account attached to that specific Privilege Set. Accounts attached to a Privilege Set all enjoy, for the most part,[1] a common set of privileges in tables and files. By default, all privileges are denied; developers must specifically enable each. This is in keeping with the Rule of Least Privileges that mandates a user have all the privileges needed for his or her role, but no more privileges than the ones needed.

Role Based Privileges form one part of the FileMaker security schema. The other part is Identity and Access Management (I&AM). I&AM is used to authenticate users seeking access to the database system. It answers two related questions: “Who are you?” and “Are you whom you claim to be?” Once these two questions are successfully answered, the user is granted access to the database system with the Role Based Privileges defined in the Privilege Set to which the Account is attached.

FileMaker can perform I&AM functions either with internal FileMaker accounts or with External Server Accounts. In either regard, the result is the same: if the user is properly authenticated and deemed to be an authorized user, that user gets the privileges associated with the Account accessing the file. Thus, there is no need to construct a “development” environment using External Server Accounts to, in the paper’s phrasing, “…test the security of your FileMaker system before the actual deployment in their production environment….” An internal FileMaker account works just as well for this purpose. Two different Accounts, one internal and the other External, attached to the same Privilege Set will enjoy exactly the same set of privileges when the user is connected to the file. FileMaker, Inc. has taken specific steps over the past several versions to assure this.

Beyond this fundamental item, there are also a number of other elements in the paper that concern us. The page number references are to pages in the paper.

Better access control (page 1). While indeed this is an advantage of External Server Authentication, this is a Domain level policy, and it will not be achieved through use of Local Security Group objects. Unless there are a great number of files in the FileMaker solution there is no real benefit in setting up this local External Authentication scheme, an internal FileMaker account will work for this purpose and is easier to set up.

What’s Needed? A local machine that is not bound to either an OD or an AD domain…(page 2). OSX and Windows work differently in this respect. Even if a Macintosh machine is bound to an Open Directory or Active Directory domain, FileMaker Server will always look to the Local Security Group first before it looks to the Domain Controller. So contrary to what is implied, the mechanism described in the paper will work when the OSX FileMaker Server machine is bound to either an AD or an OD domain. On Windows OS however, the server machine is either bound or not bound. When it is bound to an AD (is a member server of an AD domain) it will skip the local accounts and groups and always look for the domain accounts. While it is possible to force FileMaker Server to look first on the local machine when bound to an Active Directory domain, that is neither default nor standard behavior. But it is still possible to test local External Authentication when the Windows FileMaker Server is bound to an AD.

What’s Needed? FileMaker Server installed on your local machine…(page 2). We do not believe this is a good policy. We do not advocate running FileMaker Server and FileMaker Pro simultaneously on the same machine. We are aware that some developers do this and have FileMaker Pro become a guest of that FileMaker Server instance and access their files thereby. Especially if the external data source file reference is of the relative type, file:filename rather than the FileMaker network type, fmnet:/HostIP/filename, we believe there could be instances where files opened by relationships or scripts via Table Aliases on the Graph may not open as expected as a guest of FileMaker Server. Much more testing and some definitive declaration from FileMaker, Inc. Engineering are needed to determine actual FileMaker behavior in these circumstances.

Setting it up. You can replicate the relevant EA setup…(page 3). This is, at best, only partly correct. Local Security Groups do not behave in exactly the same fashion as Domain Groups. This is particularly true for Single Sign-On (SSO) which is only possible when a Windows OS workstation connects to a FileMaker Server on Windows Server and where the server is a member of the Active Directory Domain. Some developers fail to make a critical distinction between External Server Authentication and SSO. They are not the same. In the former, available for both Macintosh and Windows, the Account can be authenticated; however the user must enter credentials to access the file. Those credentials are then authenticated by the server after the user enters them. In SSO, however, the user does not have to enter credentials again to access the database once he or she is authenticated to the domain. [Note: on Macintosh SSO capabilities can be emulated to an extent by use of the KeyChain]. With Local Groups however, users must enter credentials to access the file; SSO is not operative (again with the KeyChain nuance). Thus, if the developer was expecting not to enter credentials, confusion may well ensue.

The other aspect is that the mechanics of authenticating against local accounts is different than authenticating against an OD or AD. There are factors that do not come into play with local authentication such as clock synchronization and lag time incurred by the physical distance between the FileMaker Server machine and the AD or OD machine. This translates into mimicking the EA setup, but not replicating it.

FileMaker Pro Login window (page 5) and Account in the ‘Production Coordinators’ Group (page 7). Mr. Richman’s account is styled differently here one place than the other (Mark Richman vs. mrichman). This may cause the process to fail. We believe the paper should have attempted to explain the difference to avoid confusion. On the Macintosh platform the short name is the one used by FileMaker Server and Open Directory, not the long name that is the more user recognizable one. Thus, an Account named Steven Blackwell will be reduced to the short form stevenblackwell. Note the absence of spaces and the use of all lowercase letters. When establishing Accounts on either platform, we recommend the use of all lowercase names without spaces. Likewise we recommend the use of a similar construct for the Group names, both on the server and in the file. (See contrary example at bottom of page 6). We also encourage the use of a construct similar to this one: fm_solutionname_groupname for this, inasmuch as it is easily and quickly identifiable both as a FileMaker Group in either AD or OD and as part of a specific solution.

Account in the ‘Production Coordinators’ Group (page 7). We note that the example given here for adding Accounts in OS X is utilizing the OS X client software, not the OS X Server software. While this is to be expected because the developer presumably is working on a client machine for development purposes, the UI and process on OS X Server may be somewhat different. Various versions of OS X Server have taken different approaches to this. The WorkGroup Manager however has been the utility most frequently used on the Server version to create Groups, create Accounts, and to assign Accounts to Groups. On Windows OS, the UI is more nearly identical between client and server versions.

In addition to the foregoing, there is at least one critical test the process described in the article cannot address. A key requirement for External Server Authentication, and a key point of failure in many such deployments, is a mismatch between the Group Name on the Server or on the Domain Controller and the Group Name in the FileMaker Pro file. They must match exactly. We previously offered a recommendation for the syntax of such names. To test how the system will work in the production environment, we recommend deployment of a test file configured with the Group names and set for External Server authentication, together with external Groups in the proper place. Users can then attempt to log into that file. A successful log-in can be made to create a new record with Account Name, workstation information, and Privilege Set name, all for developer review. Failed attempts will be logged by FileMaker Server if administrators enable proper logging. Additionally, obvious failures will manifest themselves to the user. When using such a file, be sure to disable auto-log-in options in the test file.

In summary then, we do not believe that the underlying premise of the paper is valid. There really is no need to have External Authentication to test the “security” of the file, inasmuch as the Privilege Sets will function identically irrespective of the authentication model. Additionally, we believe that some of the procedures described in the paper are insufficiently nuanced given distinctions between Domain authentication and Local Group authentication behaviors. Finally, the paper recommends a scenario regarding FileMaker Server and FileMaker Pro’s simultaneous use on the same machine that we do not believe is prudent. We welcome further discussion and debate within the developer community about these items.

[1] It is possible to make one Account attached to a given Privilege Set behave differently than other Accounts attached to the same Privilege Set do. But that is independent of the authentication model used.