FileMaker Security Features Overview

Implementing sound security practices can be complicated, and the effort shouldn't be undertaken without a security plan. It's difficult to construct a good FileMaker security plan without first having an overall sense of how FileMaker's security tools work, so this chapter starts with a review of FileMaker's security features. That is followed with a methodology for using FileMaker's security tools to design and implement a database security plan.

FileMaker Pro 7's security features are radically different from the security feature set that has remained almost unchanged for the last several versions of the product. Even if you consider yourself a security expert with previous versions of FileMaker, you should read this next section and familiarize yourself with the security tools that FileMaker Pro 7 puts at your disposal. These security features are clustered into three main components :

• Accounts

• Privilege sets

• Extended privileges

Briefly, accounts control which users have access to the database; privilege sets control what logged-in users can see and do; and extended privileges control network access to the database by client copies of FileMaker Pro, and also tools such as ODBC/JDBC, the Web, and FileMaker Mobile. In addition, custom extended privileges can be created for a variety of purposes.

The following sections discuss all three components in detail. The first you should understand is the Accounts feature.

Accounts

Accounts control user access through a login process. When a user wants to log in to the database, she must provide credentials to prove her identity. These credentials take the form of an account name and a password. After she has entered the credentials, FileMaker authenticates those credentials, which means that it checks those credentials against the file's list of authorized accounts. If (and only if) the account name matches a name in the list, and the corresponding password matches the password assigned to that account, then the user is granted access to the file. That access is further governed by a set of rules, called a privilege set .

When you're logged in to a database file with full access privileges, you can choose F ile, D efine, A ccounts & Privileges to bring up the Define Accounts & Privileges dialog, as shown in Figure 12.1.

Figure 12.1. The Admin account is created automatically when you create a new file.

The dialog contains three tabs that correspond to the three main components of FileMaker Pro's security system. The Accounts tab is highlighted. In the lower-right corner of the Define Accounts & Privileges dialog is a pop-menu that allows you to view the accounts by three different criteria: creation order, authentication order, and account name. The authentication order is the important one, because it means that if a user provides credentials that match up to more than one account (you'll see how that might happen later in the chapter), then the authentication order determines which account is logged in.

NOTE

Although accounts are usually thought of as being associated with human users, Web servers and ODBC sessions can also make use of FileMaker accounts. For the sake of this chapter, though, we'll refer to "users" as if they were always human users.

When you create a new database file in FileMaker Pro 7, the two accounts shown in Figure 12.1 are automatically created. One is an administrative account called Admin, which has full access to the database. The other is a guest account with read-only access. If you double-click on the Admin account, the Edit Account dialog opens, as shown in Figure 12.2.

Figure 12.2. Selecting the Admin account and clicking the Edit button invokes the Edit Account dialog. You can double-click the Admin account to get the same effect.

FileMaker Accounts

At the top of the dialog is the selection menu for the authentication method. FileMaker can either use accounts and passwords stored in the database file to self-authenticate, or use an external server for authentication. A FileMaker account is one that is stored in the file. Each FileMaker file must have at least one full-access FileMaker account.

From time to time, developers or users have been known to lock themselves out of their own databases. Sometimes the person who created the database leaves the company and the full access password is lost. Sometimes people just forget the full-access password. In previous versions of FileMaker Pro, lost passwords could be recovered by FileMaker, Inc., and by password recovery tools. That is not the case with FileMaker Pro 7. Passwords stored in the file are irreversibly encrypted and can't be recovered.

External Accounts

Users need to know a lot of passwords these days. In most organizations, users need to log in to their computers before they can even launch any applications. They need to have usernames and passwords for their email accounts, and other usernames and passwords for various network resources such as file servers and even their FileMaker databases. Some organizations like to centralize their administration of user accounts and passwords so that it takes less time to maintain all these passwords. To do this, they set up an authentication server . It's possible to have FileMaker Pro use an authentication server to validate login credentials.

NOTE

External server authentication requires the use of FileMaker Server. If you're using a file in single-user mode on your local hard drive or sharing the file peer-to-peer with other copies of FileMaker Pro, you can't use an external server to authenticate accounts.

FileMaker Pro 7 is flexible in that you can mix and match account authentication methods within a single file. You can have some accounts that are authenticated by FileMaker, and other accounts that are authenticated by an external server. For deployment environments with a large number of users and a regular IT infrastructure, a good strategy would be to set up database administrator accounts that are authenticated by FileMaker, and then user accounts that are authenticated by an external server. That way, IT personnel who may not be familiar with FileMaker administration can maintain user accounts with tools that they're familiar with, and developers can still log in to the database files with full access even if they're disconnected from the network and unable to authenticate with an external server.

TIP

This same account configuration is also a good strategy if you need to do offline development and swap in new database files in from time to time. If user accounts are maintained outside FileMaker, you don't need to worry about any account additions or modifications that might have been made while you were making changes to a copy of the file (or files). As long as no changes have been made to groups, any user account changes are incorporated automatically as soon as you host the files with FileMaker Server.

External Authentication on Mac OS X

FileMaker Server needs to be configured to make use of an external authentication server. This process is slightly different for the Mac and Windows versions of the Server Administration Tool (SAT), so we review both methods.

For more on using the Server Administration Tool to configure FileMaker Server, see "Configuring and Administering FileMaker Server Using the SAT," p. 746 .

On Mac OS X (version 10.2.8 or later), you need to launch the FileMaker Server Admin tool. Choose Server, Connect to FileMaker Server to bring up the Connect to FileMaker Server dialog. Depending on where you run the FileMaker Server Admin tool, you might be connecting to a copy of FileMaker Server on your local machine or somewhere out on the network. After you've connected to the server, click the Configure button. Click the right-most tab on the configuration screen, which is the Security tab. The selected Security tab is shown in Figure 12.3.

Figure 12.3. In Mac OS X, the Security tab needs to be configured if you plan to use external server authentication for clients .

External Authentication on Windows

Now let's take a look at this process for the Windows FileMaker Server Admin tool, which we're going to start abbreviating as SAT. Like the Mac OS X version of the SAT, it doesn't matter if FileMaker Server resides on the same machine as the SAT or on a machine elsewhere on the network.

Because the Windows version of the SAT runs in the Microsoft Management Console, or MMC, the standard view has no tabs as there are on the Mac. If you prefer to use a tabbed interface, you can right-click on the server name and select Properties to bring up the FileMaker Server Properties dialog shown in Figure 12.4. If instead you use the MMC, you configure the various components by using Assistants that step you through the process. Click the Security icon to run the Security Assistant, as shown in Figure 12.5.

Figure 12.4. The FileMaker Server Properties dialog consolidates all security options in one place.

Figure 12.5. The Security Assistant steps you through the process of configuring FileMaker Server's security settings.

After a screen or two, you'll come to the screen shown in Figure 12.6. This screen shows some of the same settings you just saw on Mac OS X and on the FileMaker Server Properties dialog.

Figure 12.6. Just as with the Mac OS X version of the SAT, the Windows version enables you to authenticate using either local or domain user accounts and groups.

After you've decided whether to authenticate with local user accounts and groups or domain user accounts and groups, you can click through the remaining Security Assistant screen (which we'll come back to later in this chapter) and complete the Security Assistant.

FileMaker Account Passwords

In earlier versions of FileMaker, it was possible to have a file that had no passwords or security restrictions at all. With FileMaker Pro 7, every file has to have an account with full access to the file. Although the default Admin account can be deleted, you still have to have at least one account with full access before you can exit the Define Accounts & Privileges dialog. The [Guest] account can't be deleted at all. In fact, throughout the Define Accounts & Privileges dialog, if you see anything wrapped in square brackets [], that means it can't be deleted.

FileMaker Pro 7 makes a few things happen automatically when a new file is created. First of all, as we've seen, the Admin and [Guest] accounts are created automatically. If that was all that happened , then the file would prompt a user for a password as soon as it was re-opened after its initial creation. That doesn't happen, and if you choose F ile, F ile Options to bring up the File Options dialog shown in Figure 12.7, you can see why.

Figure 12.7. Newly created files are automatically set to open with full access.

The file is automatically set to open with the default Admin account. That means that as soon as you want to deploy your file with the access privileges you set up, you need to remove the automatic login behavior. The result is that the next time the file is opened, the user is presented with the login dialog shown in Figure 12.8.

Figure 12.8. When a file's default login has been disabled, users are presented with a login dialog when they attempt to open the file.

You should note that the Admin account has no password assigned to it. Actually, it's more accurate to say that it has a password, but the password is blank. Although it may be convenient in the short term to leave the password blank, it should definitely be changed before you deploy the system. The failure to change default passwords is a contributing factor in countless computer system break-ins. We'll say it once more: Always change the default password . Even if you want all users to have access to the file, it's rarely in your best interest to have users in there with full access. That would mean they could change the full access password, intentionally or not, and lock you out of your own file. If you want to let the world into your database, let them in with something less than full access.

Another noteworthy characteristic of FileMaker accounts is that when the account name and password are identical, you can log in to a file by leaving the account name blank and just entering the password. The reason for this is that when a file has been converted from earlier versions of FileMaker Pro, any existing passwords are converted to accounts that have the same account name and password. For example, if a file had a password called Admin, during conversion to the FileMaker 7 format, a FileMaker account called Admin would be created, and it would have Admin for the password.

To learn more about what to do if you've forgotten your password, refer to "Locked Out of Your Database" in the Troubleshooting section at the end of this chapter.

For more on conversion issues, see "Migration Choices," p. 508 .

During a login, FileMaker displays bullet characters instead of the actual text when you type in your password. This is a security measure intended to make it more difficult for someone looking over your shoulder to learn your password. Because the account name is entered in clear text, someone who knew that account names and passwords were identical (which would be the case immediately after a file conversion) could easily learn your password by looking at your account name.

External Server Passwords

The Account Name and Password entry boxes appear only when the account is authenticated via FileMaker. If you switch the account so that it's authenticated via an external server, the Edit Account dialog changes to look like the one shown in Figure 12.9.

Figure 12.9. Accounts that are authenticated though an external server specify only a group name, not an account name and password.

Because the Account Name and Password information is stored in the external authentication server, you don't need to enter that information in the Edit Account dialog. When those credentials are passed to the external authentication server, what comes back is a list of groups to which the account belongs. That's why, when you switch the authentication to External Server, you get an entry box for the Group Name.

There are some implications to this, so it's a good idea to talk through a couple of examples.

Imagine that you have a user who gets authenticated by the external server. On that external server, you set up two different FileMaker groups. One is FMP Manager, and the other is FMP User. You have also set up two externally authenticated user accounts in FileMaker that specify those two groups.

The example user belongs to both groups, and thus can use either account. (This is the only way that user credentials can match up to multiple accounts, by the way. FileMaker prevents you from creating accounts that don't have unique account names or group names.) Suppose the example user logs in with her credentials and the authentication server returns FMP Manager and FMP User as the group names. What happens? To answer that question, we need to revisit the Define Accounts & Privileges dialog, which is shown in Figure 12.10.

Figure 12.10. The authentication order determines which account is authenticated in cases where credentials match more than one account.

You get to control what happens in cases where user credentials match up to more than one group account. By setting the authentication order, you can determine which account authenticates. A reasonable policy is to decide that if a user has credentials for more than one account, the account with the highest level of access should be authenticated. That's the configuration shown in Figure 12.10.

Suppose that you set your authentication order so that the accounts with the lowest level of privileges authenticate first, and that the account with the least access is authenticated by an external server. Then suppose that a well-meaning IT person accidentally assigns everyone to that group. The result would be that no one with externally authenticated accounts would be able to get in with anything other than the lowest level of access. This is also a good illustration of why your administrator-level passwords should be authenticated by FileMaker, not by an external server. If you're not careful with your group management on externally authenticated accounts and you authenticate weaker accounts first, you can, at least temporarily, lock yourself out of your database.

You could remedy this dire scenario by removing the high-level users from the low-level group on the external server (and then logging back in to the system), but we want to drive home the point that you need to put some thought into your security configurations.

If you're having problems trying to get all accounts to use an external authentication server, refer to "Can't Delete Last FileMaker Account" in the Troubleshooting section at the end of this chapter.

Controlling Password Changes

Figure 12.2 is reproduced in Figure 12.11 so you don't have to flip pages back and forth as we discuss the rest of the Edit Account dialog. The next item to consider in the Edit Account dialog is the User Must Change Password on Next Login check box. This feature, too, has a potential pitfall. If this option is checked, but the privilege set specified by the account doesn't allow the user to change his password, the user is not allowed to log in.

Figure 12.11. Check User Must Change Password on Next Login only if the assigned privilege set permits password changes.

That consideration aside, it's generally a good security policy to have users set their own passwords. That way, the database administrator doesn't have knowledge of any account passwords but his or her own. After they are entered, passwords can't be determined even by those with full access.

NOTE

For accounts that will be used by Instant Web Publishing users, you should never check the Change Password option because that feature isn't supported by Instant Web Publishing.

Other Account Settings

The next item is the Account Status setting. In previous versions of FileMaker, if you wanted to temporarily disable an account when someone was on leave, your only option was to completely remove the account and set it back up again later. In FileMaker Pro 7, you can set an account to be inactive and then just re-active it again at a later date.

TIP

If you have a large group of employees all starting on the same date, the account status feature allows the database administrator to set up all the accounts in advance without activating them. After the employees start, all that needs to be done is to set the account status to Active.

The next item is the privilege set. The privilege set controls the behavior of the account after it's been authenticated. Privilege sets are a large topic unto themselves, and are covered in detail in the next section.

The last item is the description. Especially for externally authenticated group accounts that don't necessarily match up to a person, it's often helpful to have a short description of the purpose of that account.

Privilege Sets

The second tab in the Define Accounts & Privileges dialog is the Privilege Sets tab. When you create a new database file in FileMaker Pro 7, the three privilege sets shown in Figure 12.12 are automatically created.

Figure 12.12. Three default privilege sets are automatically created whenever you create a new file.

Again, anything wrapped in square brackets [] can't be deleted. In the case of these three default sets, they can't really be changed, either, although extended privileges for the three sets can be enabled.

To cope with problems using a full access account with a file hosted by FileMaker Server, refer to "Can't Access Database Hosted by FileMaker Server" in the Troubleshooting section at the end of this chapter.

Creating a New Privilege Set for a User

You can create a new privilege set by clicking the New button. This brings up the Edit Privilege Set dialog shown in Figure 12.13.

Figure 12.13. This is the default state when a new privilege set is created in FileMaker Pro 7.

Let's take a moment to contrast this with earlier versions of FileMaker Pro. Figure 12.14 shows the Define Passwords dialog from FileMaker Pro 6. If you just created a password without changing any settings, the default level of security was full access. This can be termed an optimistic level of security; all options are granted and need to be shut off if necessary. In contrast, the default state of a new privilege set in FileMaker 7 is pessimistic. All options are shut off and need to be granted if necessary.

Figure 12.14. This is the Define Passwords dialog from FileMaker Pro 6. FileMaker Pro 6 and earlier versions had security settings that defaulted to full access.

It seems like a small nuance, but the difference is an added layer of security. In earlier versions, if a database administrator forgot to uncheck an option, the result was too little security. In FileMaker 7, if a database administrator forgets to grant an option, the result is too much security, which is preferable. This is an important consideration when converting older systems into FileMaker 7. The optimistic settings of the older systems are re-created in FileMaker 7.

TIP

When you convert systems that were created in earlier versions of FileMaker pro, be sure to review security post-conversion to make sure the settings meet your security requirements.

For more on addressing security issues after a conversion, see "Post Conversion Tasks," p. 522 .

In the Edit Privilege Set dialog (refer to Figure 12.13), you can see that it has three distinct areas: Data Access and Design, Extended Privileges, and Other Privileges. Remember that at the beginning of the chapter we talked about developing a security plan before implementing your security settings. To do that properly, you need to be aware of the security options available to you. As we go through these settings, you should be mentally noting them as tools to help implement your security goals.

The first thing you need to do is name the privilege set. For this example, it's Salesperson, the idea being that this is the privilege set that will be assigned to any users who are salespeople.

If you click on the pop-up menu next to Records, as shown in Figure 12.15, you can see that you have a variety of options when it comes to record access. Note the list of tables at the top of the dialog. For simple systems, it's possible that some users might need to have the same type of access for all tables in the system. In systems of any complexity, though, this probably isn't going to be the case. Marketing or accounting or human resources people might have a high level of record access in marketing- or accounting or human resources “ related tables, and a low level of access in other tables.

Figure 12.15. For each privilege set, you can grant full, partial, or no access to records in the database. You can also customize record access.

The example at hand has a very simple system with only two tables: contact and salesperson. The rules will be that each contact is "owned" by a salesperson, and salespeople can edit or delete only contact records that belong to them, although they can view contact records that belong to others.

In the Salesperson table, only a sales manager can create, edit, and delete records, although a salesperson is allowed to edit his own particular record. This sort of table-specific access requirement is very common, but it doesn't work with simple access rules that apply to all tables. To implement this scenario, you need to use Custom Privileges for record access. Selecting that option will bring up the Custom Record Privileges dialog shown in Figure 12.16.

Figure 12.16. The default state for a new privilege set is to have all access shut off.

In the Custom Record Privileges dialog, you can set rules for record viewing, editing, creating, deleting, and field access on a table-by-table basis. In addition to that, you can set those rules for any future tables that haven't even been created yet. As new tables get created, they'll automatically pick up the settings specified for [Any New Table].

Notice that once again, FileMaker Pro's default security state is pessimistic. All access is shut off until you specifically grant it. If you want to apply the same setting to two or more tables, you can Shift-click tables to select a range of tables, or ( -click) [Ctrl+click] to select noncontiguous tables.

In the current case, you need different settings for different tables, so you need to set them up one at a time. First, select the Contact table and enable record viewing, as shown in Figure 12.17.

Figure 12.17. Record viewing can be on, off, or limited (based on calculated criteria).

Remember that salespeople can edit and delete only Contact records that belong to them. To implement that, you need to set up limited editing. When you select the Limited option for the Editing privilege, you get the Specify Calculation dialog shown in Figure 12.18.

Figure 12.18. The criteria used for limiting privileges must be Boolean, or an expression that can be evaluated as true or false.

Because you want to allow editing only in cases where the contact record belongs to the current user, you need to have FileMaker check the account name of the current user to be sure it matches the account name for the salesperson that's designated as the owner of the contact. The Get (AccountName) function gives you the name of the currently logged in user, and you can see whether that equals the account name information stored in the salesperson's record in the related Salesperson database. The resulting Boolean (true or false) calculation is

 Get ( AccountName ) = Salesperson by Salesperson ID::Account Name 

After this is done, the privilege for creating new records needs to be set to Yes, because all salespeople are allowed to create new contact records. That process is not cut and dried , however. Because each new contact record needs to be tagged with the ID of the salesperson that created it, record creation has to be a scripted process, and the ability for salespeople to create new records using the menu commands needs to be removed. This is covered later in the chapter.

To learn how to script the creation of contact records, see "Creating a New Privilege Set for a Manager," p. 333 , later in this chapter.

The next privilege is the Delete privilege, and that should be limited in the same way that the Edit privilege is limited. The last privilege is Field Access, and because salespeople need to be prevented from modifying the Salesperson ID to which a contact has been assigned, this privilege needs to be limited as well. Selecting that option brings up the Custom Field Privileges dialog shown in Figure 12.19.

Figure 12.19. The Custom Field Privileges dialog enables you to restrict access on a field-by-field basis.

It would be normal to assume that the Contact ID field is an auto-entered serial number with the Prohibit Modification of Value During Data Entry setting enabled, and if so, the field doesn't need any further protection. However, this is not the case for the Salesperson ID field. Because it controls the access privileges for each contact record, it needs to be locked down for salespeople. Select the field and then click the View Only radio button as shown in Figure 12.19. No other changes are necessary, so you can just click OK.

At this point, the settings for the Contact table are complete, and they should look like the settings shown in Figure 12.20.

Figure 12.20. The Custom Record Privileges are complete for the Contact table.

The Salesperson table has different rules. Although every salesperson can view every other salesperson's record, only a sales manager can create or delete records. A salesperson can edit his personal information on his own record, although he can't change his Salesperson ID or Account Name. To enforce these editing rules, you need to use the Limited option for the Edit privilege. The calculation will again be a Boolean calculation that makes sure the currently logged-in user has an account name that equals the value in the Account Name field, as shown in Figure 12.21.

Figure 12.21. This calculation ensures that a salesperson can edit only his own record.

For field editing restrictions, we'll assume again that because the Salesperson ID is the primary key, it is already an auto-entered serial number with the Prohibit Modification of Value During Data Entry setting enabled. To enforce the rule that a salesperson can't edit an Account Name, you need to limit the Field Access privilege, as shown in Figure 12.22.

Figure 12.22. Salespeople can edit their personal contact information, but not their Account Name, which needs to match the Account Name in the security settings.

That takes care of the custom record privileges for the salesperson privilege set, but some other settings need to be adjusted. Salespeople need to have access to layouts, value lists, and scripts, although they can't edit any of these. If they can't get to a layout or make use of a value list or run the appropriate scripts, they probably won't be able to use the system properly. When a sales manager sets up a new salesperson record, the corresponding account will be established with a temporary password. That means that salespeople need to be able to change their own passwords.

They also need to be able to print, and because salespeople will be accessing the system while it's being hosted by FileMaker Server, the Access via FileMaker Network Extended privilege needs to be enabled. Later in this chapter you'll learn how to control the creation of contact and salesperson records by scripted logic. To force users to work only through the scripted process, the menu commands need to be set to Editing Only. That will prevent salespeople from using the menu commands to create new records. The result will be the settings shown in Figure 12.23.

Figure 12.23. These are the final settings for the Salesperson privilege set.

Creating a New Privilege Set for a Manager

The next step is to create a privilege set for sales managers. Obviously, the sales manager privilege set enables them to do much more than a salesperson. They'll be able to create, edit, and delete records in both tables, and they'll also be allowed to export records. For the sake of this example, we'll also allow them to manage extended privileges. Sales managers can have full access to menus , but all other settings are the same as the salesperson privilege set settings. The result is shown in Figure 12.24.

Figure 12.24. Sales managers have much more latitude in working with the system. Compare this figure to the salesperson settings in Figure 12.23.

Although that concludes the setup required for the privilege sets themselves, more work is needed to make those roles fully functional. Because salespeople are to be disallowed from using the New Record menu command to create new contacts, it's necessary to create a script that creates new contact records.

Before you get into the details of the script, you should review the logic. When a salesperson creates a new record, that record needs to have the Salesperson ID of the currently logged in salesperson automatically inserted. You need to be able to determine the appropriate Salesperson ID, and to do that, you'll create a calculation field called z_Logged In in the Contact table:

 Get ( AccountName ) 

Get functions, when used in a regular calculation, evaluate when the record is created ”or when the calculation is first created for existing records. It doesn't update when a new user logs in. The way to force the function to re-evaluate is to make it an unstored calculation by checking Do Not Store Calculation Results, as shown in Figure 12.25.

Figure 12.25. Forcing the calculation to an unstored state ensures that it re- evaluates each time someone logs in.

For more information on unstored calculations, see "Storage Options," p. 221 .

After the calculation has been created, then you can create the script that creates new Contact records with the salesperson's ID number. You need to test for situations where the sales manager or database administrator is logged in, and handle those situations accordingly . The BTN: New Contact script reads as follows :

 Go to Layout ["Contact" (Contact)] If [IsValid (Salesperson by Account Name::Account Name)]   #Currently logged in user has a record in the salesperson table   New Record/request   Set Field [Contact::Salesperson ID; Salesperson by Account Name::Salesperson ID] Else   #Currently logged in user does not have a record in the salesperson table   Show Custom Dialog ["New Contact Error"; "Because you are not a listed salesperson, this contact record cannot be linked to you. Contact the Sales  Manager to correct this situation."] End If 

In cases where the sales manager or the database administrator are creating new records, they'll need to manually assign them to a specific salesperson. Another issue needs to be considered . Remember that the salesperson privilege set was set up so that salespeople couldn't edit the Salesperson ID field in the Contact table. For this script to set that value, it needs to be enabled to run with full access privileges, as shown in Figure 12.26.

Figure 12.26. By enabling the Run Script with Full Access Privileges setting, a developer can allow scripts to perform functions that a user's privileges wouldn't allow.

That takes care of creating new contacts. The next step is to take a look at the script that will be used to create new salesperson records and add a corresponding security account.

This script needs to be much more sophisticated. It's generally a good idea to keep regular system users ”even higher-level users like a sales manager ”from editing the system security settings. To that end, this script takes the information from the Account Name field and attempts to create a new account with it. If the account already exists, the sales manager is notified. If the account doesn't exist, it is created with a temporary password that the salesperson is required to change on the next login. The BTN: New Salesperson script reads as follows:

 Set Error Capture [On] Go to Layout ["Salesperson Detail" (Salesperson by Salesperson ID)] If [Get ( PrivilegeSetName ) = "Sales Manager" or Get ( PrivilegeSetName ) = "[Full Access]"   New Record/Request   Loop     Pause/Resume Script [Indefinitely]     If [IsEmpty (Salesperson by Salesperson ID::Account Name)]       Show Custom Dialog ["Missing Account Name"; "You need to enter a unique account name  before you can proceed."]     Else       Add Account [Account Name: Salesperson by Salesperson ID::Account Name; Password:  "Temp"; Privilege Set: "Salesperson"; Expire password]       Exit Loop If [Get ( LastError ) = 0]       Set Field [Salesperson by Salesperson ID::Account Name; ""]       Show Custom Dialog ["Existing Account Name"; "You need to enter a unique account  name before you can proceed."]     End If   End Loop   Commit Records/Requests[] Else   Show Custom Dialog ["New Salesperson Error"; "Only Sales Managers can create a new  salesperson record."] End If 

Note that the script starts by setting error capture to On. This is to suppress the FileMaker error dialog that's invoked when the script attempts to create a user account that already exists. Also note the loop within the script. If the sales manager leaves the Account Name field empty or if a new account name is required, the script needs to loop back to the paused state so that the sales manager can complete the data entry.

For more information on looping and error trapping within scripts, see "Common Scripting Techniques," p. 249 .

This should give you a good feel for the capabilities of privilege sets in FileMaker Pro, and it should also give you some ideas about how scripts can interact with privilege sets.

Extended Privileges

As mentioned in the previous section, extended privileges can be assigned to privilege sets to expand their functionality. There are two types of extended privileges: default and custom.

Default Extended Privileges

The four default extended privileges are present automatically in any new file, and they can't be deleted. The default extended privileges, which are shown in Figure 12.27, control access to the file from other applications and technologies.

Figure 12.27. The four default extended privileges cannot be deleted.

The four default extended privileges are pretty self-explanatory:

• Access via Instant Web Publishing ” When Access via Instant Web Publishing is enabled for a privilege set, users with accounts attached to that privilege set have access to the file from a Web browser.

• Access via ODBC/JDBC ” Access via ODBC/JDBC needs to be enabled if you want an ODBC or JDBC client to use SQL to converse with FileMaker.

• Access via FileMaker Network ” Access via FileMaker Network needs to be enabled for privilege sets that need to access the file over the network when the file is being shared in a peer-to-peer fashion, or if it's being hosted with FileMaker Server so that FileMaker Pro clients can work with it. That isn't the only use for FileMaker Server, by the way. It's possible that you might want to host a database that will be accessed only from the Web, not from a FileMaker Pro client.

• Access via FileMaker Mobile ” If you're using FileMaker Mobile and you want to synchronize files between FileMaker and Mobile for one or more privilege sets, you need to enable Access via FileMaker Mobile.

For more on using ODBC/JDBC with FileMaker, see "Importing From an ODBC Data Source," p. 552 and "Accessing FileMaker Data Using ODBC/JDBC," p. 578 .

Custom Extended Privileges

Although important, the default extended privileges are the least interesting aspect of extended privileges. Where things really get interesting is with custom privileges. After they are created, the Get (ExtendedPrivileges) function can be used to detect their assignment to a privilege set. After an extended privilege has been detected , scripts can branch accordingly, fields can validate based on that information, or calculated values can conditionally display values. It's important to note that custom extended privileges have no inherent functionality.

For the sake of illustration, let's suppose that you have a sales contact database with a credit rating screen that gets populated by the Credit department. In a real world example, you might compartmentalize salespeople by team or office or market, and would then grant different privilege sets to each sub-group. In the interest of keeping this scenario simple, we presume a single salesperson group with a corresponding privilege set and use an extended privilege to control access to the Credit Rating layout, even though it would be sufficient to just use the privilege set itself to control access to the layout.

To create a custom extended privilege, you need to be on the Extended Privileges tab of the Define Accounts & Privileges dialog. Click the New button to bring up the Edit Extended Privilege dialog. A custom extended privilege needs to have a name, and because this privilege is to be used to control access to a contact's credit rating, type credit into the Keyword box, as shown in Figure 12.28. You can add a description of what the privilege is to be used for, and also assign the privilege to any of the privilege sets. After you've finished making these settings, just click OK. The new extended privilege displays in the list of all extended privileges, as shown in Figure 12.29. Custom extended privileges can be distinguished from default extended privileges by their lack of square brackets.

Figure 12.28. The Edit Extended Privileges dialog can be used to assign the privilege to one or more privilege sets.

Figure 12.29. FileMaker does not allow you to wrap a custom extended privilege with square brackets.

It's important to remember that extended privileges can be assigned only to privilege sets, not to individual accounts directly. For that reason, extended privileges can be used only to modify the privileges of classes of users. If you need to do things that modify individual accounts, you need to either have different privilege sets for each account, or manage those sorts of things using scripts that test for the currently logged in account and act accordingly.

To take advantage of the newly created extended privilege, we've created a script that permits navigation to a Credit Rating layout only when the currently logged in user has been granted the credit extended privilege. Assuming the existence of the Credit Rating layout and the credit extended privilege, the Credit Rating script would look like this:

 If [PatternCount (Get (ExtendedPrivileges); "credit")]   Go to Layout ["Credit Rating" (Contact)] Else   Show Custom Dialog ["Insufficient Privileges"; "You do not have sufficient privileges to  view the credit rating."] End If 

This is just a simple example of how extended privileges can be incorporated into your scripts and calculations to control navigation and field access. Because the detection of the extended privilege is calculation-based, it can also be used in field validation and even in calculated auto-entry situations.