HOW FILEMAKER DEVELOPERS

CAN EXTEND
AUTHENTICATION OPTIONS
WITH NEW ADDITIONAL
OAUTH2 IDENTITY PROVIDERS
IN THE FILEMAKER PLATFORM
—ADDENDUM—

—By—

Wim Decorte and Steven H. Blackwell

FileMaker Business Alliance Platinum Members are independent entities

without authority to bind Claris International, Inc.
and Claris International, Inc. is not responsible or liable for their actions.

The views and recommendations expressed in this White Paper are solely those
of the authors and may not necessarily reflect those of Claris International, Inc.

FileMaker, FileMaker Go, and the file folder logo are registered trademarks of Claris
International, Inc. (formerly FileMaker, Inc.) in the U.S. and other countries. FileMaker
WebDirect and FileMaker Cloud are trademarks of Claris International, Inc.

© Copyright Wim Decorte and Steven H. Blackwell, 2019.

All rights reserved under both International and Pan-American Conventions.
Permission granted to users of FileMaker Workplace Innovation Platform products
to distribute within their own organizations.

Addendum 1.0 November 2019

 HOW FILEMAKER DEVELOPERS CAN EXTEND
AUTHENTICATION OPTIONS WITH NEW ADDITIONAL
OAUTH2 IDENTITY PROVIDERS IN THE FILEMAKER PLATFORM

—ADDENDUM—

In our recent White Paper How FileMaker Developers Can Extend Authentication
Options With New Additional OAuth2 Identity Providers In The FileMaker Platform1 we
discussed processes for expanding the available Identity as a Service (IDaaS) Providers
that could be used in conjunction with FileMaker® Pro 17, FileMaker® Pro 18, and
FileMaker WebDirect™ to authenticate Identity Assertions made by persons seeking
access to files. In this Addendum to that document, we want to provide some additional
information about those processes. Also, we want to present two Case Studies from
Claris FileMaker Platform customers that illustrate different aspects of this expansion.

BACKUP OF CONFIGURATION FILE

During the production process for the oAuth White Paper apparently an important
sentence was dropped from Page 24 where we talk about the dbs_config.xml file. Before
making changes to that file, make a back-up of it. And after the changes are made, make
a second, separate back-up of the revised file. These can be used if needed for roll-
backs.

MULTI-FACTOR AUTHENTICATION

We discussed in the main White Paper that use of various types of Multi-Factor
Authentication (MFA) would be a compelling reason for adoption of oAuth2 based
IDaaS providers:
[Organizations] may wish to leverage various Multi-Factor Authentication
(MFA) and Single Sign On (SSO) capabilities of such services to provide a
more user-friendly and secure Identity and Access Management (IAM) for
users. This will enable ease of administration of IAM for data owners and
data security managers, or allow self-service for users to manage their
passwords and other factors.

1
[Link]
 2

We want to emphasize several points here:

• Multi-Factor Authentication is not a requirement to make oAuth2
Authentication work with FileMaker Server. It is, however, a very good
and beneficial idea.
• Not all MFA processes are created equal. We recommend using a
hardware device such as a YubiKey2 device, a RSA SecureID3 token, or a
smart card of some sort. We recommend against sending SMS codes to a
mobile device. Such a procedure is considerably insecure. In May 2016,
the National Institute of Standards and technology (NIST) published a
guideline4 recommending the deprecation of SMS authentication as a
second factor for strong authentication. If a mobile phone is compromised5
because its user unwittingly downloaded malware onto it, a fraudster6 can
simply command the malware to monitor text messages, including those
containing OTPs, on that phone. Many phones are susceptible to Trojans
like Zeus, Zitmo, Citadel and Perkele, which leverage open access to SMS
on mobile phones specifically to intercept OTPs. Since encryption is not
applied to short message transmission by default, messages could be
intercepted and snooped during transmission, even if the receiving device
wasn’t infected by malware. Additionally through an attack vector known
as a SIM-SWAP7 exploit, information destined for one device can be
redirected to another one.

2
[Link]

3
[Link]
4
[Link]
[Link]

and

[Link]
[Link]
5
[Link]
nist-recommendation/

6
[Link]
11573221600
7
[Link]

and

[Link]
[Link]
 3

FILEMAKER CUSTOMER CASE STUDY

FOOD AND DRUG ADMINISTRATION

The US Food and Drug Administration (FDA) is a division of the Department of

Health and Human Services. It has responsibility to assure public health and safety by
regulation of food, drugs, and medical devices, among other items. An office of the FDA,
the Center for Drug Evaluation and Research (CDER) maintains a FileMaker Pro based
system named Science and Research Investment Tracking Archive (SARITA).
A 2004 Homeland Security Presidential Directive mandates that access to the
SARITA system be through use of a Federal Personal Identity Verification card (PIV).
This process does not involve the manual entry of any credentials. The challenge was
how to make this card and its processes work with FileMaker Server hosted files. After a
number of unsuccessful attempts the CDER settled on the use of Ping Federate as an
IDaaS provider to accomplish this task.
Ping Federate here is acting as a Service Provider or Broker and not as an Identity
Provider. A “…broker is a service provider that specializes in brokering access control
between multiple service providers.”8 A user logs into his or her workstation with the
PIV card. This gives the user access to the network and to assets on the network. The
CDER wanted to extend this to granting access to the FileMaker Pro system without need
for further authentication efforts by users. In order to accomplish this, Ping Federate and
FileMaker Server needed to communicate with one another. Claris Product Development
Engineers and one of its Senior Consulting Engineers assisted the FDA to modify a
FileMaker Server configuration file to facilitate and enable this process. And thus we
discovered a clue to how to extend oAuth2 functionality to other IDaaS providers.9
When a user seeks access to the FileMaker Pro file, he or she elects to
authenticate by the Ping service. The authentication request is passed to Ping Federate
functioning as a broker. Active Directory is the service provider for Accounts and Groups
authentication here. Ping is the broker that receives the request for authentication and
channels the response back to the requestor. Ping then securely sends a token to
FileMaker Server with user’s authentication information including Group information.
Thereupon the user gets access to the file with the assigned Privileges as defined in the
Privilege Set for the matching Group.

8
[Link]
9
We are grateful to a number of people at the FDA for their assistance in explaining this process. All are
listed by name in the Acknowledgments Section of this Addendum on Page 5.
 4

FILEMAKER CUSTOMER CASE STUDY

STATE LICENSE SERVICING, INC.

State License Servicing, Inc. (SLS) provides multi-state regulatory licensing

services for the pharmaceutical industry. With over 100 clients that wholesale, distribute
and/or manufacture pharmaceutical products, SLS manages licensing requirements from
applications to renewals, changes and notifications to meet the varying and ever-changing
rules of all 50 state governments and Puerto Rico.
SLS describes its business problem here as follows. Servicing their clients
requires SLS to aggregate, organize, maintain and safeguard hundreds of thousands of
data points and digital documents. This is an ongoing and collaborative process with the
client that the company manages via five technologies that come together via SLS’s web-
based client portal:
MiniOrange: Management of user credentials, single sign on
Sharefile: Archived document storage
Smartsheet: Prioritizing, approving and retrieving new documents from the client
Freshdesk: Communications and project tracking
WebDirect: Client data storage, all internal workflow
A client user enters the website and logs in with credentials managed in
MiniOrange. Following authentication, MiniOrange navigates to a page containing icons
for Sharefile, SmartSheet, Freshdesk and FileMaker WebDirect.
Because Sharefile, SmartSheet and Freshdesk allow for Single Sign On (SSO) via
SAML, the user can then simply click on icon and go directly to the technology of their
choosing. FileMaker WebDirect, however, does not allow for true SSO, and therefore,
the user must login again in order to gain access.
The effect of this for SLS is widespread. First and foremost, the user does not
have a seamless experience. SSO is expected of today’s websites, and SLS believes its
absence calls into question the professionalism of the website as a whole. Secondly,
SLS’s IT Department is forced to maintain two sets of credentials – one set for
MiniOrange and another for WebDirect. With over 100 clients and growing, the time
spent managing these credentials is increasingly burdensome. Finally, users are not able
to maintain their own credentials. As a result, SLS staff must communicate with clients
on such minor issues as forgotten passwords, etc.
So, we sought to develop a method such that once a SLS client was logged into
the MiniOrange site, that a simple click of a button would allow access to the FileMaker
database. Working with SLS and with MiniOrange10 we were able to construct an
oAuth/OpenID Connect flow from MiniOrange, and thus we were able to provide this
functionality. SLS now has the option of using MiniOrange either as an Identity Provider
or as an Identity Broker as described in the original White Paper. Client users login once
to the system.

10
We are grateful for assistance from persons at both organizations who are listed by name in the
Acknowledgments Section of this Addendum on Page 6.
 5

ACKNOWLEDGMENTS

The authors appreciate the assistance and information we received for various
persons at the Food and Drug Administration. Their work was the impetus for this White
Paper. The FileMaker Developer Community and the customer base both owe them a
large debt of gratitude.

US Food and Drug Administration—

Susan T. Frank
FileMaker Developer/Technical Project Manager
Contractor to FDA Center for Drug Evaluation and Research

Grace Carmouze-Cunningham, GWCPM

Sr. Regulatory Health Project Manager
Office of Translational Sciences, Center for Drug Evaluation and Research
US Food and Drug Administration

Sheryl Hicks, PMP

Sr. IT Project Manager
CDER/OTS
Contractor to FDA Center for Drug Evaluation and Research

Aaron Stromas
SSO Engineer
Contractor to FDA Office of Information Management Technology

Jay Singh Chahil

AD/SSO/PKI/CLOUD/IdAM Lead
Office of Information Management Technology
US Food and Drug Administration
 6

ACKNOWLEDGMENTS, continued

The authors appreciate the assistance and information we received from various
persons at State Licensing Services, Inc. and MiniOrange. The FileMaker Developer
Community and the customer base both owe them a large debt of gratitude.

State License Servicing, Inc.—

Stephen Schneider
President

Kristine Burrows
Manager of Information Systems

MiniOrange—

Krishna Murari Vijay

Senior Software Engineer

Swati Gupta
Senior Software Engineer
 7

ABOUT THE AUTHORS

WIM DECORTE is a Senior Technical Architect at Soliant Consulting, a

FileMaker Business Alliance Platinum Member company. He is a leading expert on
FileMaker Server, FileMaker Platform integration, and IT infrastructure issues. He is the
author of numerous White Papers, Technical Briefs, and BLOG posts
([Link]

STEVEN H. BLACKWELL is a FileMaker Business Alliance Platinum Member

Emeritus. He is the author of FileMaker Security: The Book as well as numerous White
Papers and Technical Briefs about FileMaker Platform Security. He is also the creator of
the FileMaker Security BLOG ([Link]
blog)