The Separation Model – Part 8 – Security
In all likelihood, the only database you'll provide [Full Access] for all users is the database you ONLY use for yourself. Otherwise, we're going to be adding security - plain and simple.
In the Data Separation Model, there's a number of options which all depend on how you're going to deploy. If you're going the low cost route, then using External account authentication, by far the easiest method, is not going to be an option. External authentication requires FileMaker Server and preferably (although not required) a deployment of either Active Directory (Windows) or Open Directory (Macintosh). So, understanding how external authentication compares to using FileMaker's built-in accounts is critical to your deployment strategy. Using the low cost route means you need to get a few things right when using the Separation Model.
In terms of implementation, this will very likely employ the use of a default username and privilege set for the UI file, while the data file retains the collection of usernames and passwords which protects the data.
In this video, I take a fair amount of time to walk through the various settings and areas which you'll need to be familiar with. I discuss what to watch out for, and how the separation model will impact your security. If you've not taken the time to really understand what FileMaker is doing, from a security standpoint, then this video will have some great pointers for a better understanding.
Comments
Local Accounts also work
Note that if you are using External Authentication, a local account on the Server system will also work. That is, when FileMaker Server gets your account ID and password, it queries the local OS. The OS then first looks to see if there is a matching local account. If so, it tries to authenticate using that account. Otherwise, the OS queries the Open Directory or, (presumably) the Active Directory servers.
This is actually a very handy behavior for testing. For example, I have a local account on our Mac server (since I admin it) and use that account to open up databases if I have doubts about the Open Directory server. Otherwise, I have a separate account that is authenticated via Open Directory.
Thus, if you just have the one system (and only a few users), you could set things up so that anyone who needs access has a local account on the server itself.
You're totally right...
I sort of omitted that information because it's not how I would set up External Auth. Since my dev server setup is a Mac Mini with OS X, you've already paid for getting Open Directory and I just assume it's easier to set it up that way. However, a Win FMP server won't necessarily have Active Directory installed unless you have a server version of the OS.
Yes, you can certainly use single signon with local accounts. As you mentioned, its' great for testing, but I wouldn't use it for deployment because it's not as portable.
Steven Blackwell called me out for saying that you "need" to use either AD or OD. But you don't really "need" to. You just should. Here's link to his more thorough information about security aspects within FileMaker.
http://fmforums.com/forum/blog/13-filemaker-security-blog/
-- Matt Petrowsky - ISO FileMaker Magazine Editor
Where is KarateApp8 ?
This is referenced in your video, but not offered for download.
KarateApp8
The file is attached to some of the other videos. Matt was more or less just explaining the security concepts, rather than making changes to the file. At least, that was my thought.
Josh Ormond
Josh Ormond