One of the most attractive options for easily integrating with a cloud-hosted directory and a FileMaker application is using Microsoft Azure Active Directory. Once enabled, this allows FileMaker apps to use OAuth for authentication. The single biggest advantage that Azure has over other OAuth options is that it allows you to manage users in groups, rather than individual user accounts.
We have covered thee before in the excellent white paper that our very own Wim Decorte wrote, along with Steven H. Blackwell, to accompany the session he presented at DevCon 2017. Download the PDF.
Multi-factor Authentication & Single Sign-On
While not a new feature, I would like to call attention to a feature that may often go overlooked, multi-factor authentication (MFA). If you specify MFA on a user account, they must enter a code sent to a different device or method, after authenticating with a username and password. You can configure this per user and support different methods of receiving an MFA code.
If your company is already using Office 365 for company email, you may already have Azure directory available as an option. The ability to use groups to authenticate users to your FileMaker applications can fit very nicely into your enterprise architecture.
How OAuth Works with FileMaker
Use a web browser to log into your Azure account and then get handed back to FileMaker (Pro, Go or WebDirect) with an authorization token. Successfully logging is especially seamless on WebDirect hosted sessions.
Additionally, if you remain logged in when entering your username and password, you will not need to enter credentials again until logging out of your Azure account in your web browser. For Windows clients, that can support Single Sign On (SSO) to your Azure account, if you’ve properly configured Windows.
Even on Mac OS, once logged in via your web browser, authenticating to a FileMaker application can effectively have a Single Sign-On experience. While not technically being SSO, the result can be similar.
Azure Updates
If you are following along with the documentation, there have been some updates to the Microsoft Azure user interface. Notably, where you define the “secret” can be non-intuitive to find and configure. You can find it by selecting the App Registration in the directory in which you are working. In the following example, we are working in the default directory, and have created an App registration named “soliant-fmsdev-01”.
Select the app by clicking on the Display Name, and you will get the options for that app. You can then select “Certificates & Secrets,” and you will see “Client Secrets” listed there. When creating the secret, name it what you want, and you will get the value generated. Take note, as this value will only show once and then be hidden. Copy and paste it while it is showing.
Also, note that you can view and update the Manifest while you have the app selected as well. This is also a UI change from previous Azure console versions. Even if you do not plan on using the Oauth flavor of authentication, it is still possible to support External Authentication, if your FileMaker server is properly configured. For example, you can synchronize cloud based or on-premises Active Directory Forest by creating a Trust. We have done this and can accommodate this and other options when using our Soliant.cloud hosting services. Feel free to inquire for more information.
Mike, Thanks for all the great blog posts. I’ve been using a lot of them recently and they have been very helpful. I appreciate the effort you make to share this information with the FileMaker community.
Any suggestions for using Azure/OAuth as a means of logging into Go solutions that are distributed via iOS SDK? In our instance the user account on the client file is created dynamically on the client (after using some dataAPI calls to the server to validate against a user database).
OAuth authentication for FM-based apps is done through FileMaker Server. Apps running locally on FM Pro or Go cannot take advantage of this set of features.