The FileMaker 19.1 Platform: What’s new in the OAuth Authentication realm?

Authenticating your users through an Identity Provider (IdP) that supports the OAuth standard has become a crucial requirement in an increasing number of solutions.

In the past year, Steven Blackwell and I have authored a series of white papers to underline that importance and to provide walkthroughs detailing setting up IdPs such as Okta, Ping, Auth0, OneLogin, KeyCloak, Sign in with Apple, etc.1

Besides the obvious benefits of centralized user account management, you also get seamless Multi-factor authentication, account self-service for your users, and even completely passwordless logins.

These are all things that you can already do with FileMaker Server 17 and later, so nothing new in the FileMaker 19.1 platform release. Except for three things.

  1. FileMaker Server for Linux exposes AD FS as a configurable IdP in the Admin Console
  2. FileMaker Server for Linux allows an AD FS group for access to the Admin Console
  3. All 19.1 clients now show a cleaner provider selection in the login dialog.

Let’s start with that last one since that one has the widest application.[/vc_column_text]

Login Dialog

When you configure an OAuth Identity Provider, that provider is added to the Pro, Go, and WebDirect login dialogs for the user to click on and start the authentication process. For the standard three that you can set up in the Admin Console (Azure AD, Google, and Amazon), their proper name and icon are used. For any other provider that you configure through the dbs_config.xml file, in any client before 19.0, the additional OAuth provider’s name and icon always show up as Microsoft. As an example, let’s use a server where we have configured Google as an identity provider in the Admin Console and Red Hat’s KeyCloak configured in the dbs_config.xml file.

Photo of the dbs_config.xml file with Keyclock highlighted

That configuration would result in a login dialog, as shown below, where the Google provider shows up as expected with its proper icon and name, but Keycloak shows up as Microsoft.

Photo of the login for FileMaker Pro 17 through 19.0
FileMaker Pro 17 through 19.0
Photo of login on FileMaker Go 17 through 19.0
FileMaker Go 17 through 19.0

When your users have Pro or Go 19.1, then the result is a lot cleaner with a generic icon but the name of the provider exactly as you have it set up in the dbs_config.xml file:

Photo of login with FileMaker Pro 19.1
FileMaker Pro 19.1
Photo of login in FileMaker Go 19.1
FileMaker Go 19.1

Note that this is all driven by the client. Even if your FileMaker Server is 18 or 19.0, your users will get this improved behavior as long as your clients are using 19.1.

If your solution uses WebDirect, then there is no change; both FileMaker Server 19.0 and 19.1 already show the proper name on the login dialog (but no icon).

Photo of login for solution using WebDirect

This improved UI is a seemingly small thing, but we believe it is a great step forward in making the adoption of custom OAuth providers easier.

AD FS – Active Directory Federation Services

Claris’ messaging around Active Directory Federation Services in the 19.1 version is, unfortunately, a little misleading. As we have mentioned in our September 30th blog post about the release notes of FileMaker Pro 19.1, support for AD FS has been around for a while now. The FileMaker Go 19.1.2 information on the iOS app store adds to the confusion by also inferring that support for AD FS is something new.

Photo of FileMaker Go 19.1.2 in the iOS App Store

It is not.

But before we get into what really is new, you can catch up on what AD FS is in this blog post from April 2020 and this white paper that walks you through how to use it in your solutions.  In short: AD FS is an extension to your regular Active Directory that makes it available as an OAuth Identity Provider so that you can configure your FileMaker Server to use it like any other OAuth IdP.

New – part I: AD FS configuration options in FileMaker Server for Linux

The downside to using custom OAuth providers is that it requires adjusting an XML config file without the benefit of having those settings exposed in the Admin Console.  The new FileMaker Server for Linux, however, does add a configuration section to the Admin Console for AD FS.

Photo of admin console showing the addition of a configuration for AD FS

Note that this does not mean that AD FS is only possible with FileMaker Server for Linux; you can use AD FS with any FileMaker Server, including the current FileMaker Cloud edition and any on-premise FileMaker Server since version 17. The only difference is that on anything but FileMaker Server for Linux, you need to add the configuration in the dbs_config.xml file directly, as described in our white papers.

New – part II: AD FS login to the Admin Console in FileMaker Server for Linux

This truly is new functionality, and this one is only available in the FileMaker Server for Linux version. You can grant access to the Admin Console to an Active Directory group of users by way of AD FS.

This is very relevant for those deployments where you cannot join or bind the server to the actual Active Directory domain.  Because AD FS authenticates to AD through the OAuth flow, that membership is not required anymore.  For now, though, remember that this is only possible when you run your FileMaker Server on Linux.

On all on-premise or self-hosted FileMaker Servers going back to FileMaker 7, you can achieve the same result provided that your FileMaker Server is a member server in an Active Directory or Open Directory.

Photo of login that shows option to allow users to sign in using AD FS

Three configuration changes need to be made for this to work:

  1. Configure the AD FS OAuth settings by adding your client id, client secret, and the host name of your AD FS server:
Photo of admin console and adding AD FS OAuth settings
  1. Under External Accounts for Admin Console Sign In, add the name of an AD group that you want to allow access to the Admin Console
Photo of the admin console on the Administration tab - addig name for AD group
  1. And finally, toggle the switch to allow Admin Console authentication to happen by your AD FS provider:
Photo of admin consol with the toggle switch for AD FS highlighted

When you then select AD FS as the login option for your Admin Console, the authentication request is routed to the login page for your AD FS, and when the authentication is successful, the Admin Console is opened and the user has full admin access to the Console.

Photo of login when

Recap of OAuth IdP options

With these new features, the authentication landscape can seem to be a little muddier than before. Here’s a summary of what can be done with what IdP as the available options may be one of the drivers for deciding which FileMaker Server deployment is the best for your authentication requirements.

Options FileMaker Server
On-Premise
FileMaker
Cloud
macOS &
Windows
Linux
Authenticating Users
On-premise
directory
service
Active Directory
Open Directory
Local Accounts / Groups
OAuth Idp Azure AD
Amazon
Google
Okta 2 2
AD FS 2
Any Open ID Connect OAuth iDP
(Ping, Sign in With Apple, Auth0,
One Login, MiniOrange, Keycloak...)
2 2
Claris ID
Authenticating Admin Console Access
On-premise
directory
service
Active Directory group
Open Directory group
Local group
OAuth IdP Azure AD
Okta
AD FS
Claris ID
Any Open ID Connect OAuth IdP

1 All of these of course in addition to Azure AD, Google and Amazon, which have been available since FileMaker 16. For a historical overview of authentication options with the FileMaker platform: /blog/onelogin-filemaker-authentication/

2 Settings not available in Admin Console

10 thoughts on “The FileMaker 19.1 Platform: What’s new in the OAuth Authentication realm?”

  1. Another informative article, Wim!
    I’m trying to implement authentication with a 3rd party OAuth provider (no support for groups), and I believe I’ve made the necessary edits to dbs_config.xml, but server is generating a redirect_uri of https://mydomain.com:16000/oauth/redirect.
    Is there any way to change/remove the port? I was expecting a redirect_uri of https://mydomain.com/oauth/redirect. Currently port 16000 is closed on our firewall. Thank you!

    1. The redirect URL should only listen to 443 – it’s hardcoded to do that; how do you establish that it is using 16000?

        1. At what stage of the process do you see this? Does clicking the provider’s button on the FM login dialog take you to to IdP’s page just fine? If so, what’s the exact error and exact URL in the browser?

          What version of FMS is this on what OS?

          1. When I click the provider’s button on the FM login dialog, it generates a connection string that includes the redirect_uri of https://mydomain.com:16000/oauth/redirect. No it does not land on the IdP’s page (HTTP 400 error), but if I edit the URL in the browser to use redirect_uri they issued to me, the connection string works. I can send you the full connection string offline. Running FMS 19.3.2.203 on Windows Server 2016 Standard.

          2. They (the IdP) don’t provide you with a redirect URL, you give it to them so that the IdP knows where to send responses to. So I’m confused about that part.
            Is your DNS name really of the structure “mydomain.com” and not something like “server.domain.com”?
            It feels like a misconfiguration on the FMS side with IIS. Is this a plain vanilla server with IIS just running the FMS web site or are there other sites running there and possible custom IIS configs?
            Also: was this a fresh install of FMS19.3.2 or was an old FMS upgraded in-place? If the latter I would suggest a full uninstall, reboot, rename the leftover FMS folder in “program files” and then a fresh install.

        2. Hi Jim, I am also getting this same issue when trying to login using oauth. Did you ever find the cause of this? What did you do to resolve it?

  2. Well originally the IdP did provide me with the redirect URL, but I’m now realizing that’s backwards. I’ll arrange to get that reset.
    And yes, my DNS name really has the structure “mydomain.com”.
    Your suspicion is correct: at one time there was another site hosted by IIS on this server, so it’s possible some configs were improperly tweaked.
    And it was NOT a fresh install of FMS 19.3.2. It was upgraded in-place from 19.2 I believe. I’ll do a fresh install soon as you suggested.

  3. When we authenticate using oath, there is a leftover browser tab, open with no content, just the oath url. Can you think of a way to close that for the user? Not a real big thing, but it seems intrusive and selfish. This is the first system where I’ve used oath as an admin, so it is the first time I’m seeing it, so forgive this newbie question…

    1. Hi Steve,

      Unfortunately, no: you cannot control that behavior. In other environments that’s not a big deal because the user continues in the browser but FM gets a hand-off from the browser and then the browser is done but FM has no control over the browser to clean up after itself.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top