Seeking Suggestions on Multi-File Accounts & Privileges

[T-Square]

I have a mature application that up till now has not made use of any login security. It is a 4-file separation-model application in which I give users extrememly limited access to the UI file, and essentially unlimited access to the other files. This is accomplished by having default "Client" Account & Privilege sets in each file that give appropriate access in each file.

Users "log in" to the app for audit tracking purposes. This consists simply of them selecting their name from a dropdown list on a standard layout, which assigns a global that is used to flag records that they create or edit. It enforces no security whatsoever, but provides a hint of tracking down the line.

My clients are asking for a new feature (credit card payments) that will require me to enforce much more rigorous security than before, and I am trying to figure out the best way to approach that.

I had planned on isolating the credit card information in a separate file and requiring a separate login for that file using FM's Accounts and Privileges. However, I found that there wasn't any way to add those tables to the UI relationship graph without the login prompt always triggering, which I felt would be intrusive for a user who wasn't going to be using the sensitive info.

I am now thinking that it would best to implement Accounts & Privileges across the app, and am looking for road-experience with this.

So far, what I have come up with is:

1) There will be Privilege sets in each file to cover the different roles. In addition to the Developer (Full access) role, I see a Basic role (for Basic Data Entry), and an Enhanced Role (for managing Credit Card Info, as well as allowing a change in roles).

2) A layout for users to add an Account will include the Account Name and the role for that account. They will also choose a password here.

3) A set of scripts (one in each file) will create the accounts and set the privileges.

4) The Basic privilege set in the Credit Card file will have no access.

5) Access to the sensitive data will be via buttons that will trigger scripts that will check the Privilege set before changing to layouts that display that data.

Some questions I have:

1) am I barking up the right tree, or is there a fundamentally easier way to accomplish my goal of a single login for all files that handles limited access to one file?

2) what can I do in the UI file (which I'll be distributing to my users)? If my clients set up different Accounts in that file, how will I prevent those Accounts from being overwritten? Is there a way to store account info in their data file, and derive the logins from that information?

3) if this sounds right, is there something glaring that I am missing?

4) if I add table occurrences for the "sensitive data" tables to the Relationship graph, will the Basic privilege set (the one with no access) trigger an onscreen error?

Any discussion or suggestions are welcome!

David

[Steven H. Blackwell]

1) am I barking up the right tree, or is there a fundamentally easier way to accomplish my goal of a single login for all files that handles limited access to one file?

I'd recommend you use External Server Authentication where all the Accounts are managed externally to FiIeMaker Pro. External Server Authentication is specifically designed for just this type scenario. See the White Paper on the FMI Web Site:

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

HTH

Steven

[John Mark Osborne]

Sounds like you have an excellent plan. That's the way I would do it with the exception of letting users create their own accounts and passwords. I would only allow administrators to do this because you will end up with passwords like "God", "Love" and "Fido". This will defeat the whole security thing if someone is able to easily guess a password.

[Steven H. Blackwell]

I would only allow administrators to do this because you will end up with passwords like "God", "Love" and "Fido".

Minimum password length can be enforced by FileMaker Pro. OTOH, credential lifecycle management options are much broader in the directory services than in FileMaker Pro. That's probably another reason for using External Server Authentication.

Steven

[T-Square]

Steven--

Thanks for the lead. I've looked at the white paper, and I'm not ready to go down the external authentication route. Neither I nor my clients are using Server, and they/we don't have an IT infrastructure that will support external authentication.

What I need to do is secure the database content from outsiders to ensure that credit card information stays at home. While it might be easier in a large-scale operation to use external authentication, in small shops, it's more work, since there's no server logins, etc.

I will have to experiment to see about some of the issues I raised--most notably with regard to account management in a separation model solution.

Cheers,

David

[Genx]

I use real accounts in my backend - this is where the auth happens. The accounts are all saved as refcords in a table. Then i have basic privelage sets in the front end with one account for each privilege setthat relate to each of the priv sets in the back. I.e. if a user has a privelege set of Sales in the back, they login in the back file, then based on their privilege set, the front end automatically logs in as the account that represents the privilege set in the backend...

In diagramatic form:

Account - Privelege set

Backend:

Alex - Sales

Brian - Sales

Wilma - Sales

James - Marketing

Krandle - Administration

Front End:

Sales - Sales

Marketing - Marketing

Administration - Administration

If wilma logs in in the back end, the front end will be logged in as sales.

If Krandle logs in in the back end, the front end logs in as administration.

And then on update, the accounts can all be regenerated in a new file because the passwords, account names and privlege sets are all stored within the file. No one go ranting at me about how i store the passwords... it would only be visible if any of the accounts had privilege of seeing the raw data which they don't.

Password is added through custom dialog.

Anyway, i've just sort of confused myself, but its all good.

Edited June 12, 2006 by Guest

[gephry]

Ah! Genx, I like that. I'll back you up if anyone rants.

I've been doing a very similar thing in FM6, but in a very half-a$$ed FM6 type of way. I now am supposed to translate the system up to FM8 and that is extremely helpful. I've been trying to figure out how I want to manage accounts. What do you do for disabling the back-end accounts? I used a drop-down menu with Disable/Enable choices. Or you have another idea?

Thanks again. It just gives you less to worry about.

[Genx]

I store the current serial id of the account in question in a global (seeing as all my fields are in the backend its like passing a variable), then execute a script in the backend to go to the accounts layout, do a find for that serial id contained in the global, and then perform whatever operations i need on the accounts that way.

~Genx