Fi I eMaker Trai ni ng

FileMaker
Security
FiIeMaker 5ecurity page 2
©2006 FileMaker, Inc. All rights reserved. FileMaker is a registered trademark of FileMaker, Inc.,
in the U.S. and other countries. The fle folder logo is a trademark of FileMaker, Inc. All other
trademarks are the property of their respective owners. Product specifcations and availability
subject to change without notice.
Special credit to Bob Bowers, Steve Lane, and Scott Love of Soliant Consulting (www.
soliantconsulting.com) and Chris Moyer of The Moyer Group (www.moyergroup.com) for
assisting FileMaker, Inc. with the development of this document.
This document may not be reproduced or otherwise redistributed without consent of FileMaker,
Inc.
FiIeMaker 5ecurity page 3
TabIe of Contents
Objectives ..................................................................................................................... 4
A Complete Approach to Security ............................................................................. 4
Determine Data and Database System Security Risk .............................................. 5
Physical File Access ..................................................................................................... 6
Operating System Security ......................................................................................... 6
Security Over the Network ......................................................................................... 6
Anatomy of FileMaker Security Features .................................................................. 9
Privilege Sets .............................................................................................................. 10
Extended Privilege Sets ............................................................................................ 21
Working with Custom Extended Privileges ............................................................ 22
User Accounts ............................................................................................................ 24
File List Filtering ......................................................................................................... 32
Review Questions ...................................................................................................... 35
Review Answers ......................................................................................................... 36
FiIeMaker 5ecurity page 4
FiIeMaker 5ecurity
Objectives
The topic of FileMaker® security encompasses more than just knowing how to use the Access
Privileges in FileMaker Pro 8. It’s important that data security be reviewed in terms of all points
of access to data. Most often, the database system is just one of many points of access to
sensitive organization data.
By the end of this module, you’ll be able to:
• Describe the issues surrounding data security
• Describe the different authentication schemes that can be used with FileMaker Pro 8
• Create and modify all aspects of privilege sets
• Create and implement extended privileges
• Set up FileMaker Pro 8 to use external authentication via FileMaker Server 8
A Complete Approach to Security
In most organizations, data resides not only in the database systems, but also in the form of
printed documents that are stored in fling cabinets. It often happens that sensitive information
goes into the trash un-shredded, sometimes with disastrous results. When considering
security precautions, organizations need to review the security of data in all of its forms, not
just in relationship to the database system. User processes are also important. It’s pointless to
implement strict database security if users log into the system and then stay logged in over
lunch or overnight while their desktop computers are unattended.
Often it’s important for different users to have different capabilities within the database
system. For example, perhaps only certain employees are allowed to approve orders. If you
compartmentalize database access in such a way that a few people, especially when absent,
slow down the business processes then you give employees a strong incentive to share login
information with others and thus defeat your security precautions. While it’s important to
implement proper database security, it’s perhaps just as important to devise the system in
such a way that it doesn’t make it unnecessarily diffcult for employees to get their work done
effectively.
We’re going to start this module with a review of all the points that you need to consider when
implementing a data security plan.
FiIeMaker 5ecurity page 5
Determine Data and Database System Security Risk
Data 5ensitivity
Before spending a lot of time devising and implementing an ironclad security system, you
should consider the ramifcations of a worst-case security breach. If you have a database that
contains the same product information as your sales brochures and the company web site, you
needn’t go to great lengths to protect that data. Information that is easily available from public
sources is probably not worth a signifcant security investment.
5ystem Process 5ensitivity
Sensitivity of the stored data isn’t the only consideration, however, a database system that
contains publicly available information may be linked to systems that run your organization. To
the extent that organizational processes can be disrupted, you need to protect against not only
corruption of the data, but corruption of the business logic embedded in the database system
as well.
If any user can make functional modifcations to the database system, the odds are great that
someone will unintentionally damage the functionality of a system. Such damage might be as
minor as accidentally removing a feld from a layout or as serious as modifying a script so that
it destroys data.
Trade 5ecret 5ensitivity
If your database system were to be obtained by someone outside your organization, would
that person derive a competitive advantage by learning how your organizational processes
work? Do you have any proprietary formulae or processes embedded in your database system
that you consider trade secrets? Often, the database system itself, even without data, contains
important information about organizational processes that needs to be protected.
Pisk of Data or 5ystem Loss
Most security discussions center on the concept of preventing sensitive data from being
revealed. You should also consider what precautions need to be put in place in the event that
data is destroyed. There are many unintentional ways for data to be destroyed. They range
from hard drive failures to lightning strikes to fre to uneducated users. Having a good backup
process is the best way to ensure that you can quickly recover from an intentional security
breach or an unexpected disaster.
On a related note, if a FileMaker system goes down right in the middle of a data or system-
modifying transaction, such as the creation of a new record or a change to a layout or script,
the incomplete transaction will be discarded and when the system comes back up, it will be as
if the transaction had never occurred.
FiIeMaker 5ecurity page 6
Physical File Access
FileMaker Pro 8 stores data in a unicode format. If you were to use a regular text editor to open
a database fle, no usable information would be apparent. That doesn’t mean that fle access
security precautions are unnecessary, however, because given enough time, a determined
hacker can break into just about any fle. That being the case you need to provide physical
security for your sensitive data and systems. Networked systems should reside on a secure
computer in a locked facility.
Physical access to the hard drive that contains the data should be restricted to those with a
need for access. If you have a single user database that contains sensitive information, make
sure you secure your computer. If the security risk is high enough, it’s worth hosting the system
from a secure environment even if you’re the only user of the system. Hosting with FileMaker
Server 8 will give you the added beneft of regularly scheduled backups, assuming the database
administrator has set them up properly. Security for backup media is also important. It’s a waste
to make a big investment in security and then have backup media sitting in an unlocked fling
cabinet. Don’t forget to secure backup media and backup servers as well as the ‘live’ fles.
Operating System Security
Even if different users need to have access to a computer that holds sensitive data, you don’t
have to let all users have access to the entire computer. Use the security features inherent in the
computer operating system to compartmentalize data for the people that require access.
Security Over the Network
FileMaker uses TCP/IP as its network protocol when your deployment is confgured to share
data in a peer-to-peer or Server and guest confguration. Network packet sniffng software can
be used to eavesdrop on this network traffc. Properly confgured frewalls and Virtual Private
Networks (VPNs) are useful for keeping would-be hackers outside of your organization from
monitoring network traffc inside your organization.
An additional level of security provided by using FileMaker Server 8 is the ability to encrypt
the network traffc between FileMaker Server 8 and client connections. This can be confgured
with the Server Administration Tool (SAT), as shown in Figure 1. Note: network traffc between
copies of FileMaker Pro 8 that are sharing a database peer-to-peer can NOT be encrypted.
FiIeMaker 5ecurity page 7
Figure 1
If you use wireless networking, you need to be aware that wireless-networking signals can be
detected beyond the walls of your premises. Be sure to encrypt your wireless networking traffc
when working with sensitive data.
There are additional layers of network security that can be added. You may have an environment
where subcontractors or other types of outside personnel have access to your internal network.
They may not possess database passwords with which to log into your FileMaker systems, but
if they have a copy of FileMaker, they can use the Open Remote command in FileMaker to look
around the network and see what kinds of systems are running. If any of your systems have
default passwords confgured, then they’ll even be able to gain access to those systems. They’ll
also be able to determine on which servers those systems reside. You can prevent this kind of
research by not using default passwords and by confguring FileMaker Server 8 to display only
databases each FileMaker Pro 8 user is authorized to access, as shown in Figure 2.
FiIeMaker 5ecurity page 8
Figure 2
If you have a Lightweight Directory Access Protocol (LDAP) server deployed on your network,
you can register FileMaker Server 8 with the LDAP server. The Open Remote dialog box has an
option to display hosts listed by LDAP (Figure 3). You can take advantage of the LDAP to only
publish hosted database information to those users who need to access them. This is more a
matter of convenience than security: users could fnd out the host names or addresses of your
servers by other means, and connect to them directly. LDAP provides a convenient means to
centralize access to several FileMaker servers, but doesn’t otherwise help in restricting access
to those servers.
FiIeMaker 5ecurity page 9
Figure 3
Anatomy of FileMaker Security Features
Now that we’ve reviewed the different areas that need to be considered in a security assessment,
let’s turn our attention to the tools that FileMaker Pro 8 provides to address security concerns.
The security features in FileMaker Pro 8 are implemented in the form of three main
components:
1. Privilege Sets
2. User Accounts
3. Extended Privileges
FiIeMaker 5ecurity page 10
Briefy, user accounts control access to the database system, and privilege sets control
what they can do once they have access. Extended privileges are used both to specify the
permissible connection methods (FileMaker network access, Instant Web Publishing etc.) for
a database, and to allow developers to add specifc custom privileges not accounted for in
regular privilege sets. These three components are topics unto themselves, and so we’ll review
each one separately.
Privilege Sets
Privilege sets control what users can see and do in a database fle. Since each user account
must be associated with an existing privilege set, it’s a common practice to defne privilege sets
frst. In general you will have fewer (often many fewer) privilege sets than you will have user
accounts. For example, you might create a privilege set called Sales, which would determine
the privileges available to all people in a sales department. You might then create ten user
accounts, and assign each one the same Sales privilege set.
When you create a new FileMaker database, three privilege sets are created by default. If you
choose File>Defne>Accounts & Privileges, the Defne Accounts & Privileges dialog will open.
Click the Privilege Sets tab to see the three default privilege sets, as shown in Figure 4.
Figure 4
FiIeMaker 5ecurity page 11
If you click the New button, the Edit Privilege Set dialog will open, as shown in Figure 5.
Figure 5
The fgure illustrates that the default settings for a privilege set are pessimistic, not optimistic. This
means that the default settings are as restrictive as possible. Left unchanged, the default settings
will allow a user to do nothing. Optimistic settings would allow a user to do everything.
The purpose of pessimistic default settings is so that if an inexperienced database administrator
fumbles around and creates a new privilege set, the administrator won’t inadvertently leave
access to the database wide open. Access must be explicitly and deliberately granted when
creating new privilege sets. Doing this properly requires some knowledge. The result is that
unknowledgeable administrators are less likely to cause accidental harm.
FiIeMaker 5ecurity page 12
Looking at Figure 5, you’ll see that there are a substantial number of privileges to control, so
the construction of privilege sets requires some thought. Let’s begin by listing everything that
a privilege set can control:
View Records
Edit Records
Create Records
Delete Records
Modify Scripts
Execute Scripts
Modify Value Lists
View Layouts
Modify Layouts
Access Menus
Printing (also controls the ability to save as a PDF)
Exporting Records (also controls AppleEvent access and the ability to Save as Excel)
Managing Privileges
Enable Extended Privileges
The default set of Extended Privileges controls access to the data via different methods: Instant
Web Publishing, ODBC/JDBC, FileMaker Network, FileMaker Mobile, XML, and XSLT custom
web publishing. To aid in the planning of your security implementation, it’s useful to make a grid
composed of the different types of users intersected with the privileges that are controllable
by privilege sets:
User Type View
Pecords
Edit Pe-
cords
Create
Pecords
DeIete
Pecords
Modify
5cripts
E×ecute
5cripts
Modify
VaIue
Lists
Modify
Layouts
Access
Menus
Admin Yes Yes Yes Yes Yes Yes Yes Yes Full
Manager Yes Yes Yes Yes No Yes Yes Yes Full
Marketing Yes Yes Yes No No Yes No No Edit
Sales East Yes Yes Yes Limited No Yes No No Edit
Sales West Yes Yes Yes Limited No Yes No No Edit
This type of grid will clarify your thinking on appropriate privileges, and it’s a good format to
circulate for review as well. You might potentially want to construct a grid like this for each table
in the database, if your privilege system is complex enough. Note that in the grid above, Sales
East and Sales West have “limited” ability to delete records (this concept is explained farther
on). Privilege sets can have very precise criteria for granting a specifc privilege.
FiIeMaker 5ecurity page 13
By “limited” here, the database designer intends that salespeople in the East region can only
delete records that are marked as belonging to the East Region, and salespeople in the West
region can only delete records that are marked as belonging to the West Region. To implement
the limited capability to delete records as shown in the security grid, you would start with a new
privilege set as shown in Figure 6. Rename the privilege set as East Region, and then choose
Custom privileges from the pop-up list next to the Records label as shown in Figure 6. The
Custom Record Privileges dialog shown in Figure 7 will open.
Figure 6
In the Custom Record Privileges dialog, different settings can be made for View, Edit, Create,
Delete, and Field Access for each table in the database. Note that if you have a database that
is composed of multiple ñIes (not to be confused with tables), you’ll need to re-create and
maintain these settings in each fle.
FiIeMaker 5ecurity page 14
Figure 7
If you choose limited access to a privilege, such as View, then the Specify Calculation dialog will
open, as shown in Figure 8.
FiIeMaker 5ecurity page 15
Figure 8
In our current example, which is for the East region, we want the sales person to view only
records assigned to his region. If he somehow were to look at a record assigned to “West” (or
any region other than “East”), each feld would display <no access>, as shown in Figure 9.
Note: There are a variety of ways to access FileMaker data from outside the application. These
range from the Web to ODBC/JDBC to FileMaker Mobile to ActiveX and AppleScript. All of
these applications can be restricted by setting record-level access appropriately for the privilege
sets that will be used by these clients. Record-level security should be the centerpiece of your
security strategy for external applications. It may be worth noting that record level security will
slow a large database since every fnd has to add to the request, every relationship has to add
this to the join, etc.
FiIeMaker 5ecurity page 16
Figure 9
Once the custom record privileges have been confgured, it’s time to turn our attention to
the rest of the privilege set settings. As shown in Figure 10, layouts can also have specifc
privileges assigned to them. If a user has the same kind of access for all layouts in the fle, then
you can use one of the standard settings that can be applied to every layout. In the case of a
salesperson, it wouldn’t be advisable to let them modify layouts and possibly damage existing
functionality. They need to use the fle, so AII no access isn’t a good option either. It’s possible
that they might need access to all layouts just to edit record data, and if that’s the case, then AII
view onIy is a good option. That’s not always the case, though, and it’s also worth considering
whether a salesperson will need different levels of access for layouts that might be created in
the future. For that situation, you need to use Custom privileges.
FiIeMaker 5ecurity page 17
Figure 10
Figure 11 shows the Custom Layout Privileges dialog. If a layout is set for view only or modifable
access, then the privileges for accessing records via that layout become editable. Although this
is a relatively simple dialog, it’s powerful in that it can customize access for each individual
layout and for any layouts that might be created in the future by setting access for [Any New
Layout]. A good strategy is to use a low level of access such as view only for layout access and
view only for layout record access for new layouts. Once layouts have been created, you can
then go in and adjust access on a case-by-case basis.
FiIeMaker 5ecurity page 18
Figure 11
Value Lists have a similar set of access controls. As shown in Figure 12, value lists can either have
standard modifable, view only, of no access privileges, or they can have customized privileges
for each value list.
Figure 12
Figure 13 shows the Custom Value List Privileges dialog. For a salesperson, it would most likely
be appropriate to restrict access to view only, which means that they could use the value list,
specifc privilege set have the ability to edit and maintain one or more value lists while they
have view only access to all other value lists.
FiIeMaker 5ecurity page 19
Figure 13
Script access is slightly different. If you look at the Custom Script Access dialog in Figure 14, you
can see that it contains a Notes column. This column shows whether or not a specifc script has
been set to run with full access privileges or not. This is an important aspect of script security.
It’s often desirable to restrict users from performing operations like record deletion or record
creation as a general case. However, an individual script can be designed so that it allows
such operation only under very specifc circumstances. If it’s desirable to allow the user to
perform the operation under those specifc circumstances, it can be made possible by allowing
the script to run with full access. In essence, specifc scripts can have a higher level of access
privileges than the currently logged in user. (Note that a script run with full access takes on all
the characteristics of the full access user, including the privilege set and any related extended
privileges.)
FiIeMaker 5ecurity page 20
Figure 14
For [Any New Script], it’s a good policy to restrict access to executable only. If a specifc privilege
set needs to maintain specifc scripts that haven’t been created yet, access can be granted on
a case-by-case basis.
In Figure 15, the settings for Layouts, Value Lists, and Scripts have been set in accordance with
the security grid. Printing has been enabled, which brings us to the password options.
Passwords can be set to be static, or they can be set to be user-modifable, which is preferable
from a security standpoint. If modifable, then a minimum password change interval can be set.
A minimum length for future passwords can also be specifed. All of these options have been
set in Figure 15.

CAUTION: It is possible to set up a confict if a user’s account requires the password to be
changed at the next logon (refer ahead to Figure 17) and if the user’s privilege set doesn’t
allow them to change the password. In that case the user will not be able to log in. A similar,
though not identical, problem can occur with externally authenticated accounts. If an externally
authenticated account requires the user to change the password, FileMaker cannot handle that
request because the request comes from the external authentication source, not from FileMaker.
Therefore, the user will be unable to login and will not be prompted with a “Change Password”
dialog to indicate the true source of the failure. Generally, this is not an issue in an environment
where the user logs into the domain with the operating system because the OS will handle the
password change appropriately. However, if someone only logs in via FileMaker and has no
FiIeMaker 5ecurity page 21
way to access the OS/Domain password dialogs, he will not be able to change the password.
Therefore, password expiry options cannot be used in such environments.
Menu access has been restricted to Editing only, again per the security grid. The other menu
options are All, which is self-explanatory, and Minimum, which is really only useful for a read-
only privilege set.
The fnal setting to discuss is in the Extended Privileges area. The fmapp privilege has been
selected, and that means that this user will be able to access the database over a network. If that
privilege wasn’t granted and the database was hosted with FileMaker Server 8, the user would
not be able to log in. Notice that there are other Extended Privileges. They’ll be discussed in
the next section.
Figure 15
Extended Privileges
Extended Privileges are primarily for controlling database access by other tools. The fmpiwp
extended privilege enables access via Instant Web Publishing. It’s possible to have FileMaker
Server 8 host databases that are only accessible via the web, not with FileMaker Pro 8.
The default extended privileges are shown in Figure 16. The fmiwp privilege allows a database
to be accessed via Instant Web Publishing. The fmxdbc extended privilege enables the data
base to be accessed via ODBC or JDBC. ODBC/JDBC sharing can still be specifed for the
database, but unless the currently effective privilege set has fmxdbc enabled, ODBC/JDBC
sessions will fail.
FiIeMaker 5ecurity page 22
The fmapp extended privilege allows the fle to be accessed via a FileMaker network connection.
This includes FileMaker Server as well as peer-to-peer sharing. Next comes fmmobile: this
extended privilege allows FileMaker Mobile to synchronize with the database.
Finally, there are a couple of new additions to the list of default extended privileges: fmxml
and fmxslt. These extended privileges control access to the fle via XML-based custom web
publishing and XSLT-based custom web publishing. In FileMaker 7, these extended privileges
were not available by default, and had to be added by hand to any fle requiring custom web
publishing access.
Figure 16
Working with Custom Extended Privileges
It’s possible to create new extended privileges by clicking the New button as shown in Figure
16. The Edit Extended Privilege dialog opens, as shown in Figure 17.
FiIeMaker 5ecurity page 23
Figure 17
A keyword needs to be assigned to the extended privilege. It should be meaningful so you’ll
be able to easily pick it out when you need to use it later. This extended privilege is going to be
used to control the user experience.
Figure 18
FiIeMaker 5ecurity page 24
The newly created extended privilege will appear in the extended privilege list. It’s now
ready to use. To make use of this privilege, we need to use the Get (Extended Privileges)
function. Figure 19 shows a startup script that creates a found set of East or West region
records depending on which extended privilege is present.
Figure 19
User Accounts
User accounts are the gatekeepers of the database system. They are used to authenticate
users. Authentication is the process of forcing a user to prove that they are who they say they
are. This proof is presented in the form of two pieces of information that only one specifc user
is supposed to know: the account name and password. When a new FileMaker database is
created, two user accounts are automatically created for that database: Admin and [Guest].
FiIeMaker 5ecurity page 25
Figure 20
The Admin account has full access to the fle, a requirement when creating a new database. If
you select the Admin account and then click Edit (or just double-click the Admin account), The
Edit Account dialog will appear, as shown in Figure 21.
Figure 21
FiIeMaker 5ecurity page 26
Passwords are required for each account name, but blank passwords are permitted. The default
Admin account has a blank password assigned to it. This is fne as long as the developer is the
only user of the fle, but it’s important to change the password to something more obscure prior
to deploying the system. History is littered with stories of compromised security all because
the system administrator or database administrator (DBA) didn’t bother to change the default
passwords. Unless you have a good reason for letting all users in with full access, such as a
testing or perhaps a training environment, you should NEVER leave default passwords enabled
on a system after it’s been deployed.
There are two ways to disable the automatic login behavior. One way is to select FiIe>FiIe
Options to bring up the File Options dialog as shown in Figure 22. That dialog allows you to
disable the ‘Log in using’ option. Another way happens automatically when you change the
default Admin account password. If the Admin account password doesn’t match the password
in the File Options dialog, then a user will get presented with the login dialog.
Figure 22
FiIeMaker 5ecurity page 27
The top box in the Edit Account dialog shows the authentication method. FileMaker
authentication can be done in two different ways: internally and externally. Internal authentication,
which is the ‘FileMaker’ setting, means that the collection of usernames and passwords is
managed in the FileMaker database fle. Strictly speaking, passwords are not stored with the
fle. When passwords are created or changed, a one-way hash algorithm (based on respected,
industry-standard methods) converts them into irreversible strings that are stored in the fle.
What this means is that the passwords are irreversibly encrypted when they’re entered. When a
user enters the password into the login dialog, that password is also encrypted and compared
to the encrypted password string. While the possibility exists for cracker software to try every
combination of strings and compare hashes to fnd a match, using more than three characters
for a password makes this process extremely time consuming and diffcult to accomplish. Of
course, if the fle is hosted from FileMaker Server and secured properly so no one can gain
physical access to the fle, even that possibility is removed.
External authentication, shown in Figure 23, means that the username and password will be
passed to an authentication server. The exact behavior depends on how authentication is
confgured in the operating system of the server machine. On either platform, the authentication
could be local (set up manually on the server machine), or domain-based (relying on an
authentication server of some kind, either Active Directory on Windows or Open Directory on
Mac OS X). The authentication server could be a separate machine, or potentially the server
machine itself. It depends entirely on the server machine’s authentication setup.
Figure 23
FiIeMaker 5ecurity page 28
Take a closer look at Figure 23. Because the authentication method is External Server, the
Account Name became a Group Name. When user credentials, (the user name and password) are
authenticated by an external server, that user’s group membership list is returned to FileMaker
Server 8, which will compare the authenticated group list with the group name specifed for the
account. If the specifed group name matches one in the list, the user is granted entry with the
corresponding privilege set in effect.
This means that there needs to be some coordination between the person setting up FileMaker
security settings and the person who maintains the group for the workgroup or domain. As the
database developer, you’ll need to determine how many different levels of access you’ll need.
We’ll cover this topic in more detail in the next section, but for now let’s say that you need one
for administration, one for a manager level, and perhaps some different user departments. For
ease of maintenance, it makes sense to use a common prefx for all groups:
FMPAdmin
FMPMgr
FMPMarketing
FMPSales
These groups will be easy to remember and maintain on the workgroup or domain server.
Note that the authentication method is set on account-by-account basis. In a database that
has some accounts being authenticated by FileMaker and some accounts being authenticated
externally, the user’s login credentials will determine which method will be used. It’s theoretically
possible to have the same user name and password used for FileMaker access and network
domain or workgroup access, meaning that a user could be authenticated either way. This is
where the authentication order comes into play. Whichever account is higher on the Accounts
list (shown in Figure 20) is the one that will be used.
Regardless of how you set up your authentication scheme, FileMaker Server 8 needs to be
confgured appropriately. The default setting is to authenticate using FileMaker accounts only.
If you want to blend FileMaker accounts and external accounts, FileMaker Server 8 needs to
be confgured as shown in Figure 24. It’s impossible to confgure a fle so that all accounts are
externally authenticated. A fle requires at least one FileMaker account with full access.
FiIeMaker 5ecurity page 29
Figure 24
A word of caution about external account authentication: Although it’s extremely unlikely, it’s
theoretically possible for someone to acquire a copy of your database fles, serve them up on
a server of their own, confgure the server to use external authentication, and allow themselves
to point FileMaker Server 8 at their own authentication server. Even then, this will only work if
they know which groups you authenticate against. That will only give them the same access that
the group has, which may not be full access. If they’re capable of doing all of this and they know
your authentication groups, odds are they probably already had access to the system and this
kind of effort won’t put them any farther ahead than they already were. About the only person
capable of doing something like this is a rogue IT administrator or database administrator.
Again, they probably already had access to the system to start with. The moral of this story is
that the fle should be physically secured so they cannot take the fle to their own server.
Before we fnish the topic of User Accounts, there are two more items to discuss. One is that
each account can be set to Active or Inactive. This setting determines whether that account
can be used to log into the system. The Inactive setting has a variety of uses. If an organization
has several people starting all at the same time, it’s convenient for the database administrator
FiIeMaker 5ecurity page 30
to set up those accounts in advance so that a large amount of work doesn’t have be done the
day the new people start. They can be set up as inactive accounts and then turned on when
necessary.
The inactive status is also useful if a user is going on vacation or extended leave. While not
desirable, it often happens that users share passwords in order to facilitate work getting done.
If anyone has acquired that absent person’s username and password, a temporary inactive
account status will make sure that the account is not used in the interim.
The second item concerns a key ingredient to a user account: the privilege set. On the Edit
account dialogs shown in Figures 18 and 20, you should note that the account was tied to
one and only one privilege set. It’s impossible to set up a user account without designating a
privilege set.
Exercise 1: Defning Accounts and Privileges:
In this exercise, we’ll add some additional accounts and privileges to the Sales_System_01.fp7
fle. By default, the fle already has an Admin account with full privileges (including all database
design privileges) and a Guest account with very limited privileges. We’d like to add a couple
of intermediate privilege levels: one for sales managers, who have the ability to edit team
and personnel information, and another for sales people, who can only work with transactions.
Neither privilege group should be permitted to perform database design functions such as
creating layouts or defning felds.
By default, a new FileMaker 8 fle is set to open automatically with the default Admin account.
(This is to ensure that FileMaker 6 behavior is preserved, while also ensuring that new fles do
have an Admin account). To force users to login, we’ll also need to disable this automatic login.
1. Add a new Privilege Set to the fle, called Sales Manager. The Sales Manager group
should have the ability to create, edit and delete in all tables, but no ability to edit
layouts, value lists or scripts.
2. Create a new Account called Sales Manager. Assign the account a password of
“manager.” Assign the Sales Manager Privilege Set to the account.
3. Add a new Privilege Set to the fle, called Sales Staff. Sales Staff may view records in
Team and SalesPerson, but may not edit them. Sales Staff have full editing and deletion
privileges in Transaction. Sales Staff, like Sales Manager, may not perform any database
design actions.
4. Create a new Account called Salesperson. Assign the account a password of “staff.”
Assign the Sales Staff Privilege Set to the account.
FiIeMaker 5ecurity page 31
5. Disable the automatic Admin login, so that all users will be forced to provide a user
name and password.
6. Close the fle, then open it again and log in as Salesperson. Note that you can navigate
to Team and Salesperson layouts, but can’t edit data.
7. Close the fle, then open it again and log in as Sales Manager. Note that you can edit all
types of records, but don’t have access to feld defnitions, scripts, or layout mode.
Exercise 2: Adding a Re-Login Script
In this exercise, we’ll work with the Re-Login script step, which was added with FileMaker 7. Re-
Login can be an important part of a FileMaker security infrastructure. One particularly handy
use for this new script step is for developers who need to test their system under a variety of
different privilege levels. Creating a few re-login steps can make that process a great deal
easier.
In this exercise, we’ll build on the fle we worked with in the previous exercise:
1. Create a new script in the fle called “Log In as Admin.” It should contain the Re-Login
script step, specifying Admin as the user, with a blank password. Make sure the script is
set to display in the Scripts menu.
2. Create similar scripts that will allow the user to re-login as a Sales Manager or
Salesperson.
3. Trigger the various re-login scripts and verify that your privileges change each time.
Exercise 3: Adding a “Privilege Viewer”
To help in debugging our security work during development, it would be nice to be able to
pop up a dialog box that gives information on the current security settings. The dialog should
show the current account name, current privilege set, and any extended privileges that are
active. We’ll continue to build on the fle from the previous exercise. This can also be done with
the Data Viewer in FileMaker Pro 8 Advanced.
1. Create a new script called Show Privilege Information. It will show a custom dialog box
that will list the current account name, current privilege set, and any current extended
privileges in a comma-separated list. (Hint: you’ll need several of FileMaker’s Get()
functions to do this).
2. Log in and re-login as various users. Run the new script each time and see how the
output changes.
FiIeMaker 5ecurity page 32
3. By default, the existing privilege sets won’t have any extended privileges enabled.
Enable some extended privileges, such as fmapp, and see how the dialog box display
changes.
Exercise 4: Adding a Custom Extended Privilege
The built-in access controls in FileMaker are powerful, but have some limitations. Suppose
we decided that the sales staff should have no access whatsoever to team records. If we edit
the Salesperson privilege set to disallow any access to team records, when a user clicks the
“Teams” button, they’ll still be taken to the Team layout, but all the data felds will show an “<No
Access>” message. It would nicer to show the user a warning at the time they click the button.
1. Edit the Sales Staff privilege set to deny salespeople access to team records. You can
either edit the layout privileges to allow the privilege set no access to team layouts,
or edit the record-level privileges to disallow viewing of team data. Or you could be
thorough and do both. (Please note this doesn’t prevent you from seeing the data.
Create a new fle and reference this fle and you can create all the layouts you want
showing the records. Lock down the rocord via record-level privileges and this is not a
problem.)
2. Switch to the transactions layout, then re-login as a salesperson and click the Teams
button. Depending on how you changed the privilege set in step 1, you’ll either see a
layout with felds marked “<No Access>”, or the entire layout will be grayed out with the
words “<No Access>” visible.
3. Switch back to Admin access. Create a new extended privilege called “teamaccess”.
Assign the extended privilege to the [Full Access] and Sales Manager privilege sets.
Use the Show Privilege Information script you created in Exercise 3 to verify that the
new extended privilege is working for those privilege sets.
4. Modify the Nav Team script to check for the existence of this extended privilege. If the
user does not have the “teamaccess” privilege, the script should display a friendly error
message and perform no navigation.
File List Filtering
When hosting database fles with FileMaker Server 8, it’s possible to flter the list of available
fles that is presented to the user in the Open Remote File dialog. In Figure 26, FileMaker Server
8 shows three fles available for access. If FileMaker Server 8 is confgured to “Display only the
databases each user is authorized to access,” then that list will be restricted. This can work in a
couple of different ways.
FiIeMaker 5ecurity page 33
Figure 26
On Windows, when a user clicks on a FileMaker Server 8 host in the Open Remote File dialog,
FileMaker Pro 8 will take the credentials that the user used to login to that machine and pass
them to FileMaker Server 8. If properly authenticated, a list of available fles will appear. If no
fles match those credentials, the user will be prompted with a login dialog so that different
credentials can be entered, and the process will repeat. If the user already knows that the
machine login credentials don’t work for the required fles, holding down the Shift key while
clicking on the Host entry will invoke the login dialog right away. Once the user has authenticated,
the fltered result will appear in the Available Files list, as shown in Figure 27.
Note that this fle list fltering is somewhat different from the ability to designate a fle as “multi-
user, but hidden”. The latter temporarily hides a fle from the user’s view, whereas the fle list
fltering makes it appear as though the fle is not on the server at all.
FiIeMaker 5ecurity page 34
Figure 27
This same process holds true for fltered available fles. FileMaker will attempt to open a selected
fle with the machine login credentials. If different credentials are required, the user will need to
hold down the Shift key to invoke the login dialog and enter different credentials.
The Mac OS X process is similar, except that credentials stored in the keychain are used. To override
keychain credentials, the user will need to hold down the Option key to invoke the login dialog.
Final word: Note that these account, privilege set and extended privilege set security settings
are specifc to each fle. A FileMaker database fle can contain multiple tables, and the security
settings apply to each table within the fle. If, for any reason, you need to impIement a database
soIution that consists of muItipIe ñIes, you’II need to maintain separate security settings in each
ñIe (though it’s possibIe to maintain accounts and passwords across muItipIe passwords through
carefuI scripting}.
FiIeMaker 5ecurity page 35
Review Questions:
1. What are the three main components of FileMaker security?
2. When creating a new database, what default accounts are automatically created?
3. When creating a new database, what default privilege sets are automatically created?
4. What is external authentication?
5. What types of servers can be used for external authentication?
6. Explain the difference between pessimistic and optimistic default settings.
7. What are some ways that FileMaker can be protected on the network?
8. What are Extended Privileges for?
9. What kinds of custom privileges can be applied to record access?
10. How does fltered fle display work?
FiIeMaker 5ecurity page 36
Review Answers:
1. User Accounts, Privilege Sets, Extended Privilege Sets
2. Admin and [Guest].
3. Full Access, Data Entry Only, and Read-Only Access.
4. When a user account is set to authenticate via an external server, the login information
is passed to FileMaker Server 8, which passes it the host operating system for
authentication. If authentication is successful, the user’s group memberships will be
passed back to FileMaker Server 8.
5. Available authentication methods are entirely conditioned by the operating system in
use for the FileMaker Server machine. For both Mac and Windows, the server can be set
up to authenticate using local accounts and groups, or accounts and groups from some
authentication server, either the server machine itself or a different machine.
6. Pessimistic settings exert the most control over user actions, while optimistic settings
exert the least control. Pessimistic settings assume the user is potentially hostile, while
optimistic settings assume the user is trustworthy.
7. When using FileMaker Server 8, network traffc between FileMaker Server 8 and
FileMaker Pro 8 clients or FileMaker Server 8 and a FileMaker Web Publishing Engine
is encrypted. FileMaker Server 8 can be confgured to only display those databases
that a user is authorized to use. Firewalls and VPN’s can be used to protect FileMaker
databases from hackers outside the local area network.
8. Extended Privileges are for controlling access to the database from Instant Web
Publishing, Custom Web Publishing (XSL), XML, ODBC/JDBC, FileMaker Pro 8 and
FileMaker Pro 8 Advanced via the network, and FileMaker Mobile. Custom extended
privileges can also be created for purposes of scripted navigation control, data
validation, or allowing an Active-X control to run, among other things.
9. View, Edit, Create, Delete, and Field Access. Each one of those privileges, except for
Create, can be confgured for limited access.
10. File fltering is enabled by confguring FileMaker Server 8 to display only the databases
each user is authorized to access. The result is that once a user has been authenticated
to FileMaker Server 8, the Available Files list will only contain fles that the user has
access to.