File Access Priviliges w/ ext file

[patrickglass]

Hello, i have build a database with the two file schema, one for front end and relations and the back end with only the data tables. this is just so i can do updates to the program without modifying the database itsself.

I not have come into the problem that i would like to secure it. i would like to have custom accounts for each type of user and many users itself ( < 100 ) maby 1 or 2 on at once within out local network. there is no real security risk with people viewing the data so much as it is just machine reports and inventory. but i would like to prevent from accidental changes. what is the best way to administer so many users. I am using Filemaker Pro 8 on Windows Xp with no intentions as of yet using FileMaker Server.

My main question is how do i set security for access for the backend defined file. when i go into Accees and Privaliges within the front end and go to custom access i cant see any of the data tables and therefore cannot protect them. do i have to do all the security for the data from withing the backend. Does the frontend sent the username to the backend to be process and querried as to what access they have been given.

Thanks for the time and please feel free to ask more questions as this is my first database. Patrick Glass

[Fenton]

Security settings are done for each file, so yes, you have to do it in each file. FileMaker knows which account is logged in. It will open the 2nd file with the same account/password, if it exists in both files.

[You don't say whether you want to have an account for each person, or just a few more generic accounts. The rest of this post is assuming an account per person. Otherwise just create the accounts/privileges manually. The big question is: Do you want the database to know who is logged in, for creation/modification/ownership fields? If so, each needs their own account. Otherwise just a few more generic accounts/passwords may be sufficient.]

With so many users I think you'd want to script the creation of accounts, unless you want to go into the guts every time you want to add or delete an account. Scripts are not that hard to do, just a few fields and scripts in each file. I have posted an example file in the Sample files section with one way to do this.

There are a few variations, depending on whether you keep the usernames/passwords afterwards (not very secure), whether you even set their passwords (or let them set them on 1st login). My example is the less secure type. But it can be made more secure by deleting the passwords afterwards. You want to keep the account name, so you can delete the account with a script later, if need be. You want to protect that table.

The great advantages of scripting account creation are that you can click one button to do it in both files. It is very fast. And you can create a simple interface so administrators can do it. It is not required that they be logged in with the Full Access account, as the scripts themselves can run with Full Access privileges (checkbox on the lower left).

Both files should have the same set of account names/passwords. They could have different privilege sets and names. It is somewhat simpler to keep them the same, but many configurations of Privilege sets are possible. Because you can test in the script, and assign many different accounts to the same privilege set, as well as reassign several privilege sets from the Data file to only 1 priv. set in the Interface file. You would likely have need of fewer privilege sets in the Interface file.

It seems a little odd that you'd have 100 people, but only 1 or 2 at once logged in.

[Steven H. Blackwell]

I recommend that you do look into use of FileMaker Server and its external server authentication capabilities. it will make your life easier.

Steven

[patrickglass]

Well thanks for all of the comments and Pooh-Bah I will definitely find you example. Well right now we are starting as a small database with few people only managers and data entry personnel with access. They will be run on dedicated computers. This is we will also be tracking part usage and I would like each mechanic to have a username and pass so that I can track changes. But all mechanics don’t have their own computer so at the part warehouse we will have the computer with the barcode reader and they log in and scan the part. That’s about it. So we don’t have the resources to be giving all our labor staff their own computer. We will eventually (once we have the need) switch to FM Server, but as of yet we are still putting this is a trial phase. So to put it plainly right now we have only 4 main users but I would like to plan for a bit in the future to have the ability to add more easily.

Also I was wondering if FileMaker Server can handle security that was placed in the actual file. Or does it have to be externally authenticated. I would just like to make portable solution that may once be able to grow, but for now remain small.

Patrick Glass

[Fenton]

If several use the same computer, each with a different FileMaker Account (created by script), and you wanted to use that to track use, you'd need a mechanism to force a Relogin after use, before the next guy wants to use it. There is a fairly simple Relogin script step that would do that.

After someone uses it, or as part of the script that does whatever it is they do, you could have a step (or button) Relogin to a Guest account; which has view-only access. Then a button to Relogin to a real account. So while the computer was just sitting there, it would not be logged in to anyone's account, and would not accept data entry.

The one glitch I see is that when and how to "log out" automatically if someone is doing various things. Server could help here, as it could wait, then drop them if the client FileMaker was idle for a set period of time.

As Steven says, FileMaker Server is what you need if you really care about your data (and who doesn't). It can authenticate either via just the FileMaker file settings or combined with external authentication. He would know more about that. It can also backup your data automatically.

But logging out on a shared client when several users are using it one after the other, with little idle time, is going to require an explicit Relogin routine, built into the interface data entry somehow. The trick would be to do it so that it was secure, but did not get in the way of data entry.

[P.S. "Pooh-Bah" is simply my "user status," not my name. It was somehow assigned to me, quite a while ago, probably because I post so much. And I could hardly argue with such a title -]

[T-Square]

Fenton--

Thanks for your ideas about scripted accounts. I plan on examining your sample file.

However, I have to take issue with one point you make. You say that "Both files should have the same set of account names/passwords."

But Patrick makes clear that he is using a separation model under the assumption that he can update the user interface without modifying the back end. In a SM environment, it won't be possible for the developer to deploy a new front end if the end user has created new accounts in their copy of the front end. Neither would it really be necessary, assuming that the UI should be static in the deployed system. So, the account setup will of necessity be different in the two files.

I think that he really should assume that the UI file will have one customer login with extremely limited access, and work out a system to manage the back end accounts and logins via scripts. At least, that's where I'm trying to head with this kind of situation.

It seems to me that in the FM security model, the Accounts are almost trivial in comparison to the Privilege Sets. While you can create accounts via script, I don't see any way to create or manage Privilege Sets without having your hands on the actual files. Thus, it seems to me that the most important step in managing security on deployed applications is to determine (and create) the Privilege Sets while you still have control of the files (i.e., early in the development cycle).

Just thinking out loud...

David

[Steven H. Blackwell]

We are concerned here with Identity and Access Management. Identity management occurs through the Accounts and their authentication process. Access is managed by the Privilege Set to which an Account is linked.

Use of External Server Authentication takes the authentication management out of the FileMaker Pro files and put it on a server. That way there are no Accounts in the FileMaker Pro files at all. Combined with the use of The Separation Model™ this provides almost completely seamless updating processes. This also allows for rollbacks if issues arise.

Steven

[patrickglass]

Hello again, I took your advide Old Advance Man, i talked with our manager and he has decided that eventually we will be going for a whole mine solution. and so we are purchasing a server and site licence pack. my question is what are the differences technical wise (other than the ammount of user who can log in) of FM Server Pro and advanced. Also while were at it between FM Pro and Advanced

Since we are getting the server is it easyer to manage users with the server rather than in the filemaker file itself. i have tried fentons examble but i seem to be stuck at one state where is will only place the user in the frontend file and not the two backends.

We would like to do backups regularily to our two other Samba servers. also at first we will be running FMS off a plain PC while test out needs for a sever comp. what specs are acceptable to run filemaker server with 10 connections at once. but to different databases completely.

I hope i made some sence, i was just sort of rambling. also i am leaving this company to go back to school in a week and am giving the responsibility of user management to someone else. Thanks for all the help. Patrick

[Steven H. Blackwell]

See the Server Tech Brief at

http://www.filemaker.com/support/uprade/techbriefs.html

Server Advanced is for Web Publishing and ODBC/JDBC. If you're not using those features, use FileMaker Server 8 (standard). You can always upgrade later if need be.

Contact Argyle & Broadstreet in Mississauga ON for your license needs as they are the official Sales Reps for FMI in Canada.

I recommend that you get a medium-power dual processor Xeon box with UW-SCSI (10K rpm) drives and run Windows Server 2003 Standard Edition on it.

HTH

Steven