FileMaker privilege sets define what a user is allowed to see and do inside a custom app.
They are a fundamental part of FileMaker’s security model. An account identifies the user, while the privilege set assigned to that account determines the user’s level of access.
Extended privileges control an additional question: how may the user connect to the file?
Accounts and privilege sets
Each FileMaker account access entry is assigned a privilege set.
The account may be authenticated by:
- A username and password stored in the FileMaker file
- An external server such as Active Directory
- An OAuth or OpenID Connect identity provider
- Claris ID or an external identity provider in FileMaker Cloud
Regardless of the authentication method, the privilege set controls authorization inside the FileMaker file.
A single privilege set can be assigned to many individual users or groups.
What can a privilege set control?
A privilege set can determine access to:
- Tables and records
- Individual fields
- Layouts
- Scripts
- Value lists
- Printing
- Exporting
- Menu commands
- FileMaker development features
- Security-management features
Record access can also be calculated. For example, sales representatives may be allowed to see only customers assigned to them, while managers can see every customer.
These rules are enforced by the FileMaker platform itself. Hiding a button or preventing navigation to a layout is not a replacement for an actual security rule.
Predefined privilege sets
Every new FileMaker file contains three predefined privilege sets:
- Full Access, for complete development and administration
- Data Entry Only, for viewing and modifying data without development access
- Read-Only Access, for viewing data without ordinary record modification
Developers can create additional privilege sets corresponding to the roles within an organization.
Typical examples might include Sales, Accounting, Management, External Customer, Auditor, and API Integration.
What are extended privileges?
Extended privileges determine which access methods are available to a privilege set.
Common extended privileges include:
fmappfor FileMaker Pro and FileMaker Gofmwebdirectfor FileMaker WebDirectfmrestfor the FileMaker Data APIfmodatafor ODatafmxdbcfor ODBC and JDBCfmxmlfor XML Custom Web Publishingfmphpfor PHP Custom Web Publishingfmurlscriptfor running scripts through URLs or ShortcutsfmreauthenticateXfor controlling reauthentication after disconnection or background activity
A user may therefore be authorized to access certain data but prohibited from accessing the file through a particular interface.
For example, an integration account could have Data API access while being unable to open the file with FileMaker Pro.
Extended privileges do not grant data access
Enabling fmrest, fmodata, or another extended privilege does not give a user unrestricted access to the database.
The account remains subject to the record, field, layout, and script permissions defined by its privilege set.
Conversely, giving a user permission to view records does not automatically allow that user to connect through every available interface. The corresponding extended privilege must also be enabled.
Both layers must authorize the operation.
Security is defined per file
FileMaker privileges belong to an individual .fmp12 file.
In a multi-file custom app, the accounts, privilege sets, external groups, and extended privileges must be coordinated across every relevant file.
This is a frequent source of unexpected authentication prompts or access errors. A user may be correctly authenticated in the interface file but lack corresponding access to a separate data file.
The principle of least privilege
Users and integrations should receive only the permissions they genuinely require.
An API account used to create orders does not necessarily need permission to export customer data. A customer accessing WebDirect should not automatically receive FileMaker Pro network access.
Careful privilege-set design reduces the consequences of mistakes, compromised credentials, and programming errors.
FileMaker security should also be tested using real non-administrative accounts. An application tested only with Full Access may conceal serious permission problems.
FileMaker security expertise from fmcloud.fm
At fmcloud.fm, secure hosting begins with the server infrastructure but does not end there.
We help organizations review FileMaker privilege sets, extended privileges, external authentication, API accounts, encryption, and access methods.
Our knowledge of both FileMaker development and server architecture allows us to identify security gaps that may not be visible when the database file and its hosting environment are assessed separately.
