Security with Seperation format

[greg@work]

Hey guys, how do you setup and maintain login security for FM files using the seperation method. If it is stored in the GUI file how do you get the login info from the client old GUI file to your updated GUI file (besides asking for their old GUI file)? Or do you use an alternative login method, i.e. third file and not use FM security?

Some examples would be appreciated.

Cheers

[T-Square]

Greg--

I have been looking at security a lot recently, and here are my ideas so far. Please note that I haven't had a chance to implement and test these theories.

First, I will note that Stephen Blackwell always urges developers to use External Server Authentication to manage security (a feature of Server, which I don't have), which is beyond my knowledge or skill. But it's worth looking at.

Second, I believe that a two-tiered security model would be appropriate in the SM. The first tier is for the UI file, and is very basic, while the back end stores more complex security.

To my eye, the UI file really only has two levels of security needed: one for the developer (full access) and one for the users (access limited). This should simplify things, since (as you note) you will be distributing new versions of the UI file, which won't have downstream changes.

Then in the back end, you create a set of role-based Privilege Sets, which are preset to cover the different classes of user of the system. Obviously, determining these roles may be a severe sticking point (very similar to the frequent complaint that the SM doesn't help when you have to add fields to the data structure). I am hoping in my case that I can get away with only a few roles; in a moderately complex environment, there might be many.

Finally, you have scripted Account creation, where an semi-super user can assign the appropriate role to new users.

The accounts are maintained in the users' data file, and you are free to distribute new UI files without fear of losing their account info.

As I said, I haven't implemented this scheme, and I know there are areas I need to examine closely, but perhaps this will help you.

David

[greg@work]

T-square thanks for that

Yes the SM process can be an issue if you need to adjust the data file, but I am hoping that will be limited. I am adding a few unnamed fields to the data file to hopefully cater for a few of those changes if required, will see. SM is new to me hence my question about Security methods.

[Steven H. Blackwell]

A few general comments.

Most access privileges are set in the data files as noted. But you cannot ignore the UI/Logic file either. Custom Extended Privileges can help enforce security over business processes directed at data Integrity and Confidentiality.

For the most part privileges set in the data files for the various tables are respected in the UI/Logic file.

I have found it easiest to have the same Privilege Sets in the UI/Logic file as I have in the data files. The privileges themselves in any given Privilege Set may be different, but the consistent structure is very helpful.

External Server Authentication removes the Accounts and their management from the FileMaker Pro files, making creation, deletion, deprovisioning, etc. of Accounts much easier.

HTH

Steven

[T-Square]

Stephen--

Thanks for the tip about putting privilege sets in the front end as well. I assume I'm reading between the lines correctly in that you're NOT talking about Accounts, but only the Privilege Sets. But, when you say "Custom Extended Privileges can help enforce security over business processes ..." I am not clear how you would implement this in the UI file. I assume that you mean that your scripts take into account the current Privilege Set and behave accordingly. But how do you get the front end set up with the same PS as the datafile? Do you have a front end relogin to a generic account that uses the appropriate PS, or what?

Also, I KNEW you would be able to come in and get the External Authentication thing pushed...

David

[Steven H. Blackwell]

Thanks for the tip about putting privilege sets in the front end as well. I assume I'm reading between the lines correctly in that you're NOT talking about Accounts, but only the Privilege Sets.

No. Privilege Sets without Accounts just sit there doing nothing. The Accoutns have to be there as well.

Custom Extended privileges enforce business rules. Since user interaction with the system occurs in the UI/Logic file, that's where the CEP's belong.

Steven

[T-Square]

So, if the UI has the same accounts as the datafile, and your clients have the ability to add accounts, how is the developer supposed to push out a new UI file without damaging the client's account modifications? Doesn't that kind of defeat a main point of the Separation Model?

David

[Steven H. Blackwell]

So, if the UI has the same accounts as the datafile, and your clients have the ability to add accounts, how is the developer supposed to push out a new UI file without damaging the client's account modifications? Doesn't that kind of defeat a main point of the Separation Model?

No. it enhances it. You accomplish this by not putting the Accounts in the files. The Accounts go on the server.

Steven

[T-Square]

Stephen--

I guess we're in an Apples/Oranges situation. Your schema assumes a server environment; I do not have that luxury.

But I don't understand what you mean when you say:

"External Server Authentication removes the Accounts and their management from the FileMaker Pro files, making creation, deletion, deprovisioning, etc. of Accounts much easier"

but later say that:

"Privilege Sets without Accounts just sit there doing nothing. The Accounts have to be there as well"

and finish with:

"You accomplish this by not putting the Accounts in the files"

It seems like a contradiction to say on the one hand that accounts have to be there, but then say that they are handled exclusively by the server. Can you clarify that?

In the final view, I have no experience with the Server realm, so I can't really say, but it seems like your examples apply primarily (if not exclusively) to that realm. Those of us deploying to multiple single-user clients will have to consider other options.

David

[Steven H. Blackwell]

A Privilege Set is the core of the security schema for modern FileMaker Pro files. But the Privilege Set has to be attached to an Account in order to function.

That Account can be an internal FileMaker Pro Account. Or the Account can be on an External Server and be authenticated by, for example, Active Directory. In that case, the link to the Privilege Set is through the Group on the external Server matching the Group created inside the FileMaker Pro file. That is how the Accounts are removed from the files.

Accounts authenicate the user, whether the Account is internal or external. Once authenticated and granted access to the file, the user's actions and rights are governed by the Privilege Set.

External Server Authentication requires FileMaker Server.

For more information, please see the following:

http://www.filemakersecurity.com for FileMaker Security:The Book

http://www.filemaker.com/support/upgrade/techbriefs.html for three separate tech briefs. One is on Using the New Security Model; a second is on Server; a third, on External Server Authentication.

Your scenario that you describe is a special case; it clearly does not fall into the Server External Authentication realm.

HTH.

Steven